Modelos de Software con Objetos

About "names" when designing with Objects

2012-01-26T18:11:00.000-03:00

http://tinyurl.com/6ndcnbs

Hope you like it.

FAST te ayuda a ir a ESUG 2011!

2011-06-30T08:53:00.001-03:00

En FAST siempre estamos pensando la manera de hacer crecer la comunidad Argentina de Smalltalk. Es por ello que uno de nuestros objetivos siempre fue conectarnos y afianzar los lazos de amistad con las otras comunidades de Smalltalk del mundo.

Nos da mucha alegría comunicar que, como acción para lograr este objetivo, nos propusimos este año ayudar económicamente con 3.000 pesos a un Smalltalker que quiera ir a la conferencia de ESUG que se realiza este año en Escocia. (Para más información sobre la conferencia ver: http://www.esug.org/wiki/pier/Conferences/2011).

¿Quiénes pueden participar?
Hay dos requisitos para los que deseen presentarse:
1) Deben tener aceptada algún tipo de presentación en la conferencia, ya sea un paper de investigación, una charla en el área de desarrollo o participar del "Innovation Technology Award".
2) El viaje no debe estar subsidiado totalmente por la empresa/universidad donde trabajan (más información abajo)

¿Qué hay que hacer?
Es muy sencillo, simplemente mandar un mail a quieroIrAEsug2011@fast.org.ar con el subject: QUIERO IR A ESUG 2011, indicando nombre, apellido, y qué presentación realizarás (ya sea paper, presentación o sistema como parte del innovation technology award).

¿Hasta cuándo hay tiempo?
Los pedidos serán aceptados hasta el 8 de Julio del 2011 inclusive

¿Cuándo sabré si salí sorteado?
El resultado del sorteo será comunicado el 13 de Julio del 2011

¿Cómo se realizará el sorteo?
Se ordenará la lista de personas que se presentaron de manera random,
El que quede primero en la lista será el ganador del sorteo.
Si por algún motivo la persona ganadora del sorteo no puede ir, se lo sacará de la lista y el siguiente será el acreedor del sorteo. Así sucesivamente hasta que la persona ganadora acepte y utilice el premio.

¿Si gané, cuando recibiré la plata y cómo?
La plata se entregará por medio de una transferencia bancaria 5 días hábiles después de haber ganado el sorteo.
Para recibir el dinero deberá presentar una copia del pago de la registración a ESUG y del pago del pasaje de avión. Si luego de pasados esos 5 días dicha presentación no se realiza, el premio será acreditado a la siguiente persona en la lista.

¿La empresa donde trabajo me paga el viaje y el congreso, puedo participar?
No. Este sorteo es para aquellas personas que irán a ESUG por sus propios medios, ya sea de manera parcial o total.
Se utilizará la copia del pago de la registración y del pago del pasaje de avión para comprobar que esto sea así.

¿La empresa donde trabajo/universidad donde hago investigación me ayuda con un porcentaje del costo, puedo participar?
Sí, siempre y cuando el total que otorguemos más lo que aporte la empresa/universidad donde trabajás no supere el costo total del viaje (pasaje de avión, hospedaje y registración al congreso)
La intención es otorgar este dinero a gente que realmente lo necesite, confiamos en que se abstendrán aquellos que no cumplan con este requisito.

¿Dudas?
Mandar un mail a quieroIrAEsug2011@fast.org.ar

Realmente nos da mucha alegría poder ayudar de esta manera, esperamos que a ustedes también.
Go Smalltalk!

FAST: Fundación Argentina de Smalltalk
http://www.fast.org.ar

Smalltalks 2011 Call for Papers

2011-06-22T09:40:00.001-03:00

CALL FOR PAPERS

SMALLTALKS 2011
5th International Conference on Smalltalk Technologies
Research Track: Call for Papers
November 3th - 5th, 2011

Important dates:

Submission (Hard Deadline): August 22th, 2011 (Argentinian time:
UTC/GMT -3 hours).
Notification of acceptance: September 23th, 2011.
Camera Ready Submission: October 7th, 2011.

---------------------------------------------------------------------------------

Conference Location: Universidad Nacional de Quilmes (Argentina)

The Smalltalks series of conferences (www.fast.org.ar) is a lively
forum on Smalltalk-based software
technologies that brings together more than 200 people from both
academia and industry for a period of three days.

Past editions of Smalltalks have included many high-quality
presentations from industry and research.
These contributions have shown interesting applications of Smalltalk,
advances in the Smalltalk language, didactic uses of Smalltalk and so
on.

Similar to last year, Smalltalks 2011 will include a dedicated research
track.
We welcome submissions to this research track presenting original
scientific contributions to, or using, Smalltalk in general.

Topics of interest include, but are not restricted to:

- Aspects, Aspect Languages and Applications.
- Ambient Intelligence, Ubiquitous / Pervasive Computing and
Embedded Systems.
- Compilation Technology, Optimization, Virtual Machines.
- Educational Material.
- Language Engineering, Extensions.
- Model Driven Engineering / Development.
- Meta-Modeling, Reflection and Meta-programming.
- Programming in the Large, Design, Architectures and Components.
- Programming Environments, Browsers, User Interfaces, UI Frameworks.
- Source-code analysis and manipulation (Static analysis,
refactoring, type inference, metrics).
- Team Management.
- Testing, Extreme Programming / Practices.
- Web Services, Internet Applications, Event-driven Programming.
- Experience Reports.

Important dates:

Submission (Hard Deadline): August 22th, 2011 (Argentinian time:
UTC/GMT -3 hours).
Notification of acceptance: September 23th, 2011.
Camera Ready Submission: October 7th, 2011.

Papers:

Papers should be written in English, in PDF-format and should not exceed 15
pages (including references and figures), using the Elsevier journal format.

Templates for LaTeX formats can be found at
http://www.elsevier.com/wps/find/authorsview.authors/elsart

Papers must be submitted through the EasyChair submission web site at
https://www.easychair.org/conferences/?conf=smalltalks2011

The accepted papers will be digitally available on the conference
website. We are currently negotiating a special edition of a journal
for which the best papers will get invited.

Papers submitted must not have been previously published and must not be
under review for publication elsewhere. Papers must strictly adhere to
submission guidelines. If you have questions, please send an e-mail to
Jannik Laval and Andy Kellens to smalltalks2011-chair@fast.org.ar.

Program Committee
--------------------------
- Gonzalo Zabala (Universidad Abierta Interamericana, Argentina)
- Hernan Wilkinson (Universidad de Buenos Aires, Argentina)
- Serge Stinckwich (Institut de recherche pour le developppement, France)
- Mircea Lungu (University of Bern, Switzerland)
- Tudor Girba (Sw-eng. Software Engineering GmbH, Switzerland)
- Johan Fabry (DCC, Universidad de Chile, Chile)
- Luc Fabresse (Ecole des Mines Douai, France)
- Marcus Denker (INRIA Lille, France)
- Coen De Roover (Vrije Universiteit Brussel, Belgium)
- Damien Cassou (Hasso-Plattner-Institut, Potsdam, Germany)
- Gilad Bracha (SAP Labs, Palo Alto, USA)
- Noury Bouraqadi (Ecole des Mines Douai, France)
- Alexandre Bergel (DCC, Universidad de Chile, Chile)
- Gabriela Arevalo (Universidad Nacional de Quilmes, Argentina)

Program Chairs
--------------------
Andy Kellens (Vrije Universiteit Brussel, Belgium)
Jannik Laval (INRIA Lille/LABRI Bordeaux, France)

Estamos sorteando un lugar en el curso de TDD

2011-03-01T08:04:00.001-03:00

Para aquellos que están interesados en participar en el curso, les comento que estamos sorteando un lugar. Para anotarse vayan a http://tinyurl.com/4s35vsh

FAST ayuda a Guido y Javier a ir a la Deep Into Smalltalk School en INRIA

2011-02-10T10:06:00.003-03:00

En FAST (http://www.fast.org.ar) estamos muy contentos de haber podido ayudar a Guido Chari y Javier Pimas en su viaje a Francia para participar en la "Deep into Smalltalk School" (http://rmod.lille.inria.fr/web/pier/blog/2011-01-23) que el Inria está organizando con soporte de ESUG.
Además de organizar las conferencias de Smalltalk uno de nuestros objetivos es poder ayudar a la comunidad de Smalltalk Argentina en todo lo referente a la investigación y promoción industrial de Smalltalk.
Guido y Javier están terminando su tesis de licenciatura sobre SqueakNos y luego de este curso serán especialistas en la VM de Smalltalk!

Entrevista sobre por qué Smalltalk es tan importante en Argentina

2010-10-15T17:48:00.003-03:00

Este año durante ESUG, nos hicieron una entrevista a Leandro Caniglia y a mi sobre por qué creíamos que Smalltalk era tan importante en Argentina.
Pueden verla en http://blip.tv/file/4211623/
Por supuesto que es una visión subjetiva de los motivos, pero espero que les guste.

TDD en lenguajes estáticamente tipados y dinámicamente tipados

2010-10-14T21:52:00.002-03:00

Subí un video que compara cómo se comporta la técnica de Test Driven Development (TDD) utilizando lenguajes estáticamente tipados (en este caso Java) y dinámicamente tipado (en este caso Smalltalk). El video está divididó en dos partes:

1) http://www.youtube.com/watch?v=RLAZjiK4UHc
2) http://www.youtube.com/watch?v=wXW9WN9ay2E

Traté de ser lo más objetivo posible. Por supuesto, es solo un experimiento y no se puede inferir todas las diferencias que ya conocemos entre estos tipos de lenguajes, pero sí puede servir como punto de partida para investigar un poco más el tema.
Espero que les gusten las conclusiones :-)

Entrada gratis para el curso de TDD!!

2010-10-12T14:28:00.002-03:00

Vamos a sortear una entrada gratis para el curso de TDD (http://tinyurl.com/25n4zwq) este jueves 14 en http://tinyurl.com/2du3yox
Aprovechen!

TDD practicado en lenguajes dinámicos vs. lenguajes estáticos

2010-10-05T15:17:00.001-03:00

eEte jueves 7 de octubre a las 18.30, en el grupo argentino de Ruby en Urban Station, El Salvador 4588 en Palermo Soho voy a dar una charla sobre TDD practicado en lenguajes dinámicos vs. lenguajes estáticos. Acá está la breve descripción:
La charla se centra en mostrar las diferencias esenciales que surgen al utilizar la técnica de Test Driven Development (TDD) en lenguajes dinámicos como Ruby respecto de lenguajes estáticos como Java.
Se hará una pequeña introducción sobre TDD y una demostración en vivo de las diferencias utilizando para ello otro lenguaje dinámico, Smalltalk, antecesor de Ruby y Java como lenguaje estático.
Los espero!

Smalltalks 2010 - Declarado de Interés Provincial

2010-09-27T21:49:00.002-03:00

La provincia de Entre Ríos declaró de Interés Provincial a la 4ta conferencia de Smalltalk en Argentina, Smalltalks!
No se imaginan lo contento que estamos!! Por más que sea una cuestión formal, es una gran reconocimiento hacia el evento, la comunidad de Smalltalk en Argentina y Smalltalk, así que estamos más que contentos!

Smalltalks 2010 - Inscripción abierta!!

2010-09-22T14:55:00.004-03:00

Ya está abierta la inscripción para Smalltalks 2010! pueden registrase en http://www.fast.org.ar/
Este año lo hacemos en Concepción del Uruguay, Entre Rios, a solo 3 horas de Buenos Aires. Estamos arreglando descuentos con hoteles para aquellos que lo necesiten.
Además tenemos confirmada la visita de Lukas Renggli (creador de SeaSide entre otras cosas) y Gilad Bracha (creador de Newspeak). Tenemos un par de personalidades más en tratativas, así que no dejen de anotarse y presentarnos sus trabajos, va a ser una conferencia muy interesante!

Curso de Test Driven Development para todos!

2010-09-07T20:56:00.004-03:00

Tengo el agrado de notificarles que está abierta la inscripción a uno de los cursos de Test Driven Development (TDD) que ofrecemos en 10Pines, el cual se denomina “Construcción de Software Robusto con Test Driven Development” a realizarse a partir del 15 de noviembre del corriente año.
Test Driven Development (TDD) es una de las prácticas ágiles que más adopción tuvo dentro de la comunidad de desarrollo de software debido a su simplicidad como proceso y efectividad directamente relacionada con la calidad del sistema generado. TDD ayuda a producir diseños más simples y menos acoplados, creando al mismo tiempo un gran conjunto de test que nos dan “coraje” al momento de realizar cambios o incrementar la funcionalidad de un sistema. Hay estudios que muestran que usando TDD, la tasa de error de los sistemas disminuye 10 veces aumentando al mismo tiempo la satisfacción laboral y técnica de los desarrolladores.
El curso, de 16 hrs, posee una breve introducción teórica para luego concentrarse en ejercicios prácticos especialmente preparados para que los asistentes aprendan la técnica.
Pero como el nombre del curso lo indica, este no se centra únicamente en TDD sino en la construcción de software robusto, por lo tanto además de aprender la técnica de TDD, se realizarán discusiones enriquecedoras de diseño y arquitectura que les permitirá complementar, validar y aumentar tus conocimientos sobre el desarrollo de software utilizando objetos.
Para más información sobre los objetivos, días, disponibilidad y costos del curso, hace click acá: Construcción de Software Robusto con Test Driven Development

Los espero!

Por qué las base de datos relacionales van a desaparecer

2010-08-30T11:03:00.002-03:00

Si, si, es una predicción medio loca y hasta pareciera absurda dado el estado actual de tecnologías, pero hay mucho indicios que me llevan a pensar lo que puse en el título.
En realidad, son todos indicios tecnológicos y no de negocios, pero como nuestra profesión se basa en la tecnología creo que en algún momento se hará fuerte una tecnología que desplazará a las base de datos relacionales de la misma manera que ellas desplazaron a los archivos jerárquicos (como vsam, etc).
Lo que me llevó a pensar esto nuevamente es un proyecto en el cual estoy haciendo coaching en el cual estamos usando Java como lenguaje de programación y Hibernate para conectarnos a una base de datos relacional. Hubo dos "colaboraciones" que me hicieron recordar lo antiguo de esta tecnología:

1) Cada vez que se quiere persistir un objeto, hay que hacer: session.save(anObject)
2) Cada vez que se quiere borrar un objeto, hay que hacer: session.delete(anObject)

¿Qué tiene de malo tener que hacer esto? Simplemente que en otras tecnologías no es necesario hacerlo! por lo tanto son más simples desde el punto de vista de utilización lo que implica que son menos propensas a error.
Para el caso 1), en una tecnología como la que usa GemStone, no es necesario decirle a un objeto que quiero que se persista, simplemente si ese objeto es referenciado desde un objeto persistido, este se persiste. Simple, natural, lógico.
El caso 2) es quizá el más fuerte puesto que me hizo acordar al manejo de memoria manual, ¿recuerdan c++, tener que hacer "delete anObject" para desalocarlo y todos los problemas que ello conllevaba? Acá estamos en el mismo caso, utilizar base de datos relacionales es como utilizar un manejo de memoria manual algo que por suerte ya está abandonado (salvo para casos muy particulares). ¿Por qué tenemos que borrar un objeto explícitamente cuando el mismo puede desaparecer automáticamente, como cuando se realiza un garbage collect?. Por suerte ya hay tecnologías que hacen esto (de vuelta GemStone) y "borran" objetos cuando los mismos no están más referenciados. Simple, natural, lógico.
Creo que estos dos casos son indicios que muestran que trabajar con base de datos relacionales en algún momento tiene que cambiar. En algún momento nos tenemos que dar cuenta que trabajar con ellas es trabajar en un paradigma "viejo", similar al procedural donde se separan "datos" de "código", en vez de utilizar un paradigma que ya está probado ser más robusto y escalable para desarrollo de aplicaciones como el de objetos.
Claro está que la base de datos relacionales tienen sus ventajas. Por ahí la más fuerte desde el punto de vista tecnológico es el SQL, pero al mismo tiempo para mi es su cruz, es lo que no va a permitir que la tecnología evolucione, cambie paradigmáticamente. Y por supuesto no hay que dejar de ver la fuerza comercial que ellas tienen, pero como dije antes, en algún momento la comunidad estará preparada para algo nuevo, distinto, cuando se cansen de tener que hacer save y delete y se den cuenta que si en memoria no hay que hacer eso, ¿por qué hay que hacerlo con el disco?, en definitiva el disco es "memoria" y debería estar abstraído (salvo cuando hay que hacer aplicaciones que deben diferenciarlos :-) ).
Claro está que a los dos problemas que mencioné hay que agregar varios más, como el problemático mapeo, manejo de identidad, manejo de caching y unicidad, etc., problemas que en otras tecnologías no existen...
Para concluir, ¿cuándo pasará esto? No creo que rápidamente... de la misma manera que a las base de datos relacionales les costó desplazar a los archivos planos y jerárquicos, no será inmediato reemplazar a estas. Por ahí en 10 años se empiece a divisar y entender que hay una alternativa a ellas, no creo que antes, a menos que aparezca un player nuevo en la comunidad, un player que sea respetado y tenga fuerza y logre imponer el quiebre paradigmático... por ahí ese player puede ser VMWare si se da cuenta del productozo que compró (GemStone), pero habrá que ver si sus "gurús" logran salirse del paradigma actual y ver más allá... el tiempo dirá.

¿A quién le creo?

2010-08-29T14:25:00.003-03:00

Este comentario no tiene nada que ver con objetos ni sistemas, sino más bien con la realidad que nos está golpeando a los argentinos respecto de los medios de comunicación.
El viernes mientras caminaba hacia un cliente para dar un coaching de TDD me encontré con un kiosko que tenía a los diarios Clarín y Tiempo Argentino juntos, motivo por el cual pude observar una contradicción impresionante sobre la misma noticia en la primera plana de ambos diarios.
Clarín decía: "Papaleo declaró que estaba libre cuando vendió Papel Prensa". (ver http://www.clarin.com/ediciones-anteriores/edicion-impresa/20100827)
Tiempo Argentino decía: "Papaleo ratificó que entregó Papel Prensa bajo presión" (ver http://tiempo.elargentino.com/ediciones/2010-08-27/notas)
¿Quién dice la verdad? Clarín? Tiempo Argentino? Ninguno? o los dos? ¿Qué contradicción no?.
Sinceramente no me inclino por Clarín, ya se han visto tantas manipulaciones que realizó que seguro esta es otra más. ¿Qué ha acerca de Tiempo Argentino? Es oficialista y nos han hecho creer que generalmente ser oficialista está mal y que los políticos siempre mienten, ah, pero claro, los que nos han metido en la cabeza eso fueron los periodistas (y también bastante los políticos con su actuar realmente)... ¿entonces?...
Finalmente me quedo con lo que me recordó mi viejo hoy por la mañana: "En una guerra la primero que pierde es la verdad"... creo que este es un ejemplo claro.

Tributo a Alan Kay en su cumpleaños 70

2010-08-06T09:53:00.002-03:00

La gente de ViewPoints ha publicado un libro (que se puede bajar on-line) como tributo a Alan Kay en el cual personas que trabajaron con él escribieron un capítulo cada uno. Hay varios capítulos interesantes como por supuesto el de Adele Goldberg, con un poco de historia también... Por ejemplo no sabía que el primer "cliente" comercial de Smalltalk fue la CIA!!! jaja, increíble... menos mal que no lo siguieron usando o por lo menos no sabemos si lo siguen usado... o por ahí el motivo por el cual Smalltalk no creció más fue por que la CIA no quizo!! claro! por fin lo entiendo :-) y bue, la teoría conspirativa siempre tiene que estar presente :-)

Working effectively...

2010-08-04T17:56:00.002-03:00

with legacy code... Ese es el nombre de un libro que estuve hojeando (últimamente me cuesta mucho leer libros técnicos, me aburren!! lo cual no es un buen sintoma...) que está interesante, es recomendable pero que muestra nuevamente la cantidad de problemas que surgen en el mantenimiento de sistemas desarrollados con lenguajes estáticamente tipados.
Básicamente, el mayor problema es el acoplamiento que produce tipar las variables lo cual impede al momento de tener que escribir tests para código existente utilizar objetos que simplemente sean polimórficos con los objetos reales pero solamente para el conjunto de mensajes que se le envían y no para todo el protocolo declarado en el tipo!
Si, ok, están los mock objects y sus librerías para hacer su uso más fácil, pero igual sigue siendo más laburo del necesario o por lo menos del que llevaría en un lenguaje dinámicamente tipado como Smalltalk...
Por último, el libro muestra muchos errores de diseño típicos muy interesantes que haciendo TDD desde el comienzo no se cometerían que nuevamente tienen que ver con lograr diseños más desacoplados, algo que venimos comentando en nuestro curso de TDD desde que empezamos.

Para los que aman la historia de nuestra profesión...

2010-08-04T17:50:00.002-03:00

como yo, salió una entrevista a Edgar Dijkstra realizada en el 2001 en la última Computer. La verdad, muy recomendable para conocer un poco más sobre el principio de nuestra profesión con comentarios sobre Algol-60, Peter Naur, Hoare, N. Wirth (y su relación con el paper de GOTO Considered Harmfull)... y como no podía faltar, la comparación USA/Europa que propició el comentario de Alan Kay en su Turing Award Lecture.
La entrevista completa está online para todos en: http://www.cbi.umn.edu/oh/display.phtml?id=320

Smalltalks 2010 Research Track: Call for Papers

2010-06-22T09:16:00.003-03:00

Con esto, queda oficialmente anunciado el congreso Smalltalks 2010!!!
Este año lo haremos en la UTN de Concepción del Uruguay, Entre Rios.
Estamos muy contentos de poder hacerlo ahí, una facultad que ha hecho mucho por Smalltalk y ha traido mucha gente a todos los congresos, y estamos muy contentos de poder hacerlo en otra ciudad que no sea Buenos Aires puesto que nuestro objetivo es llevar Smalltalk a todo el país.
Por favor! miren que comité tenemos!!! la put... una maravilla (todo laburo de Gabriela Arevalo, grande Gaby!!)
Para la gente de Buenos Aires, les comento que estamos trabajando para hacer que el viaje y hospedaje sea factible para todos.
Personalmente creo que esta bueno salir un poco de la "gran ciudad", conocer otros lugares de nuestro país y apoyar la difusión de Smalltalk de esta manera, espero que puedan apoyarnos en esta iniciativa!
--------------------------------------------------------------------------------------------
CALL FOR PAPERS

SMALLTALKS 2010
4th Argentinian Smalltalk Conference
Research Track: Call for Papers
November 11th – 13th, 2010
Important dates:
Submission (Hard Deadline): September 7th, 2010 (Argentinian time: UTC/GMT
-3 hours).
Notification of acceptance: October 6th, 2010.
Camera Ready Submission: October 20th, 2010.
---------------------------------------------------------------------------------

Conference Site: Universidad Tecnológica Nacional (UTN), Concepción del
Uruguay (Entre Ríos, Argentina)

In the past three years the Smalltalks series of conferences (www.fast.org.ar)
have been a lively forum on Smalltalk-based software technologies that
attracted over more than 200 people from both academia and industry for
three days.

During the first three conferences, the industrial partners showed the
applicability of Smalltalk in business, while researches (both students and
professors) showed their advances and didactic uses of Smalltalk. The
presented
approaches and methodologies concerned the language, its implementation
technology, its programming tools as well as the software development
culture it supports.

This year the accepted papers not only will be available in the website but
also the best ranked ones will be published in a special edition of Elsevier
COMLAN Journal. Thus, we invite to submit papers in the research track on
original scientific research conducted in and/or for Smalltalk in general.

Topics of interest include, but are not restricted to:

• Aspects, Aspect Languages and Applications.
• Ambient Intelligence, Ubiquitous / Pervasive Computing and Embedded
Systems.
• Compilation Technology, Optimization, Virtual Machines.
• Educational Material.
• Language Engineering, Extensions.
• Model Driven Engineering / Development.
• Meta-Modeling, Reflection and Meta-programming.
• Programming in the Large, Design, Architectures and Components.
• Programming Environments, Browsers, User Interfaces, UI
Frameworks.
• Reasoning About Code (Analysis, Refactoring, Type Inference,
Metrics).
• Team Management.
• Testing, Extreme Programming / Practices.
• Web Services, Internet Applications, Event-driven Programming.
• Experience Reports.

Important dates:

Submission (Hard Deadline): September 7th, 2010 (Argentinian time: UTC/GMT
-3 hours).
Notification of acceptance: October 6th, 2010.
Camera Ready Submission: October 20th, 2010.

Papers:

Papers should be written in English, in pdf-format and not exceed 15 pages
(including references and figures), using Elsevier journal format.

Templates for LaTeX formats can be found at
http://www.elsevier.com/wps/find/authorsview.authors/elsart

Papers must be submitted through the EasyChair submission web site at
http://www.easychair.org/conferences/?conf=smalltalks10
The accepted papers will be digitally available in the conference website.
From accepted papers, selected ones will be published in a special edition
of Elsevier COMLAN Journal.

Papers submitted must not have been previously published and must not be
under review for publication elsewhere. Papers must strictly adhere to
submission guidelines. If you have questions, please send an e-mail to
Marcus Denker and Gabriela Arévalo to smalltalks2010-chair@fast.org.ar using
[Smalltalks2010-RT] as tag in the e-mail subject.

Program Committee
--------------------------
• Alexandre Bergel (DCC, Universidad de Chile, Chile)
• Noury Bouraqadi (Ecole des Mines, Douai, France)
• Gilad Bracha (Ministry of Truth, USA)
• Johan Brichau (Inceptive.be, Belgium)
• Johan Fabry (DCC, Universidad de Chile, Chile)
• Alejandro Fernandez (LIFIA - Facultad de Informática – UNLP,
Argentina)
• Tudor Girba (Sw-eng. Software Engineering GmbH, Switzerland)
• Andy Kellens (SOFT, Vrije Universiteit Brussels, Belgium)
• Michele Lanza (University of Lugano, Switzerland)
• Adrian Lienhard (SCG, University of Bern, Switzerland)
• Damien Pollet (INRIA / Université de Lille 1, France)
• Lukas Renggli (SCG, University of Bern, Switzerland)
• David Röthlisberger (SCG, University of Bern, Switzerland)
• Tom Van Cutsem (SOFT, Vrije Universeit Brussels, Belgium)

Program Chairs
--------------------
• Marcus Denker (INRIA, Lille, France)
• Gabriela Arévalo (Universidad Austral, Buenos Aires, Argentina)

Conclusiones sobre el Open Agile del Sabado

2010-03-15T07:49:00.002-03:00

Este sábado fui al open agile que se realizó en el centro cultural Borges y del cual 10Pines fue auspiciante. Personalmente me gusta mucho la dinámica de los "open space", se logran charlas muy interesantes y todos aportan su conocimiento, si nunca fueron a un evento de este tipo, les aconsejo por lo menos ir una vez para ver cómo se realiza.
Respecto de la parte técnica del evento, saqué un par de conclusiones que quería compartir:
1) Me llamó la atención la confusión que existe entre TDD y test. Vi que hay muchas personas que creen que TDD es la única solución de test y lo quiren usar para resolver todos los problemas como la generación de UI, configuración de sistemas, etc. Sin embargo TDD implica desarrollo de software y no solo eso, implica escribir el test primero, por lo tanto testear la UI no es hacer TDD porque para poder hacerlo es necesario tener la UI por lo que no se escribe el test primero. Testear la configuración de un sistema no es TDD puesto que no se está desarrollando nada, etc. En conclusión TDD es una técnica más que entre otras cosas ayuda a testear, pero no es la única técnica de testing.
2) Me sorprende cómo cuando se habla de buen diseño la gente relativiza tanto el término "buen", hasta el punto donde puede ser "mal" y no hay problema. Esto es algo que me ha pasado en otros ámbitos y la facultad también, pareciera que el diseño de una aplicación puede ser cualquier cosa y hablar de "buen diseño" no tiene sentido. Yo soy completamente contrario a esa opinión. Para mi existen buenos y malos diseños y se pueden determinar en base a un conjunto de criterios bien establecidos que tienen que ver con aquellos que atacan la esencia del software y su desarrollo. Cuestiones como mantenibilidad, representabilidad, semántica, etc. son características esenciales del software que definen que tan bien o no está diseñado. Por último existe un conjunto de características no esenciales en la cual el diseño puede diferir fuertemente, como performance, usabilidad, etc. y donde creo que si se puede relativizar un poco más que es bueno o malo puesto que son características más contextuales que esenciales
3) Cada vez me lamento más que Kent Beck haya llamado a SUnit así. En realidad me lamento la parte de Unit puesto que a partir de esto se relaciona TDD únicamente con test unitarios y hay mucho más que test unitarios en tdd. Los test pueden ser bien funcionales, pueden ser user stories, se puede usar xUnit para escribir test de programación o diseño que nada tienen que ver con que sean "unitarios"... en fin, una lástima la confusión que se genera por este nombre.

Videos de Smalltalks 2009

2009-12-03T08:02:00.002-03:00

Que tal,
James Foster está publicando los videos que filmó es su blog. La verdad que se está tomando un trabajo impresionante porque los está combinando con las slides, muchas gracias James!!
Acá está el link a la apertura del congreso http://www.youtube.com/watch?v=UzRZmFKxqO4
Y aca el link al blog de James http://programminggems.wordpress.com

Jornada de Calidad

2009-11-05T14:46:00.003-03:00

Un post para mi olvidado blog :-)
Voy a dar una charla de TDD en las Jornadas de Calidad de la Ort: http://campus.ort.edu.ar/ceo/noticia/61244/jornada-de-calidad-de-software

Por otro lado no olviden de verificar www.fast.org.ar dentro de poco estará el cronograma publicado!

Smalltalks 2009 - Tercera Conferencia Argentina de Smalltalk

2009-08-23T22:10:00.000-03:00

Del Jueves 19 al Sábado 21 de Noviembre del corriente año,
se llevará a cabo en la Facultad de Ciencias Exactas y Naturales (FCEN) de
la Universidad de Buenos Aires, la Tercera Conferencia de Smalltalk de Argentina,
denominada "Smalltalks 2009"

Todas aquellas personas que estén relacionadas con Smalltalk, sean
docentes, alumnos, investigadores, desarrolladores o empresarios, están
invitados a participar como oyentes o expositores de manera gratuita.
El sitio para inscribirse será anunciado en breve.

El objetivo de la conferencia es reunir a la comunidad Smalltalk Argentina e Internacional
para estrechar vínculos compartiendo trabajos,
experiencias y vivencias relacionadas con esta tecnología o temas afines.

Esta edición de la conferencia categorizará las presentaciones en "Industria y Desarrollo" e "Investigación y Educación", contará con un concurso de programación y nos visitará, nuevamente, gente reconocida de la comunidad Smalltalk internacional.

En la "Categoría de Investigación/Educación" se expondrán aquellos trabajos de
investigación y educación que se estén realizando o se hayan realizado con
Smalltalk, en ámbitos de universidades y establecimientos públicos o
privados.

En la "Categoría de Industria y Desarrollo" se expondrán trabajos relacionados a la
Creación de Software utilizando Smalltalk, por medio de empresas o personas, con fines comerciales o no.

Algunos temas sugeridos para las presentaciones, de manera no excluyente son:
* Herramientas de Desarrollo
* Desarrollo con Prototipos
* Model Driven Development
* Prácticas Ágiles (XP, TDD, etc)
* Desarrollos de Aplicaciones Web
* Meta-Modeling / Meta-Programación
* Nuevos Modelos o Frameworks implementados
* Material Educativo
* Sistemas Embebidos y Robótica
* SOA y Web services
* Reportes de Experiencias de Desarrollo o Investigación
* Sistemas comerciales
* Testing: Prácticas y automatización
* Interoperabilidad con otras tecnologías
* Best Practices de Diseño y Arquitectura

Aquellos interesados en exponer, deben tener en cuenta los siguientes
hitos y tareas:

1) Deben presentar un Resumen de la presentación a más tardar para el
Lunes 19 de Octubre de 2009. Dicho Resumen no debe superar una carilla
y debe incluir mínimamente una descripción del trabajo a presentar sin
omitir el objetivo del mismo y la categoría a la cuál pertenece la presentación.
El mecanismo de presentación del Resumen será anunciado en breve.

2) El Comité de Programa de la Conferencia definirá para el Lunes 26 de
Octubre aquellos trabajos que serán elegidos para ser presentados durante
la jornada a partir de los Resúmenes recibidos según lo especificado
en el punto anterior. Se dará mayor importancia a aquellos trabajos con
capacidad de mostrar ejemplos dinámicos y no únicamente presentaciones
estáticas.

3) Los trabajos y presentaciones realizadas serán publicadas en el sitio de la conferencia una vez finalizada la misma.

4) La definición del Cronograma de la Conferencia se publicará a través
de la página web el Miércoles 28 de Octubre.

Respecto del concurso de programación, todos aquellos que deseen participar pueden interiorisarse del mismo en el grupo smalltalks-2009-coding-contest@googlegroups.com
La intención del concurso es pasar un buen momento, disfrutar solucionando un problema en Smalltalk y ganar un premio como reconocimiento del trabajo realizado.
Estamos trabajando fuertemente para que todos puedan participar del mismo e iremos presentando ejemplos y prototipos que puedan ser tomados de ejemplo para desarrollar mejores soluciones.

Para información sobre cómo llegar a la FCEyN, pueden acceder al sitio del departamento de computación: http://dc.uba.ar
Por favor, difundan esta invitación en aquellas listas y grupos que consideren interesados.

Los esperamos a todos!
Comité Organizador de Smalltalks 2009

Bing vs. Google

2009-07-09T21:42:00.003-03:00

Fijensé el resultado de hacer http://bing-vs-google.com/?q=bing (o sea, buscar bing y comparar los resultados de google y bing).

No siempre el resultado será siempre el mismo, les dejo una imagen que muestra la diferencia...

Una conclusión interesante sobre la ley de Moore y un dicho de Alan Kay

2009-07-09T21:18:00.001-03:00

No tiene desperdicio: http://lists.canonical.org/pipermail/kragen-tol/2007-March/000850.html

¿Quizá debería ver VisualAge/Envy un poco?

2009-07-09T18:58:00.002-03:00

Sino, no haría el comentario del final :-) http://lambda-the-ultimate.org/node/3459

Algo que venimos enseñando hace más de 10 años

2009-07-09T18:37:00.002-03:00

Los diagramas de diseño tienen como objetivo comunicar. Me alegro que Rebecca lo ponga bien claro es su blog: http://www.wirfs-brock.com/2009/06/value-of-design-documentation.html

Respuesta: ¿Cómo mejorar esta clase?

2009-07-03T10:11:00.002-03:00

El otro día postee una pregunta sobre cómo mejorar la clase MouseOverHandler de Squeak/Pharo... no hubo ningún comentario lo que creo que significa que nadie se animó a hacerlo! (o claro, nadie leyó el post...). En fin, creo que nadie se animó a hacerlo porque realmente no es fácil y sólo ver el código desalienta a cualquiera, pero bueno, yo lo hice hace una para de semanas atrás así que les comento cómo.
Primero, ¿cuál es el problema con esta implementación? El principal es que el método #processMouseOver: es muy difícil de entender. Es muy largo y complicado, así que hay que empezar por tratar de entender que hace y mejorarlo. Para ello vamos a utilizar el refactoring de extract method para reemplazar colaboraciones por mensajes que revelen su intención. Lo interesante es que el método está comentado justamente en las secciones que vamos a extraer, lo cual muestra como a veces en vez de comentar código simplemente hay que escribirlo con intention revealing. Veamos como queda.
Reemplacemos este código:

hand := anEvent hand.
leftMorphs := mouseOverMorphs asIdentitySet.
"Assume some coherence for the number of objects in over list"
overMorphs := WriteStream on: (Array new: leftMorphs size).
enteredMorphs := WriteStream on: #().

Por:
self initializeProcessMouseOver.

Luego reemplacemos:
"Now go looking for eventual mouse overs"
hand handleEvent: anEvent asMouseOver.
"Get out early if there's no change"
(leftMorphs isEmpty and: [enteredMorphs position = 0])
ifTrue: [^leftMorphs := enteredMorphs := overMorphs := nil].
focus := hand mouseFocus.

Por:
self handleAsMouseOver: anEvent.

También reemplacemos: (no se preocupen en leer todo el código, simplemente tomen un dimensión de qué estamos reemplazando y por quién)
"Send #mouseLeave as appropriate"
evt := anEvent asMouseLeave.
"Keep the order of the left morphs by recreating it from the mouseOverMorphs"
leftMorphs size > 1
ifTrue: [leftMorphs := mouseOverMorphs select: [:m | leftMorphs includes: m]].
leftMorphs do:
[:m |
(m == focus or: [m hasOwner: focus])
ifTrue:
[localEvt := evt transformedBy: (m transformedFrom: hand).
m handleEvent: localEvt]
ifFalse: [overMorphs nextPut: m]].

Por:
self handleAsMouseLeave: anEvent.

También reemplacemos:
"Send #mouseEnter as appropriate"
evt := anEvent asMouseEnter.
enteredMorphs ifNil:
["inform: was called in handleEvent:"

^leftMorphs := enteredMorphs := overMorphs := nil].
enteredMorphs := enteredMorphs contents.
enteredMorphs reverseDo:
[:m |
(m == focus or: [m hasOwner: focus])
ifTrue:
[localEvt := evt transformedBy: (m transformedFrom: hand).
m handleEvent: localEvt]].

Por:
self handleAsMouseEnter: anEvent.

Y por último:
"And remember the over list"
overMorphs ifNil:
["inform: was called in handleEvent:"

^leftMorphs := enteredMorphs := overMorphs := nil].
mouseOverMorphs := overMorphs contents.
leftMorphs := enteredMorphs := overMorphs := nil

Por:
self rememberOverList

Bueno, no se que les parece (o si quedó claro como lo escribí), pero simplemente hay que agarrar cada conjunto de colaboraciones que tiene un comentario sobre que hacen y extraerlas a otro método. En conclusión con algunos cambios más el método #processMouseOver: quedá así:

processMouseOver: anEvent

self initializeProcessMouseOver.
self handleAsMouseOver: anEvent.
self hasLeftMorphsChanged ifTrue: [
self handleAsMouseLeave: anEvent.
self handleAsMouseEnter: anEvent.
self rememberOverList ].

self initializeTrackedMorphs

¿Se entiende mejor qué hace no?. Fijensé como un cambio tan sencillo, simplemente usando extract method, mejora el diseño considerablemente. Por supuesto que hay que seguir utilizando esta técnica para cada uno de los nuevos métodos porque siguen siendo muy complejos y al hacerlo se puede ver que hay código repetido, de hecho el mismo refactoring browser al realizar la extracción lo sugiere. No voy a mostrar todo este proceso porque es similar al anterior y no quiero hacer el post muy pesado (más de lo que es!).
Por último, también realicé otros cambios como por ejemplo no usar nil para inicializar las variables de instancia que utiliza para realizar el procesamiento, sino inicializarlas con colecciones vacías de tal manera que nunca se produzca un MNU.
En conclusión, el código quedó así:

Object subclass: #MouseOverHandler
instanceVariableNames: 'mouseOverMorphs enteredMorphs overMorphs leftMorphs'
classVariableNames: ''
poolDictionaries: ''
category: 'Morphic-Events'!
-------------------------------------------------------------------------------
processMouseOver: anEvent

self initializeProcessMouseOver.
self handleAsMouseOver: anEvent.
self hasLeftMorphsChanged ifTrue: [
self handleAsMouseLeave: anEvent.
self handleAsMouseEnter: anEvent.
self rememberOverList ].

self initializeTrackedMorphs
-------------------------------------------------------------------------------
initializeProcessMouseOver

leftMorphs := mouseOverMorphs asIdentitySet.
overMorphs := WriteStream on: (Array new: leftMorphs size).
enteredMorphs := WriteStream on: #()! !
-------------------------------------------------------------------------------
handleAsMouseEnter: anEvent

| asMouseEnterEvent |

asMouseEnterEvent := anEvent asMouseEnter.
enteredMorphs := enteredMorphs contents.
enteredMorphs reverseDo: [ :anEnteredMorph |
self inform: asMouseEnterEvent to: anEnteredMorph originatedFrom: anEvent ifNotFocusedDo: [] ]
-------------------------------------------------------------------------------
handleAsMouseLeave: anEvent

self keepLeftMorphsOrder.
self informMouseLeaveToLeftMorphsUsing: anEvent
-------------------------------------------------------------------------------
handleAsMouseOver: anEvent

anEvent hand handleEvent: anEvent asMouseOver.
-------------------------------------------------------------------------------
noticeMouseOver: aMorph event: anEvent
"Remember that the mouse is currently over some morph"

leftMorphs remove: aMorph ifAbsent: [ enteredMorphs nextPut: aMorph ].
overMorphs nextPut: aMorph.
-------------------------------------------------------------------------------
initialize
mouseOverMorphs := #().

self initializeTrackedMorphs
-------------------------------------------------------------------------------
initializeTrackedMorphs

leftMorphs := OrderedCollection new.
overMorphs := WriteStream on: #().
enteredMorphs := WriteStream on: #().
-------------------------------------------------------------------------------
hasLeftMorphsChanged

^(leftMorphs isEmpty and: [ enteredMorphs position = 0 ]) not
-------------------------------------------------------------------------------
inform: evt to: aLeftMorph originatedFrom: anEvent ifNotFocusedDo: aBlock

^ (self is: anEvent withFocusOver: aLeftMorph)
ifTrue: [ self transform: evt from: anEvent andSendTo: aLeftMorph ]
ifFalse: aBlock
-------------------------------------------------------------------------------
informMouseLeaveToLeftMorphsUsing: anEvent

| asMouseLeaveEvent |

asMouseLeaveEvent := anEvent asMouseLeave.

leftMorphs do: [ :aLeftMorph |
self inform: asMouseLeaveEvent to: aLeftMorph originatedFrom: anEvent ifNotFocusedDo: [ overMorphs nextPut: aLeftMorph ] ]
-------------------------------------------------------------------------------
is: anEvent withFocusOver: aMorph

| focusedMorph |

focusedMorph := anEvent hand mouseFocus.
^ aMorph = focusedMorph or: [ aMorph hasOwner: focusedMorph ]
-------------------------------------------------------------------------------
keepLeftMorphsOrder

leftMorphs size > 1 ifTrue: [ leftMorphs := mouseOverMorphs intersection: leftMorphs ]
-------------------------------------------------------------------------------
rememberOverList

mouseOverMorphs := overMorphs contents.
-------------------------------------------------------------------------------
transform: anEvent from: originalEvent andSendTo: aMorph

| transformedEvent |

transformedEvent := anEvent transformedBy: (aMorph transformedFrom: originalEvent hand).
^ aMorph handleEvent: transformedEvent
-------------------------------------------------------------------------------
¿Mucho más claro no?

Una revista editada por Kent Beck

2009-07-02T07:22:00.001-03:00

Salió una revista on-line editada por Kent Beck. Está en: http://pragprog.com/magazines

Quiz: ¿Cómo mejorar esta clase?

2009-07-01T10:55:00.002-03:00

Que tal,
les dejo un problema para pensar, no es muy largo ni difícil, con 10 minutos imagino que pueden encontrar la manera de resolverlo. El problema es el siguiente: hay que mejorar el código de la clase MouseOverHandler que se encuentra en Squeak o Pharo, en particular el método #processMouseOver: anEvent.
El motivo por el cual seleccioné este problema se debe a que últimamente en la imagen de Pharo en condiciones aún no encontradas, el método #noticeMouseOver: aMorph event: anEvent envía el mensaje #includes: a nil.
Lo interesante del problema es:
1) Entender como funcionan las instancias de esta clase
2) Encontrar el motivo de por qué funciona incorrectamente el mensaje #noticeMouseOver: aMorph event: anEvent
3) Pensar cómo se puede generar información que confirme lo encontrado en el punto 2
4) El objetivo de este post, mejorar el diseño de esta clase.
Acá está el código por si no tienen ganas de abrir un Squeak/Pharo.
---------------------------
Object subclass: #MouseOverHandler
instanceVariableNames: 'mouseOverMorphs enteredMorphs overMorphs leftMorphs'
classVariableNames: ''
poolDictionaries: ''
category: 'Morphic-Events'
---------------------------
initialize
super initialize.
mouseOverMorphs := #().
---------------------------
processMouseOver: anEvent
"Re-establish the z-order for all morphs wrt the given event"

| hand localEvt focus evt |
hand := anEvent hand.
leftMorphs := mouseOverMorphs asIdentitySet.
"Assume some coherence for the number of objects in over list"
overMorphs := WriteStream on: (Array new: leftMorphs size).
enteredMorphs := WriteStream on: #().
"Now go looking for eventual mouse overs"
hand handleEvent: anEvent asMouseOver.
"Get out early if there's no change"
(leftMorphs isEmpty and: [enteredMorphs position = 0])
ifTrue: [^leftMorphs := enteredMorphs := overMorphs := nil].
focus := hand mouseFocus.
"Send #mouseLeave as appropriate"
evt := anEvent asMouseLeave.
"Keep the order of the left morphs by recreating it from the mouseOverMorphs"
leftMorphs size > 1
ifTrue: [leftMorphs := mouseOverMorphs select: [:m | leftMorphs includes: m]].
leftMorphs do:
[:m |
(m == focus or: [m hasOwner: focus])
ifTrue:
[localEvt := evt transformedBy: (m transformedFrom: hand).
m handleEvent: localEvt]
ifFalse: [overMorphs nextPut: m]].
"Send #mouseEnter as appropriate"
evt := anEvent asMouseEnter.
enteredMorphs ifNil:
["inform: was called in handleEvent:"

^leftMorphs := enteredMorphs := overMorphs := nil].
enteredMorphs := enteredMorphs contents.
enteredMorphs reverseDo:
[:m |
(m == focus or: [m hasOwner: focus])
ifTrue:
[localEvt := evt transformedBy: (m transformedFrom: hand).
m handleEvent: localEvt]].
"And remember the over list"
overMorphs ifNil:
["inform: was called in handleEvent:"

^leftMorphs := enteredMorphs := overMorphs := nil].
mouseOverMorphs := overMorphs contents.
leftMorphs := enteredMorphs := overMorphs := nil
---------------------------
noticeMouseOver: aMorph event: anEvent
"Remember that the mouse is currently over some morph"
(leftMorphs includes: aMorph)
ifTrue:[leftMorphs remove: aMorph]
ifFalse:[enteredMorphs nextPut: aMorph].
overMorphs nextPut: aMorph.

Alguien está necesitado de dinero...

2009-07-01T10:53:00.002-03:00

Bueno, quién no? pero miren esto:
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=180375524276
Inicialmente me hace pensar en dos cosas:
1) Ya nadie se gana la vida escribiendo libros (o por lo menos libros técnicos)
2) Kent Beck no es muy bueno haciendo negocios :-)
El resto de las posibilidad lo dejo par el ideario colectivo :-)

El sitio está listo!

2009-06-23T08:53:00.004-03:00

Quería comentarles que ya tenemos listo el sitio de Internet, la dirección es http://www.10pines.com/
Aún está en inglés, pero pronto lo pasaremos al castellano.
Espero que les guste! si encuentran algún error o tiene sugerencias, será bienvenido.

Charla en ESUG

2009-05-31T14:40:00.001-03:00

Algunos me preguntaron de que voy a hablar en ESUG. Mi intención es hablar sobre un trabajo de tesis que están haciendo Nicolas Chillo y Gabriel Burnstein que trata de Mutation Testing.... veremos si es aceptado...

Gracias por los comentarios sobre el viaje!

Voy a ESUG!!!

2009-05-22T15:55:00.001-03:00

Si, nuevamente voy a ESUG!!! (www.esug.org)

ESUG es la conferencia de Smalltalk de Europa. Es una conferencia muy linda que tuve la oportunidad de asistir en 2005. Lo interesante es que este año vamos muchos argentinos y la mayoría daremos una charla...

Magritte 2

2009-04-14T13:21:00.002-03:00

Algo que siempre digo y me olvidé de comentar en el post anterior es que "es muy fácil criticar pero difícil hacer". Mis comentarios del post anterior fueron todas crítticas, sin embargo Magritte también tiene cosas muy interesantes como el manejo de mementos para la edición de objetos, la posibilidad de configurar el framework (todo puede ser cambiado, como el container, las descripciones, los componentes), etc.

Una aclaración que me parece necesaria para no parecer siempre negativo.

Magritte

2009-04-14T09:24:00.003-03:00

No voy a escribir sobre arte, no, este post no es sobre René Magritte sino sobre el framework creado por Lukas Renggli para ayudar en el desarrollo de aplicaciones utilizando metraprogramación.

Ayer estuve leyendo bastante sobre el mismo y jugando un poco con él. Es un framework que permite rápidamente obtener una representación visual de objetos del modelo, creando en ellos una serie de descripciones. Por ejemplo, si tenemos la clase Address, creando métodos que se llaman "descriptionXxx" donde Xxx generalmente tienen que ver con los nombres de las variables de instancia, se puede obtener un componente SeaSide o Morph para instancias de Address.

Veamos un ejemplo del tutorial que ofrecen:

descriptionStreet

^ MAStringDescription new

autoAccessor: 'street';

label: 'Street';

priority: 10;

yourself

Esta sería la descripción para la variable de instancia 'street' de Address (o MAAdressModel como se llama en el tutorial... un nombre poco feliz desde mi punto de vista puesto que la palabra Model está de más). Veamos que significa cada cosa:

1) autoAccessor: Significa que se accederá a 'street' con los mensajes #street y #street:, si no existen los creará, pero no solo eso, creará también la var. de instancia si no existe.

2) label: String que se utilizará para identificar el entry field de Street

3) priority: Posición en la que debe aparecer el campo en el componente visual. Menos prioridad significa más arriba, más prioridad significa más abajo.

Veamos ahora otra "descripción":

descriptionPlz

^ MANumberDescription new

autoAccessor: 'plz';

label: 'PLZ';

priority: 20;

min: 1000;

max: 9999;

yourself

Este describe el código postal. Más observaciones:

4) Nótese que priority es 20, lo que significa que irá luego de street... no se si notaron que hay 10 números entre el priority de street y este, ¿por qué?, para poder poner componentes visuales entre street y código postal sin necesidad de modificar estos métodos.

5) min: y max: indican los valores numéricos máximos del código postal

Por último, quería mostrar esta "descripción" también:

descriptionCanton

^ MASingleOptionDescription new

options: #( 'Zurich' 'Bern' 'Luzern' 'Uri' 'Schwyz' 'Unterwalden' 'Glarus' 'Zug' 'Freiburg' 'Solothurn' 'Basel' 'Schaffhausen' 'Appenzell' 'St. Gallen' 'Graubunden' 'Aargau' 'Thurgau' 'Ticino' 'Vaud' 'Valais' 'Neuchatel' 'Geneve' 'Jura' );

reference: MAStringDescription new;

autoAccessor: 'canton';

label: 'Canton';

priority: 40;

beSorted;

yourself

Es la utilizada para elegir un canton (provincia). Observaciones:

6) Los distintos cantones están hardcodeados en la descripción

Bien, ahora voy a dar algunas opiniones sobre los puntos que estuvimos viendo:

1) Nunca usaría autoAccessor. No sirve cuando se está desarrollando un app en serio puesto que crearía una variable aún cuando el nombre de la misma está mal escrito, es muy peligroso dejar la creación de variables y métodos a herramientas en vez de hacerlo uno. Por otro lado, si se hace un rename de la variable este "descriptor" no se enteraría... ese es uno de los problemas de este tipo de frameworks, la falta de integración con las herramientas de desarrollo comúnes y también por no estar reificadas las variables en Smalltalk. Para solucionarlo utiliaría #selectorAccessor: o escribiría un test que se asegurará la consistencia de este descriptor.

2) Sobre label. Acá es donde me empieza a gustar menos la cosa. En una clase del modelo (Address) estoy poniendo información sobre que quiero que aparezca en la view, un acoplamiento poco deseado. Además este label podría cambiar de view en view. La solución que proponen es obtener una copia del descriptor y modificar el label para ese caso... hmm, más acoplamiento.

3) y 4) priority: Más acoplamiento. Entre el modelo y la view por estar este número en un método del modelo y entre los descriptores mismos por utilizar entre ellos un número mayor que el otro para indicar que va después. Para el primer caso, ¿qué le importa al modelo en que posición se va a mostrar el componente visual para alguna de sus variables de instancias?. Para el segundo caso, ¿no sería mejor tener un objeto que indique la secuencia en la que debe ir cada componente visual? una OrderedCollection de descriptores por ejemplo?. De esa manera el hecho de la posición no estaría acoplado al descriptor sino que sería responsabilidad de otro objeto. Por otro lado, ¿por qué dejar 10 número entre uno y otro? ¿no se pueden usar número reales? Si se puediesen poner números no enteros (cosa que no probé aún) no habría necesidad de dejar 10 números entre una descripción y otra puesto que todos sabemos que siempre hay números entre dos números reales.

5) Que las validaciones de los objetos no estén con los mismos no me parece una buena solución. Si el código postal de Suiza tiene que estar entre 1000 y 9999, debería existir una abstracción para dicho ente que además debería encargarse de realizar esta validación. Separar la validación del objeto en si mismo no representa correctamente el ente que se está modelando, lo cual trae problemas a posteriori, como por ejemplo cargar direcciones desde un archivo. En ese caso, ¿quién valida que el código postal sea un número entre 1000 y 9999?, ¿o para hacerlo también tengo que usar Magritte?. Digamos que uso Magritte, ¿qué pasa entonces cuando creo una dirección desde el workspace? no voy a usar Magritte para eso...

6) Por más que es un ejemplo y los cantones están hardcodeados por ello (imagino), supongamos que no, ¿cómo los obtendría?. Tendría que colaborar con el objeto encargado de mantener la lista de cantones válidos. Algunos propondría utilizar una clase, "Cantones" por ejemplo que tenga una class variable con las cantones válidos, una porquería desde mi punto de vista. Si vamos a hacer eso utilicemos una variable global, "Cantones" y listo, ¿para qué crear una clase?. Pero sea una u otra la solución, el acoplamiento que se crea es enorme! ahora esa descripción no va a funcionar con otra cosa que no sea esa lista de cantones! que además está referenciado desde un método de la clase Address! o sea que no puedo usar Address en otro contexto!... una muy mala solución y que surge de la necesidad de indicarle los cantones en la "descripción" en vez de indicarselos a la view directamente al momento de construirla.

En fin, mi conclusión por ahora es que Magritte, como todo este tipo de frameworks, sirve para hacer una app rápido y chiquita si no te importa mucho el diseño y cómo la vas a mantener. Ahora, si querés hacer una app en serio o no utilices Magritte o hay que tomar algunas decisiones como:

1) Que las descripciones no estén en el modelo

2) Que el orden de los componentes estén en otro objeto y sea configurable por view

3) Que la validaciones no estén en las descripciones

4) Que no exista acoplamiento entre la descripción y los elememtos que muestran las views

Una última cosa que acabo de acordarme, me parece una decisión muy poco feliz la que tomaron de que todos los objetos sepan responder #description para devolver una colección de descriptores de Magritte. ¿por qué no lo llamaron #magritteDescription o algo así y de esa manera no impedían utilizar ese mensaje en el modelo para cosas que tengan que ver con el modelo?.... en fin.

Voy a mandar un mail a la lista de Magritte con estos comentario para ver que soluciones/respuesta obtengo. Los mantendré informados.

Mapeo Objeto-Relacional

2009-04-14T09:22:00.002-03:00

El mapeo de objetos a base de datos relacionales es un tema bastante complicado y estudiado en nuestra profesión, aunque siempre aparecen nuevos frameworks que supuestamente solucionan los problemas que se generan en este mapeo, pero que finalmente crean nuevos... en fin, vamos a tener que esperar mucho hasta que la gente se de cuenta que el problema es de fondo y no de forma... mientras tanto les paso un link que me recomendaron sobre este tema:

http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx

Nueva Etapa Laboral

2009-04-03T10:32:00.003-03:00

Aquellos que tengan Facebook habrán visto que a principio de semana puse que estoy empezando una nueva etapa laboral... no comenté muchos detalles allí, así que quería utilizar este medio para aclarar un poco más de que se trata.

Con unos amigos estamos armando una empresa en la que ofrecemos servicios de desarrollo de aplicaciones complejas, capacitación y coaching de objetos, patrones, frameworks, tdd, metodologías ágiles y diagnósticos sobre código y diseños de aplicaciones existentes.

No creo que sea necesario explicar a que me refiero con aplicaciones complejas o capacitación. Si quizá un poco sobre a que me refiero con coaching. Cuando capacitamos, no nos interesa únicamente dar los cursos, sino hacer un seguimiento con la gente una vez terminados. Lo que ofrecemos es realizar pair programming con los asistentes para que realmente apliquen lo que enseñamos. Esta es la única manera de agregar valor en la capacitación y que realmente la gente aprenda.

Seguramente también sea necesario explicar a que me refiero con "diagnóstico de código y diseño". Bueno, ustedes saben que hay muchas empresas que ofrecen consultoría para ayudar a mejorar los procesos de desarrollo, implementar un sistema de SCM, etc, pero pocas (sino ninguna) se mete a bailar con la más fea, donde realmente hay que moverse y demostrar experiencia y conocimiento; pocas se meten en el código y el diseño de un sistema existente y ofrecen un diagnóstico sobre cómo está hecho y cómo se lo puede mejorar. A esto es lo que apuntamos con este servicio, la idea es arremangarnos, ver el diseño y el código del sistema que les parezca importante y darles un diagnóstico del mismo. Este diagnóstico sería similar a lo que nos da un médico clínico cuando lo visitamos. Nos dice en qué andamos mal y qué deberíamos hacer para mejorar, etc; nosotros haremos lo mismo. Ver un sistema, analizar su diseño, cómo está codificado para luego generar un informe que indique su "grado de salud" (qué tan enfermo está, cuanto va a vivir, qué se puede hacer para alargar su vida, etc). Sinceramente no conozco empresa que ofrezca este servicio puesto que es muy difícil de realizar y hay que estar muy capacitado para obtener buenos resultados. Nosotros tenemos la capacidad y conocimiento para hacerlo y es un valor agregado muy importante que ofrecemos.

Bueno, basta de marketing por un rato.... Respecto del blog, voy a intentar postear más seguido ahora, aunque en realidad este cambio aún me está requiriendo más tiempo del que esperaba, imagino que cambirá en unas semanas.

Por otro lado no quiero dejar pasar la oportunidad de agradecer y mencionar lo feliz que fue y es para mi trabjar en Mercap, he aprendido muchísimo a nivel técnico y humano, hemos tenido grupos de personas muy lindos y hemos logrado cosas que no he visto en ninguna otra empresa. De hecho, voy a seguir trabajando algunas horas en Mercap puesto que es una empresa que realmente amo, por la gente, por lo que hacemos y por lo que hicimos. Por eso quería agradecer también por este medio a Alejandro (dueño de Mercap) por la oportunidad que me da de seguir formando parte de la empresa y apoyarme en este nuevo emprendimiento.

En fin, ya cerrando y volviendo al marketing :-), si alguien está interesado es saber un poco más qué ofrecemos, tiene interés en conocer precios o contratar algún servicio, no deje de avisarme!

Ingeniero o Arquitecto

2009-03-19T17:20:00.002-03:00

Son muchas las comparaciones que se hacen entre el desarrollo de software y la arquitectura o la construcción de edificios/casas/etc., de hecho el término "Arquitecto de Software" proviene de dicha disciplina. En este post voy a tratar de explicar por qué me parece que está mal utilizado este término (como muchas otras analogías que se hacen con esa disciplina).

Este tema me vino a la cabeza luego de la clase de ayer en la UBA cuando conversábamos sobre qué significa que un modelo sea bueno. Recuerden que desde nuestro punto de vista, el software es un "modelo computable" de un dominio de problema de la realidad, por lo tanto debe cumplir con ciertas características para ser un buen software. Por un lado, debe cumplir con las mismas características con la que se juzga cualquier modelo, no solo los computables, esto básicamente significa que pueda representar correctamente lo que modela. Pero también existen características que debe cumplir por ser computable que tienen que ver con performance, uso de recursos, etc.

Es interesante ver que generalmente en las carreras de sistemas nos enseñan como lograr buenas características computables de los programas que realizamos como que sean performeantes, etc., pero rara vez existen materias en donde nos enseñen a crear un buen modelo. Justamente este tema es el que ataca nuestra materia.

¿Qué tiene que ver todo esto con los arquitectos?, bueno, el rol que "actualmente" vela porque un sistema tenga buenos atributos computables, es lo que llamamos "Arquitecto". Es él quien debe asegurar que el sistema sea performeante, que escale bien, etc. Es el que se encarga de los temas de infraestructura del sistema.

Analizando un poco el mundo de la construcción de edificios/casas/etc., se puede ver que el encargado de asegurar que estas construcciones "no se caigan", que las estructuras sean las correctas, etc., o sea que todo lo relacionado con la infraestructura sea correcto, no es el arquitecto si no el ingeniero civil. De hecho, los planos de estructura, vigas, etc. deben estar hechos por un ingeniero civil y no por un arquitecto! El arquitecto generalmente se ocupa de hacer que el edificio/casa/etc. sea funcional, "lindo", aproveche bien los espacios, etc., todas características que no tienen nada que ver con la infraestructura en si... (Los arquitectos son también quienes generalmente llevan el proyecto adelante, pero ese es otro tema).

Por lo tanto, si lo pensamos detenidamente y no me equivoque en las responsabilidades del arquitecto y el ingeniero civil, utilizar la palabra Arquitecto dentro de nuestra profesión para indicar el rol de la persona que se encarga de definir la infraestructura del sistema parece ser equivocado, puesto que de donde proviene, esa palabra no es utilizada para dicho rol. El nombre utilizado para nombrar a la persona que cumple ese rol es Ingeniero Civil, por lo tanto sería mejor llamar al rol similar en el desarrollo de software "Ingeniero", pero claro, dicho término tiene otra connotación en nuestra disciplina y está más relacionado con la persona que se encarga de construir un sistema, que el sea usable y por que no, llevar adelante un proyecto... ups! pero eso es lo que hace un arquitecto en el ámbito la construcción!

¿Me estoy perdiendo algo o realmente estas palabras están mal usadas en nuestra profesión? ¿No deberíamos llamar ingeniero al arquitecto de software y viceversa? ¿qué les parece?

Jornadas Agiles

2009-03-12T17:01:00.001-02:00

El fin de semana pasado se realizaron unas Jornadas Agiles utilizando una organización muy interesante denominada Open Space.

La idea de esta técnica es que los participantes mismos decidan como será la jornada, decidan los temas y la agenda de cómo serán tratados. Inicialmente parece medio loco no?, algo que va en contra de la idea de tener todo organizado de entrada y bien definido, una característica que buscamos quizá por una cuestión de enseñanza y no por vivencias propias.

Les comento que la organización terminó siendo buenísima. La gente propuso los temas, la agenda se armó de manera colaborativa y no llevó más de 1 hora y media hacerlo con 100 persona y con 25 temas en total (creo). Pero lo más importante aún, desde mi punto de vista, es que no hubo exposiciones (salvo algunas como la mía que intenté hacerla más colaborativa y no lo logré) sino reuniones donde todos opinaron y colaboraron, lo cual generó muchas ganas de participar y un ambiente muy motivador... esta motivación me hace acordar a cuando se realiza pair-programming o sesiones de diseño grupales.

En fin, se utilizó una técnica que tiene mucho que ver con el espíritu ágil y que tenemos ganas de utilizarla por lo menos para un día en el congreso de Smalltalks de este año... así que vayan pensando temas!

Sesiones de Diseño II - TDD en Vivo

2009-03-12T15:30:00.001-02:00

Ya vamos por la tercer sesión de diseño y realmente ha sido muy interesante. (Un amigo, JP, suguirió que debería llamar al post "TDD en Vivo", por eso lo adjunté al nombre).

Es muy interesante ver como cada grupo fue tomando distintos caminos y concentrándose en distintos problemas. Sin embargo hubo una característica común que permitió avanzar rápidamente en todos los casos y que soluciona el error principal que se cometió en la primer sesión: se empezaron a hacer test más sencillos y cortos. Fue muy interesante ver cómo al hacer tests más cortos se lograron mejores resultados y la gente se motivó mucho más. Aunque el avance esencial haya sido poco, el hecho de haber creado muchos tests y que den verde indudablemente afectó la moral del equipo. Es algo que Kent Beck ya había comentado cuando propuso esta técnica y que nuevamente estamos confirmando.

Por otro lado es muy interesante ver que los diseños en general no varían mucho, hay diferencias de nombres pero el problema está siendo resuelto de manera similar en la mayoría de los casos por los distintos grupos. También fue muy interesante ver con un grupo, como se entendió mejor y hasta se simplificó partes de código muy complejas simplemente factorizandolas con un extract method. Nuevamente hacer extract method y estar obligado nombrar (darle un significado) a un conjunto de colaboraciones difíciles de entender o poco declarativas, ha demostrado ser una técnica muy valiosa.

Los mantendré informados!

The real crisis? We stopped being wise (Barry Schwartz)

2009-03-12T15:27:00.002-02:00

Hace unas semanas hubo una charla muy interesante de Barry Schwartz donde comenta lo importante de ser "inteligentes" por más de que existan "métodos" o "procesos" que nos digan cómo tenemos que trabajar o actuar. Un charla imperdible: http://www.ted.com/talks/barry_schwartz_on_our_loss_of_wisdom.html

Lunes 16/03, 17:00 hrs: Defensa Tesis de Satori: un Ambiente de Aprendizaje de Objetos

2009-03-04T12:03:00.000-02:00

Invitamos a todos a la defensa de la siguiente tesis de licenciatura, que

se llevará a cabo el Lunes 16 de Marzo a las 17:00 hrs, FCEyN, aula a

confirmar:

Título: "Satori: un Ambiente de Aprendizaje de Objetos"

Alumnos: Burella, Juan y Olivero, Fernando

Director: Hernán Wilkinson

Jurados: Máximo Prieto, Gabriela Arévalo

--------------------------------------------------------------------

Resumen

El paradigma orientado a objetos es actualmente uno de los paradigmas de desarrollo más utilizados en la industria y en la educación, hecho que determina la importancia de su enseñanza. Se puede afirmar que a pesar de haber transcurrido varias décadas desde su aparición, su enseñanza aún genera desafíos pedagógicos, los cuales se ven influenciados por condiciones externas que dificultan la generación de los resultados esperados. Estos inconvenientes no son inherentes al paradigma sino que, en la mayoría de los casos, son manifestaciones de las carencias que existen en las técnicas y herramientas utilizadas para enseñarlo.

En este trabajo se han analizado varios ambientes, entornos y herramientas utilizados actualmente para su enseñanza, documentando los beneficios y déficits que poseen para cumplir con los objetivos que, según nuestro punto de vista, deben cumplir para tener éxito en la transmisión de este paradigma. Debido a los déficits encontrados, es que vimos la necesidad de crear un nuevo ambiente de aprendizaje, lo cual nos permitió simultáneamente detectar una serie de requerimientos que entendemos estos ambientes deben satisfacer.

Satori es por lo tanto el resultado de este trabajo de investigación y desarrollo, al cual lo podemos considerar un ambiente de objetos "puro". Éste, reifica cada uno de los conceptos básicos del paradigma e intenta reflejarlos de la forma más simple y directa posible. Incorpora, desde su concepción, características que pretenden promover la exploración y manipulación como metodología de adquisición de conocimiento y su modalidad de uso expresa la metáfora más importante del paradigma: objetos que colaboran entre sí enviándose mensajes. De esta manera los usuarios del ambiente pueden llevarse un panorama global de qué es el Paradigma Orientado a Objetos, reconociendo a los objetos y los mensajes como las entidades fundamentales.

El ambiente de aprendizaje de objetos Satori, ha sido además desarrollado en un sistema tridimensional colaborativo denominado Croquet. Esto permitió la representación en tres dimensiones de los elementos básicos del paradigma, ofreciendo por lo tanto herramientas de inspección y manipulación naturales, principios básicos del modelo pedagógico constructivista. Ofrece también todas las herramientas necesarias para la colaboración virtual entre personas, facilitando y permitiendo compartir el conocimiento adquirido durante el aprendizaje.

Sesiones de Diseño en Mercap

2009-02-27T16:54:00.001-02:00

Esta semana retomamos en Mercap algo que llamamos "sesiones de diseño". La idea es juntarnos en grupos de 4 o 5 personas y resolver de manera completa un problema utilizando TDD, en vivo, con una máquina y proyector.

El motivo de hacer "coding" en vivo usando TDD en vez de solo diagramas en un pizarrón tiene que ver con el resultado que se obtiene en ambos casos. Hacer diagramas en un pizarrón está bien para hacer algo rápido y hasta a veces incompleto, pero como ya sabemos, cuando hay que programar la solución, hay que tener en cuenta todos los detalles, hay que formalizar lo que pensamos y es en estos casos donde se aprende más. Esto me hace acordar la frase "el diablo está en los detalles..." bueno, acá no es el diablo pero sí hay temas muy interesantes que surgen al hacerlo

Por cuestiones de responsabilidades no hacemos que estas reuniones duren más de una hora y media y tratamos de que los problemas no tengan que ver directamente con el negocio en el cual trabajamos para despejar un poco la mente de los problemas del día a día.

La verdad que es muy interesante hacerlo y muy enriquecedor. Desde el punto de vista pedagógico es interesante ver la mecánica de cada grupo, las ideas distintas y similares, etc. También vamos a comparar los resultados de cada grupo para aprender de las diferencias.

Hasta ahora la conclusión más interesante que saqué salió de un error que cometieron todos los grupos y fue que el primer test que hicieron fue muy complejo, no siguió el espíritu de TDD, de hecho llevó casi una hora escribirlo y en dos grupos no logramos hacerlo funcionar en el tiempo de la sesión. Pero también es verdad a que se debió por el enunciado del problema, en donde el primer caso planteado era complejo.

Otra diferencia interesante fue como un grupo generalizó mucho más de entrada que el resto y fue justamente este grupo el que menos logró hacer finalmente, como era de esperarse.

Es bueno recordar que TDD nos pide hacer iteraciones chiquitas, tratar de tener un "verde" lo más rápido posible, y esto tiene que ver más que nada por una cuestión psicológica... ver que avanzamos nos mantiene contentos e inspirados.

La semana que viene veremos como sigue la cosa. Voy a tratar de seguir posteando las conclusiones que me resulten interesantes.

Mock objects considered harmful (sometimes) [1]

2009-02-25T18:16:00.003-02:00

Estuve leyendo un poco más sobre BDD y caí en estos artículos que explican como hacer BDD con RSpec en Ruby:

http://www.oreillynet.com/pub/a/ruby/2007/08/09/behavior-driven-development-using-ruby-part-1.html

http://www.oreillynet.com/pub/a/ruby/2007/08/30/behavior-driven-development-using-ruby-part-2.html

El segundo es más interesante que el primero. Si tienen un tiempo léanlo antes de seguir, por lo menos la parte final a partir de la cual crea la clase Game para representar el juego (Sección "Indroducing Mock Objects vis the Game Class"). Por favor, analicen críticamente el diseño que propone y los test que hace antes de seguir (por supuesto que pueden seguir leyendo si quieren, pero seguramente van a entender mejor lo que digo si lo leen).

Bueno, si lo leyeron y analizaron, deberían tener algunas críticas, ¿no?. Yo tengo un par que me parecen muy importantes, es más una hasta me hizo (y hace) dudar sobre la capacidad y experiencia de la persona que escribió pero voy a tratar de no ser muy duro puesto que es muy fácil criticar y muy difícil hacer. (Si llegaron hasta acá y se están preguntando que tiene que ver todo esto con el título, no desesperen, ya llega).

La primer critica que tengo es el acoplamiento que tienen los objetos instancias de Game[2] con la UI. Ver este acoplamiento me hace creer que la persona que escribió el artículo no conoce MCV (Model View Controller), el primer framework para desarrollar aplicaciones visuales (me atrevería a decir el primer framework) y del que se han derivado muchos patrones (si leyeron el libro de Design Patterns saben a que me refiero).

Una de las reglas de diseño que MVC "impone" es que el modelo nunca debe conocer la UI. La UI es un consumidor del modelo y el modelo únicamente provee comportamiento que luego las ventanas, views, etc. usarán para mostrarlo. En la solución planteada por G.Brown, objetos instancias de Game (que son objetos del modelo) conocen una UI, de la cual obtiene información como quienes son los jugadores o de cuantos puntos es el tablero. Este acoplamiento desde mi punto de vista es innecesario y puede ser resuelto fácilmente pasándole esa información a Game cada vez que se crea una instancia. O sea, la UI una vez que tiene toda la info y el usuario presionan el botón "Jugar" (o como se llame), crearía una instancia de Game indicándole quienes son los jugadores y cuantos puntos tiene el tablero, algo así:

playPushed

....

game := Game playedBy: (Array with: 'Juan' with: 'Pepe') withSizeOf: 10.

....

De esta manera no existiría ningún acoplamiento entre Game y la UI, de hecho cualquier objeto podría crear un Game, como por ejemplo un test. Lo bueno de esta solución es que tampoco es necesario usar un mock para simular la UI (por no estar esta acoplada con Game), permite que nos concentrarnos en el modelo y que no tengamos que "adelantarnos" y "suponer" cual será el protocolo de la UI. So far, la primer crítica. Primera conclusión, seguir los principios de MVC! Segunda conclusión: El mock de UI no fue necesario

Paso a la segunda crítica: En el ejemplo del paso 15, se puede ver que se redefine el mensaje de construcción de instancia de Grid para devolver un mock que la simule. Según lo que comenta G. Brown, hacerlo evita que se tenga que usar Grid o crear instancias de esta clase "innecesariamente". No quiero sonar rudo, pero me parece un pésimo ejemplo y una muy mala conclusión. En primer lugar porque está rompiendo el encapsulamiento de Game al redefinir el comportamiento del mensaje de construcción de instancias de Grid, y lo está rompiendo porque sabe que Game "usa" Grid para representar el tablero. ¿Qué pasaría si Game decide utilizar otro objeto para representar el tablero? El test dejaría de funcionar. Claramente el hecho de que Game colabore con Grid es una decisión de Game que a nadie debería importarle y menos a un test!. Haberlo hecho hizo que el test se convirtiera en uno de "caja blanca", con todas las desventajas que sabemos que eso tiene.

Lo mismo sucede con el mock que llama box_set y que utiliza para realizar movimientos por medio del mensaje #stub_move. Lo que está haciendo ahí en definitiva es simular lo que debería suceder en los objetos del modelo del juego, ¿pero para qué? ¿no se supone que estamos testeando el modelo? Además, si el mismo ya está hecho, ¿para qué lo simulamos? (además de romper nuevamente el encapsulamiento...). Devuelta, criticar es fácil, por lo tanto para no ser uno más del montón hay que ofrecer una solución, y para mi la solución acá es simple: ¡utilizar Game sin ningún mock! ¿Cuál es el problema de decirle a una instancia de Game que se unieron dos puntos tantas veces como sea necesario para crear el estado del juego sobre el cual se quiere testear (o empezar a testear) su comportamiento?

Bien, ahora si voy al título del post. Yo me pregunto, ¿G. Brown realmente cree que hacer esto está bueno o simplemente lo hace para utilizar (y mostrar como utilizar) mocks? Si el motivo fuese mostrar como utilizar los mocks, no me parece un buen ejemplo y hasta diría que es destructivo porque como ya sabemos, los seres humanos aprendemos de ejemplos y no quiero ni pensar todos los pobres programadores que están haciendo tests utilizando este ejemplo como guía. Si por el contrario lo hace así porque cree que es un buen diseño, mi pregunta es: ¿por qué cree que es un buen diseño? Una posible explicación es, como puse más arriba, que no conozca de MVC o de encapsulamiento, lo cual sería una lástima por todos los que lo leen; pero otra posible explicación, y es la que me motivó a poner el título del post y que veo muy a menudo últimamente, tiene que ver con la famosa frase que dice: "cuando lo único que conoces es un martillo, todos los problemas se parecen a un clavo". En este caso el martillo son los mock objects y que todo se parezca a un clavo son las soluciones que ofrece en su diseño usándolos. Lamentablemente en nuestra profesión es muy común ver como cuando aparece algo nuevo (o que parece nuevo) se lo empieza utilizar sin realizar el más mínimo análisis crítico de si se lo está usando correctamente; es nuevo, es cool, ¡usémoslo!

Eso es lo que veo muchas veces con los mocks, se los sobre-utiliza generando ejemplos perjudiciales y problemas de mantenimiento en los tests. En el ejemplo del mock para Grid: ¿qué pasaría con el test si se decide modificar el nombre del mensaje de creación de instancia de Grid? Claramente dejaría de funcionar y simplemente por el hecho de haber roto el encapsulamiento.

¿Cuándo utilizar un mock object entonces? Por lo menos para mi en este post me quedó claro que existen dos casos donde no hay que usarlos:

1) Para resolver problemas intrínsecos de diseño (como el acoplamiento de Game y UI)

2) Cuando se rompe el encapsulamiento (como el caso de Game y Grid)

En los tests, según mi experiencia, hay que usar mock objects para representar objetos que están por "afuera" del objeto que se está testeando y que este debe colaborar con para poder llevar adelante una responsabilidad. Pero mi consejo es, antes de usar un mock asegúrense que no pueden usar un objeto "de verdad"...

[1] Me imagino que todos deben conocer el famoso paper de Dijstra, "Goto considered harmful" que para algunos marcó el hito del inicio de la programación estructurada. De la misma manera que ya el "... driven development" está siendo sobre utilizado, me tomé el atrevimiento de sobre-utilizar el "... considered harmful" para llamar la atención. Espero por lo menos haber sido fiel al espíritu del artículo de Dijstra...

[2] Dicho sea de paso, Game no me parece un buen nombre para esta clase. Debería indicar por lo menos qué juego es.

Qi4j and state modeling

2009-02-20T08:48:00.001-02:00

Un amigo me pasó este link sobre algo que están haciendo en Java: http://www.jroller.com/rickard/entry/qi4j_and_state_modeling

Es interesante, pero es algo que nuevamente refleja las complicaciones que tienen en Java para poder hacer cosas sencillas.

Primero: el problema que tienen por usar POJOs (Plain Java Objects, lo que comúnmente hacemos en Smalltalk) puesto que lo escrito es muy distinto a lo que se "habla" en el dominio. Me alegro de escuchar ese argumento!, quiere decir que la gente está empezando a apreciar lo que venimos diciendo por años y es la importancia de hablar "el mismo idioma" con el experto del dominio, el problema es que no se dan cuenta que el "problema" está en la sintaxis y diseño de Java y que hay otros lenguajes, como Smalltalk, donde eso no sucede. O sea, el problema no está en usar Plain Objects, el problema esta en usar Plain Objects con la sintaxis de Java. Justamente debido a la sintaxis de Smalltalk es que a nadie se le ocurriría hacer algo como lo que está haciendo esta gente.

Segundo: Habla de que quieren tener un lenguaje similar al del dominio del problema, pero sin embargo usar un keyword que seguro nadie del dominio entiende como @UseDefault. ¿Qué significa eso para un experto del dominio?, seguro nada

Tercero: Me vuelven loco los ejemplo pelotudos de uso de interface como este en donde extrae la propiedades de ser "nombrable" y crea la interface "Nameable". Y perdón por la palabra pelotudo, pero la verdad este tipo de ejemplos lo único que hacen es complicarle la vida al que aún está aprendiendo. Uno de los motivos es porque esto sucede al final de un desarrollo, no mientras se está desarrollado y entendiendo el dominio. De este ejemplo se puede sacar la conclusión de que cualquier cosa que tenga sentido se puede poner en una interface por que si, sin analizar que hacerlo puede agregar complejidad al diseño! ¿qué otra cosa que no sea un ser humano puede tener nombre y apellido? Nada! Entonce, ¿para que factorizarlo así?. Por otro lado, el motivo por el cual dice que es bueno hacerlo es porque ahora podrán preguntar si "x instanceOf Nameable"... parece que de polimorfismo poco esta persona. Justamente preguntar por el tipo de un objeto es el claro ejemplo de que aún están pensado en "estructurado" y no en objetos. No más palabras sobre esto porque me está subiendo la temperatura

Tercero: Dice que cuando modelan le gusta hablar de propiedades, relaciones, etc., pero en ningún momento veo que hable de comportamiento! lo más importante! Si solo le interesa propiedades y relaciones, ¿por qué no hace un DER?. Nuevamente, un ejemplo de que no lograron entender el paradigma de objetos y están usando técnicas de otros paradigmas.

Cuarto: No entiendo por qué separan Entity de Value. Es algo que ya lo vi varias veces y el motivo es que los Values son inmutables, las entities no. Nunca escuche esta separación en filosofía ni en epistemología ni en nada similar, solo en nuestra profesión y por lo tanto me parece que es un problema del dominio computable... si es así, ¿por qué confundirlo a experto del dominio con esto?.

Quinto: El ejemplo del método listName() en la sección Privitanzing State me mató! jaja. Más me mató la frase siguiente: "Heat huh?". ¿Neat?, yo diría "a mess man!" a mess que rompe el encapsulamiento y que para perdir un nombre tengo que envier el mensaje "name()" y luego "get()"! o sea, primero tengo algo que no es lo que quiero (seguramente será un Value o Entity) y luego le pido su "valor" que es lo que realmente quiero... ¿no debería ser al revés en todo caso para que sea más simple?... en fin.

Algo que me gusto, es que como vine escribiendo últimamente, evitan usar nil (o null en java). Parece que esta idea está empezando a tomar forma simultáneamente en otras comunidades lo cual es bueno. Otra cosa interesante es que reifican las relaciones (algo esperable también por la orientación al paradigma relacional que tienen), algo que también veo como importante pero que lamentablemente nunca tuve la oportunidad de probarlo seriamente.

Conclusión, que lástima ver el tiempo que se pierde en tratar de resolver problemas no esenciales (reinventar la rueda pinchada como dice Alan Kay) creados a partir de decisiones de diseño incorrectas (en este caso decisiones del diseño del lenguaje Java).

Tip 3: Objects must be valid since its creation time

2009-02-18T18:55:00.000-02:00

Este tip de diseño del que hablé en mi presentación de Smalltalks 2008 es muy importante de mi punto de vista. La idea que trata de transmitir este tip es que cuando se crea un objeto, el mismo debe ser válido. Hay motivos teóricos y prácticos para demostrar por qué es un tip importante. Voy a empezar por el teórico.

Si están de acuerdo con la visión de que un objeto es una representación de un ente de la realidad, es muy importante preguntarse a partir de qué momento ese objeto representa el ente en cuestión. Y la respuesta sería (rápidamente) ¡cuanto antes mejor!, sino mientras tanto tendremos un objeto que no representa nada, un objeto que no puede cumplir con sus responsabilidad, un objeto que puede traer problemas. Este tip se relaciona bastante con el anterior en el cual comentaba la importancia de identificar claramente cuál es la identidad del ente representada en el objeto puesto que el objeto puede representar el ente una vez que la identidad del mismo es modelada por el objeto. Esto ya parece un trabalenguas. Voy a dar un ejemplo para tratar de transmitir la idea más claramente por lo que ahora nos iremos metiendo en los motivos prácticos.

Supongamos que tenemos que modelar una tasa de interés. En cualquier libro financiero verán que una tasa de interés es representada por un porcentaje durante cierto tiempo. Es común por lo tanto encontrarse con tasas de interés del 10% anual, o del 5% mensual. Una tasa de interés del 10% anual significa que si invertimos nuestro capital por un año, al finalizar el año recibiremos un 10% de nuestro capital como "premio" por haber hecho la inversión (estoy suponiendo que no hay pago intermedios, etc). La tasa de interés es presentada algebraicamente como la división del porcentaje por el tiempo. Esto se puede ver claramente cuando escribimos la fórmula de interés:

interés = capitalInvertido * tasaDeInterés * tiempoDeInversión donde tasaDeInterés = porcentaje / tiempo

por lo tanto:

interés = capitalInvertido * porcentaje / tiempo * tiempoDeInversión

Por lo tanto si capitalInvertido es 100 $, la tasa es 10% anual e invertimos por 2 años, tendríamos:

interés = 100 $ * 0.1 / 1 año * 2 años --> años con años se simplifican y tenemos = 100 $ * 0.1 * 2 = 20 $

Volviendo a nuestro modelo, podemos usar la clase "InterestRate" para modelar tasas de interés, la cual sabrá responder mensajes de creación de instancia como #of: aPercentage every: aTimeMeasure, o mejor aún #yearlyOf: aPercentage. Veamos un ejemplo en código:

InterestRate of: 10 % every: 1 year --> Devuelve una tasa de interés del 10% anual

InterestRate yearlyOf: 10% --> Hace lo mismo que la colaboración anterior

Ahora bien, este tip dice que el objeto que los objetos deben ser válidos desde el momento que se crean, esto significa para este ejemplo que cuando se crea una tasa de interés la misma debe ser válida. ¿Qué tasa de interés no sería válida? (una pregunta medio retorcida puesto que en realidad si no es válida no existe como tasa de interés, pero creo que se entiende no?). Claramente una tasa de interés no válida es aquella cuyo lapso de tiempo sea 0 (0 años, 0 meses, 0 días, etc. ¿recuerdan mi comentario sobre la igualdad del 0 con las medidas?) o cuyo porcentaje o tiempo sea negativo. El primer caso se puede deducir fácilmente puesto que de lo contrario el valor representado por una tasa de interés (que es la división del porcentaje por el lapso de tiempo como vimos más arriba) no se podría calcular por estar dividiendo por 0. El segundo tiene que ver más que nada con reglas de negocio, no existen tasas de interés negativas o con tiempos de inversión negativo! no tiene sentido.

Esto significa que en el mensaje de construcción de instancia de "InterestRate" tenemos que asegurar estas tres pre-condiciones. La manera en que nosotros lo implementamos es la siguiente:

InteresRate class>>of: aPercentage every: aTimeMeasure

self assertPercentageIsPositive: aPercentage.

self assertTermNotZeroOrNegative: aTimeMeasure.

^self new initializeOf: aPercentage every: aTimeMeasurement

Se puede ver claramente que lo primero que se hace es validar que las pre-condiciones de existencia (y fíjense que ya no dije validez) de una tasa de interés se cumplan. Si la validación no es exitósa se generará una excepción, que en nuestro caso será una subclase de InstanceCreationException, indicando que pre-condición no se cumplió.

Fíjense que por haber hecho esto al momento de crear una tasa de interés, es imposible tener tasas de interés inválidas. El concepto de tener objetos inválidos desaparece y de repente solo tengo o no tengo dichos objetos, lo cual podríamos decir que se condice con la realidad puesto que en la misma no existen tasas de interés inválidas, nunca un banco daría una tasa de interés con tiempo 0 o negativo, es impensable. Uno podría decir que -10% anual es una tasa de interés, lo podría escribir en un pizarrón o aún en este blog, pero llamarla tasa de interés es un abuso y hacerlo es simplemente una ilusión que podemos tener puesto que realmente no es una tasa de interés y un experto del dominio nos lo diría de entrada.

El problema de tener objetos válidos o inválidos tiene que ver más que nada con un problema computacional debido a que alguien (persona o computadora) en algún momento debe ingresar los "datos" para crear la tasa de interés. Esto implica que existe un tiempo en el cual se ingresan "datos" y que por lo tanto deben estar en "algún lado" en nuestro modelo durante ese tiempo y también implica que esos datos pueden estar incompletos. Pero entonces ese problema no corresponde ser resuelto por el objeto del modelo, en este caso "InteresRate", sino por aquel que se encarga del ingreso de datos.

Al haber hecho que una tasa de interés no se pueda crear si no es válida, ya no solo podemos asegurar que el usuario nunca creará tasas inválidas sino también que ningún programador lo hará!, si lo hace enseguida nuestro modelo le indicará que se equivocó, lo cual es buenísimo y tiene que ver con otro tip que veremos más adelante que se llama "Fail fast". Otra ventaja es que tenemos las famosas validaciones de negocio, o mal llamadas reglas de negocio en un solo lugar y no dispersas por cualquier lado (la UI, una interfaz batch, etc). Siempre que se cree una tasa de interés, venga de donde venga, la UI, un programador, otra computadora, etc, se realizará este chequeo que nos asegura que nuestros objetos siempre serán.... válidos (pensé en terminar la frase en serán, puesto que si no lo son, no existen que es lo mismo según mi punto de vista a que no son válidos; es como pensar que la palabra "válido" desaparece de mi idioma, deja de tener sentido).

Ustedes podrán preguntar cómo representamos entonces aquellos casos para los cuales la información ingresada es incompleta o no correcta, bueno, por medio de un objeto para tal fin! Por ejemplo, si aplicamos el mismo concepto para un "Deal" podríamos tener una intención de deal (DealIntention) para representar aquel que aún no se sabe si es válido. Esto puede parecer como que generará una explosión de clases pero la realidad no es así. En nuestro caso en lo que respecta a la UI, son los mismos widget o controllers los que se encargan de contener esa información inválida (Este blog ya es muy largo, pero cuando pueda voy a comentar como funciona la UI que hicimos para XTrade porque me parece muy interesante)

Esta característica de tener objetos solo válidos se potencia aún más cuando dichos objetos son inmutables, como el caso de la tasa de interés, o fechas, o medidas, etc. puesto que no habrá manera de que dicho objeto pase a ser inválido con el transcurso del tiempo. Si el objeto es mutable, podemos aplicar lo que mencione y detallaré más adelante como sincronización por copias.

Analizando aún más este tip, veremos que para objetos inmutables estas pre-condiciones se fusionan con el concepto de invariante. Hemos logrado poner en un solo lugar las pre-condiciones de varios métodos y la invariante de un objeto, lo cual me parece muy interesante por haber simplificado esta representación.

Algunos detalles de implementación adcionales:

1) Todos los mensajes de creación de instancia deben en definitiva terminar cayendo en la evaluación de un único método de creación de instancia que es además es que realiza todas las aserciones. Para nuestro ejemplo, #yearlyOf: debería estar implementado así:

InterestRate class>>yearlyOf: aPercentage

^self of: aPercentage every: 1 year

2) Debería haber un solo mensaje de inicialización que es enviado desde un único método de creación de instancias que es el que realiza las aserciones. Esto implica que el mensaje #new enviado a self se realiza en un solo lugar.

3) Se puede reificar aún mejor el concepto de pre-condiciones para luego hacer meta-programación con las mismas y por lo tanto generar documentación automática (para interfaces por ejemplo) o test automáticos como presentó Meyer la semana pasada

Bueno, suficiente por ahora, no tengo ni tiempo de releer lo que escribí así que espero que se pueda leer bien!

Behavior Driven Development

2009-02-18T16:56:00.002-02:00

Estuve leyendo sobre una "nueva técnica" (si, otra más!) para desarrollar software. Es una técnica y no una metodología por lo tanto no es algo pesado ni complicado. En realidad es una técnica que según el autor trata de resolver algunos problemas que se encontró mientras enseñaba y usaba TDD.

El artículo donde describe la técnica como introducción es interesante. La técnica se llama Behavior Driven Development y se puede leer una introducción acá.

No la he probado aún pero hay varias cosas que comenta que comparto y que veo que tan equivocados no estábamos cuando empezamos allá por el 2000 o 2001 a utilizar TDD como técnica de desarrollo para luego darnos cuenta que era más que una técnica de testing. Parece ser que ya varios se dieron cuenta de esto y el cambio propuesto por Dan North y hasta las palabras que usa, como "Behavior" me recuerda mucho a lo que siempre estuvimos enseñando.

Espero que disfruten del artículo y si alguien tiene alguna experiencia usándolo por favor comente que le parece. Según tengo entendido está teniendo bastante actividad en la comunidad de Ruby.

Bertrand Meyer en Argentina

2009-02-16T11:05:00.002-02:00

La semana pasada tuvimos el honor de que nos visitara Bertran Meyer. Dio dos charlas en Buenos Aires, una en la UTN, organizado por los Seminarios Athena y otra en la FCEyN de la UBA organizada por Marcelo Frías.

La primera (dada en la UTN) se trató sobre su punto de vista sobre como enseñar el curso de introducción a programación en estos días. En la misma comentó por qué los métodos más usados no eran de su agrado (programming in the small, teach API, just formal programming, teach a language, just functional programming) y cuales utiliza él. Uno de los temas que recuerdo como interesante era el hecho de hacer que los alumnos empiecen a programar con un framework ya creado para que aprendan a usar primero para luego aprendan a hacer. Me hizo recordar a lo que hacemos nosotros cuando les damos Smalltalk en POO, primero lo empiezan a usar y luego lo tienen que ver en más detalle y hasta modificar en DAO. De los 26 temas que comentaba como importantes para enseñar solo hay 16, que para aquellas personas que conocemos la bibliografía de Meyer no son nada novedosas, ej. Design by Contract, OO, etc. Me parece que lamentablemente el tema no fue el más apropiado para la audiencia porque la mayoría eran estudiantes y no profesores!, además mostró un ejemplo que usan en la primer clase de la materia donde crean la clase Turist que subclasificaba Preview (el framework que usan es para mostrar ciudades y rutas), en la cual el objeto París sabe responder show, Louvre sabe responder highlight, etc. responsabilidades que no le daría a esos objetos, o nombres de objetos que no usaría en todo caso.

La charla en la UBA se trato sobre testing automatizado. Básicamente lo que hacen es generar objetos random con una heurística determinada para algunos tipos de objetos y luego enviar mensajes a dichos objetos (siempre y cuando los mismos cumplan las pre-condiciones) y ver si hay post-condiciones o invariantes que no se cumplan. Si fuese así, se detectó un error. Mostró una estadística en la cual el testing manual encontró 14 errores y el automático 9. Había errores automáticos no encontrados manualmente y viceversa por supuesto. Le pregunté sobre la cobertura que ofrecía esa herramienta y se armó un gran revuelo puesto que dijo que la cobertura no indicaba nada, cosa que concuerdo a medias. Si hay un 20% no cubierto, uno sabe que debe testear ahí. Si tengo un 100% de cobertura por supuesto que no asegura que haya errores puesto depende de con que conjunto de "datos" se hizo la cobertura. En conclusión, no sacaron estadísticas de cobertura. Le pregunté si habían medido el tiempo que llevó encontrar lo errores manuales y los automáticos, dijo que no. Le pregunté si había pensado en utilizar mutation testing para modificar métodos y validar contratos y viceversa, modificar contratos y ver validar código y respondió que no "entendía mutation testing". Esta charla fue más interesante desde mi punto de vista que la anterior. Lástima que a veces hablaba mucho sobre ciertos temas en los que se perdía el núcleo de lo que quería decir.

Por supuesto, no dejó de publicitar su libro que está por salir "Touch of class ..." y Eiffel.

Igualdad de Objetos II

2009-02-13T13:05:00.000-02:00

Algo que me olvidé de comentar en el post sobre Igualdad de Objetos, es que como el mensaje #= debe devolver true si los dos objetos representan el mismo ente su implementación siempre será verificar si aquellos colaboradores internos que representan la identidad del ente en el objetos receptor del mensaje es igual a los colaboradores internos que representan la identidad en el objeto pasado como parámetro. En pocas palabra, asegurar que ambos "identifican" al mismo ente.

En el caso de Date, esto será verificar que el año, mes y día sean iguales (si esa es la representación que se decidió usar para Date).

Una consecuencia interesante en identificar que colaboradores internos representan la identidad del ente es que esto se podría hacer automáticamente lo mismo que una implementación default del mensajes hash, como también asegurar que dichos colaboradores no pueden cambiar.

nil (pongo algo más para que no parezca un error :-)

2009-02-13T10:22:00.003-02:00

Cuando escribí el título de este post era solo "nil", pero imaginé que alguien podría pensar que sucedió algún error y que por eso aparece solo "nil" en el título. ¿No les pasó eso miles de veces en los distintos sistemas que hicieron? Yo lo vi mucho, por eso modifiqué el título para no crear esa confusión :-) (por supuesto eso implicaría que Blogger está escrito en Smalltalk, cosa que sabemos que no, pero en fin, me pareció una caso curioso)

Ahora si, lo importante del blog. En las charlas que dio Meyer, comentó que en Eiffel pueden ahora asegurar que nunca se envía un mensaje inválido a nil de manera estática, que él representó como que "x.f con x en null es detectado estáticamente" (1). Lo que me pareció curioso de ese comentario es que aún existan personas que estén pensando en ese problema cuando la solución es bien sencilla! y es simplemente no usar nil! pero claro, todos lo siguen haciendo por una cuestión histórica y porque la mayoría de los ejemplos que vemos cuando estamos aprendiendo lo hacen.

Cuando le comenté a Bertrand que nosotros no tenemos el problema del nil (o null para él) puesto que no usamos nil para nada porque tenemos es una regla de programación que nos pide crear todos los objetos correctamente de entrada y representar la ausencia de algún objeto con un null object, me parece que lo sorprendió un poco. Inmediatamente me preguntó "cómo representábamos el fin de una lista encadenada por ejemplo", a lo que respondí que simplemente reificaríamos(2) el concepto de fin de lista y utilizaríamos un objeto especial para tal fin, pero no nil. Mi sensación es que se quedó pensando, por lo menos ahí terminó esta parte de la conversación.

Más allá de esta anécdota reciente con Meyer, les quería transmitir nuestra experiencia respecto de este tema y de que se puede vivir sin el objeto nil y conviene hacerlo por ser la fuente de innumerables dolores de cabeza. No se dan una idea cómo se simplifica la codificación creando objetos correctos de entrada, sincronizando con copias, evitando usar nil... Piensenlo por un minuto y traten de imaginar cuantos errores desaparecerían, cuantos "doesNotUnderstand" o "null pointer exception" dejarían de aparecer si nil o null no existieran... seguramente sientan que son muchos.

Les comento otro detalle anecdótico que me parece al mismo tiempo importante y en sintonía con este consejo. Hoy cuando leía unos blogs me encontré con esta charla que dará Hoare en QCon: "Null References: The Billion Dollar Mistake". Según lo que interpreté de su abstract y título, hablará justamente de que la existencia de null references fue un error gravísimo, y que sólo lo creó en ALGOL W por ser un feature fácil de implementar.... otro feature fácil de implementar que trae dolores de cabeza, y del cual coincido plenamente con Hoare, es realmente un "Billion Dollar Mistake".

(1) Después cuando nos comentó como lo hacían durante la cena, mucho no le entendí pero me pareció muy complejo.

(2) Digo reificaríamos y no reificamos porque nunca tuvimos que crear una lista encadenada en Smalltalk :-)

Igualdad de Objetos

2009-02-10T18:24:00.002-02:00

En el post anterior hable sobre el hecho de identificar correctamente la identidad de un objeto y sobre el verdadero significado del mensaje #==, que en definitiva verifica si dos objetos son idénticos, puesto que dos objetos pueden no ser idénticos pero estar representando el mismo ente.

Como bien comenta Gabriel (Gaboto) en un comentario, puede suceder que existan dos objetos representando el mismo ente (su ejemplo me confundió un poco) y debemos tener alguna manera de identificar dicha situación. Un ejemplo claro se da en Smalltalk con la clase Date, donde dos instancias distintas (o sea no idénticas) pueden representar el mismo día (por ejemplo hoy).

El mensaje que utilizamos para saber si dos objetos están representando el mismo ente es el mensaje #=, más conocido como "igual". Su semántica es devolver verdadero si dos objetos representa el mismo ente, lo que en lenguaje vulgar o natural decimos "si son iguales"... claro está, acá empieza la confusión. Son iguales por estar representando al mismo ente (por ejemplo el día de hoy, que es idéntico a si mismo) pero no son el mismo objeto necesariamente y por no lo tanto no idénticos entre sí.

Por lo tanto el mensaje #= toma una nueva dimensión y para mí es más claro decir que este mensaje "devuelve true si dos objetos representan el mismo ente", puesto que definir qué significa "si son iguales" es bastante problemático como veremos más adelante. Sería menos confuso usar otro mensaje para esta semántica, por ejemplo #representsSameEntityAs:, pero bueno, ya estamos muy acostumbrado al otro.

El motivo por el cual dos objetos pueden representar el mismo ente se debe únicamente a problemas computacionales. En el caso de la clase Date esto se podría solucionar teniendo una cache de fechas creadas y siempre devolver el mismo objeto para la misma fecha, una implementación similar a la de Symbol, sin embargo hacer esto puede no tener sentido por poder ocupar más memoria o ser más lento que la implementación actual al tener que buscar el objeto en esa cache. En definitiva, si existe un solo objeto para representar un ente o si existen varios es una decisión implementativa y es por ello que siempre hay que utilizar el mensaje #= para saber si dos objetos representan el mismo ente (si son iguales) y sólo utilizar el mensaje #== para dominios computaciones, donde realmente nos interese saber si estamos hablando del "mismo objeto", del objeto que ocupa la misma zona de memoria.

Ahora bien, si se decide que puede haber más de un objeto para representar el mismo ente como el caso de Date, hay que asegurar que esos objetos sean inmutables porque sino estaremos en graves problemas puesto que podrían existir representaciones desincronizadas del mismo ente (creo que a esto apuntaba Gaby con su ejemplo). Imagínense dos objetos representando la misma cuenta corriente donde el saldo en uno es distinto al saldo en otro y donde claramente solo uno de ellos representa bien el ente en ese momento por tener el mismo saldo de la cuenta (por supuesto que también podría suceder que ninguno represente el ente por tener los dos el saldo incorrecto...). En definitiva, un grave problema.

Si no es factible que dicho objeto sea inmutable, hay que asegurar que exista una única instancia "master" para representar el ente y el resto sean solo "representaciones temporales" que tendrán un propósito determinado y esporádico. Un ejemplo de este caso es lo que en mi presentación de Smalltalks mostré como "sincronización" de objetos que comentaré en más detalle más adelante, pero que básicamente consiste en sincronizar la copia "master" con la "termporal" de una vez, con el envío de un solo mensaje. Por supuesto que acá nos metemos con problemas transaccionales, pero por ahora también los esquivaré.

Otro tema interesante que se desprende de este es definir exactamente que significa "que sean iguales". Por ejemplo, 0.5 y 1/2 ¿son iguales?. Ambos representan la misma cantidad, la mitad de algo, por lo tanto desde el punto de vista numérico nos interesa que sean iguales, pero también son distintos. Por ejemplo, desde el punto de vista implementativo uno será representado como un número de punto flotante y el otro como fracción. Mismos ejemplos se pueden dar para medidas equivalentes representadas por distintas unidades. Más interesante aún es pensar si 0 es igual a 0 metro, 0 litro, 0 pesos, etc. No voy a ahondar mucho en este tema ahora, pero la verdad es que sí, todos estos objetos representan lo mismo, o sea nada en cantidad y por lo tanto "son iguales". A muchos esta afirmación les parecerá muy loca pero la explicación matemática es clara. Una medida es la representación de la multiplicación de un número por una unidad, por lo tanto 0 metro es lo mismo a decir 0*metro, que algebraicamente es 0 de la misma manera que es 0 la expresión algebraica 0*A. Algunos denominan esta situación como "el cero polimórfico". Ahora bien, todas estas medidas están midiendo cosas distintas y sería interesante poder determinar esa situación, ¿cómo lo hacemos si devuelven true cuando se les envía el mensaje #=? (lo mismo para 1 metro y 1000 milimetros o 100 centímetros, etc). En Mercap estuvimos discutiendo mucho sobre esta situación, discusión en la que también participó Máximo Prieto y que fueron muy interesantes y acalorados (por qué ocultarlo). Llegamos a la conclusión que como en matemática, debería existir la posibilidad de definir distintas categorías de equivalencias, de la cual la igualdad es simplemente una de ellas. Si esto tiene sentido entonces el mensaje #= sería una implementación de una categoría de equivalencia determinada y podrían existir distintos mensajes para implementar las otras... suena interesante no? ¿Cómo se definiría una categoría o cuál sería su significado? Dependerá de lo que queramos representar, es una decisión totalmente arbitraria... aunque quizá suene mejor consensuada, consensuada con una comunidad o grupo...

En fin, si les interesa este tema avisen, da mucho para discutir y charlar.

Tip 2: Clearly identify what represents the identity of an object

2009-01-16T12:15:00.002-02:00

En el primer Tip (si ya se, lo escribí hace mucho...) comenté sobre lo interesante que es tener como objetivo lograr un isomorfismo entre los objetos de mi modelo y los entes del dominio del problema.

Además, como ya puse en otros posts, no hay que perder de vista que los objetos representarán la esencia de dichos entes mediante su comportamiento, no estructura, relaciones, etc.

Sin embargo hay otro punto del que siempre hablamos y es la identidad. La identidad es la que permite identificar únivocamente un ente. Todo ente posee una identidad y por lo tanto el objeto que lo representa en nuestro modelo también debe tener una. Sin embargo hay una gran confusión entre lo que es identidad, lo que algunos llaman "estado de un objeto" y lo que es la identidad del objeto. Voy a empezar por este último.

Un objeto, por ser a la vez un ente de la realidad (además de estar representado otro) también posee una identidad. Esa identidad en un ambiente de objetos está generalmente implementada por medio de la posición de memoria que ocupa el objeto. Es lo que hace que ese objeto sea único, no puede haber otro objeto en la misma zona de memoria que otro.

En Smalltalk, se puede saber si dos objetos ocupan la misma zona de memoria usando el mensaje #== Este mensaje tiene por propósito verificar si dos "objetos" son identicos, o sea, si ocupan la misma zona de memoria pero no puede decir nada sobre la identidad del ente que representan dicho objetos. En rigor de verdad, si dos objetos son idénticos significa que están representando al mismo ente y por lo tanto representan la misma identidad del ente, pero si dos objetos no son identicos no se puede asegurar que estén representando a entes no idénticos. Es acá donde se ve claramente la diferencia entre identidad de objeto e identidad de ente. Un ejemplo lo va a aclarar.

En Smalltalk existe la clase Date, pero si evalúo dos veces la siguiente colaboración "Date today" obtengo dos objetos que no son idénticos pero que sí representan al mismo ente, el día de hoy. Por lo tanto no hay que confundir identidad de objeto que viene dado por el ambiente de objetos de identidad del ente que la tenemos que definir nosotros en nuestro modelo.

¿Cómo representamos la identidad del ente? Dependerá del ente que estemos modelando o la implementación que utilicemos. Por ejemplo, los SmallInteger en Smalltlk nos dan la sensación de ser únicos (o sea, de que hay uno y solo un objeto por cada uno de ellos). A nivel implementativo sabemos que no es así, pero es un claro ejemplo donde la identidad del ente esta asociada a la identidad del objeto. Otro ejemplo son los objetos instancia de Symbol, no puede haber más de un objeto para el mismo símbolo que representan de la realidad. Como vismo, no sucede así con las fechas y con otros objetos como aquellos instancias de Time, Point, etc.

¿Qué es lo que representa entonces la identidad de los entes para estos objetos? Siempre es un conjunto de colaboradores internos (variables de instancia) que cumplen ese propósito. En el caso de Date, dependiendo de la implementación serán el número de día, mes y año. En el caso de Point serán esos objetos que representan la coordenada x e y.

Una característica interesante que tenemos que cumplir con estos colaboradores que representan la identidad de los objetos es que no pueden cambiar, puesto que si lo hacen el mismo objeto estaría en un instante de tiempo representando un ente y luego otro, sería un objeto con "problema de personalidad" no les parece?. Es por ello que es fundamental entender bien qué colaboradores internos representan la identidad de un objeto puesto que ellos no pueden cambiar. Hay otras implicancias interesantes de este hecho, la primera es que el mensaje #= del objeto devolverá true si los colaboradores internos que representan la identidad del ente son iguales. Esto significa que si queremos saber si dos objetos representan el mismo ente, debemos usar el mensaje #=, es este mensaje el que nos dirá si dos objetos representan a un ente idéntico o en otras palabras, a exactamente el mismo ente. Moraleja, no confundir identidad de objeto de identidad de ente y por lo tanto nunca, pero nunca usar el mensaje #== en un modelo a menos que ese modelo esté tratando con un dominio de problema computacional y donde realmente se tenga por intención saber si se está tratando a exactamente "el mismo objeto" sin importar si además si representan exactamente el mismo ente.

Esto que estoy comentando les debería disparar una nueva explicación de porque el hash debe estar relacionado con el #= y por qué cuando un objeto cambia los colaboradores que representan la identidad cambia su hash que termina produciendo un descalabro importante en aquellos objetos que dependen de la invariabilidad de esta característica.

También esto tiene que empezar a dispararnos la idea de que hay colaboradores internos que representan la identidad del ente que modela el objeto y otros que no. ¿qué características pueden tener estos otros? ¿pueden cambiar? ¿que representan?. Son muchas preguntas, no tengo una respuesta 100% segura, pero en la mayoría de los casos me parece que dichos colaboradores existirán por motivos implementativos como por ejemplo tener un cache, poder acceder más rápido a un objeto, etc. y no a cuestiones esenciales del dominio de problema en si, pero no lo puedo asegurar.

Otra pregunta interesante para hacerse es, ¿debería el lenguaje ofrecerme herramienta particulares para hacer uso de esta diferencia? Por ejemplo, que defina una clase de esta manera:

Object subclass: #Point

identityDefinedBy: 'x y'

instanceVariableNames: ''

... etc.

Al hacerlo, automáticamente el ambiente podría asegurar que la identidad no puede cambiar, y algo más interesante aún que la misma se defina en el momento de crear el objeto, algo que veremos en el próximo tip.... mientras tanto tiro la idea, yo aún no tengo un posición tomada.

Desarrollo ágil y vacaciones

2009-01-16T11:40:00.005-02:00

Este fin de año terminé destruido, me dí cuenta que durante el 2008 hice muchas cosas e indudablemente sentí el impacto. Por suerte mañana empiezo mis vacaciones y esta vez me voy a tomar 3 semanas seguidas, siento que realmente las necesito. Espero poder desconectarme lo suficiente para volver con ganas para este año, aunque voy a limitar un poco lo que hago porque no quiero terminar otra vez así. Uno de los temas que creo que voy a limitar es la cantidad de tesis que estoy dirigiendo, aunque no lleve mucho tiempo hacerlo el problema es tener que estar pensando en todas ellas simultáneamente más todo el resto de cosas que tengo que hacer...

Pero como en ciertas cosas no puedo con mi genio y me enteré de este seminario ágil, por ahí presente algo relacionado a la importancia que tiene para mi trabajar en un lenguaje dinámico si realmente se quiere se "ágil". Todo esto me vino a la mente después de haber visto ayer en Mercap Cinema (una vez por semana nos juntamos en el almuerzo a ver videos técnicos) la entrevista en la que estuvieron Dan Ingall y Allen Wirfs-Brook, en donde Dan hace hincapié y repite miles de veces la idea de "self sustainable system" o "meta circular system" y Allen hace una comparación entre Internet y la imagen de Smalltalk basada en la idea que no hay que bajar internet para cambiar una página de la misma manera que no hay que bajar la imagen de Smalltalk para cambiar un método.

En fin, todo esto me hizo pensar lo poco que se entiende aún este espíritu dinámico que posee Smalltalk y que no tiene nada que ver con ser "dinámicamente tipado", sino con el hecho de tener un imagen y poder modificar un sistema mientras corre, donde ese sistema puede ser hasta sí mismo! (que es lo que hace incapíe Dan). Creo que la gente está empezando a ver la importancia de los lenguajes dinámicamente tipados y por lo tanto estaría bueno mostrarles un poco más allá y ver que opinan.

En XTrade, donde utilizamos GemStone como server de objetos, es muy común que hagamos cambios sin bajar el sistema, simplemente modificando por medio de un script de topaz (un cliente de texto de GemStone) lo necesario para arreglar un error. Lamentablemente no tuvimos tiempo aún de implementar la modificación del cliente del sistema, que está escrito en VisualAge, sin tener que cambiarlo completamente, o sea, bajando el cliente y volviéndolo a subir reemplazando toda la imagen, pero sabemos cómo podríamos hacerlo. En una aplicación Web esta característica es aún más interesante.

En fin, ¿qué les parece? ¿sería interesante una charla así en ese contexto? El título que pensé sería algo así: "No se puede ser ágil sin ser dinámico o que nos falta para ser técnicamente ágiles"

Viernes 19/12 , 16:30 hrs: Defensa Tesis de Reingeniería de Jerarquías Polimórficas Utilizando Traits

2008-12-11T12:25:00.000-02:00

Nuevamente estoy con poco tiempo para postear... tengo pendiente seguir con los tips que presente en Smalltalks 2008, pero por ahora copio esta invitación a la defensa de tesis de Claudio y Nicolás que además dieron una presentación muy buena en Smalltalks 2008 sobre este tema...

----------------

Invitamos a todos a la defensa de la siguiente tesis de licenciatura, que
se llevará a cabo el Viernes 19 de Diciembre a las 16:30 hrs, aula a
confirmar:

Título: "Reingeniería de Jerarquías Polimórficas Utilizando Traits"

Alumnos: Acciaresi, Claudio y Buttarelli, Nicolás Martín
Director: Hernán Wilkinson
Jurados: Máximo Prieto, Gabriela Arévalo
--------------------------------------------------------------------
Resumen
Los Traits son una nueva herramienta de modelado que permite al
programador compartir comportamiento entre objetos sin utilizar la
subclasificación. Este nuevo concepto fue llevado a Smalltalk en el año
2003 y desde entonces a la actualidad se realizaron varios trabajos
utilizando Traits. Sin embargo, la mayoría de estos aborda el tema desde
un punto de vista más bien práctico realizando refactorizaciones de
jerarquías ya implementadas. Este trabajo en cambio, estudia a los Traits
en un marco teórico donde se considera que programar no es otra cosa que
representar conocimiento.
Para cumplir con este objetivo se reimplementó la jerarquía de Collection
utilizando Traits. Una vez generado el nuevo modelo se realizó un
análisis del mismo en comparación con la jerarquía implementada en el
ambiente de desarrollo elegido: Squeak. Dicho análisis se basó en la
definición e implementación de métricas de calidad y de performance
tomadas sobre ambos modelos.
Durante el desarrollo se encontraron un conjunto de ventajas y desventajas
en el uso de esta nueva herramienta, pero además, se redefinieron los
Traits como la reificación de características comunes entre objetos. De
esta manera, se separa el concepto de Traits con el de eliminar código
duplicado, y se analiza si el hecho de reificar características comunes
entre los objetos del dominio nos ayuda a crear mejores modelos
computacionales de la realidad.

Mas fotos sobre Smalltalks 2008

2008-11-26T10:37:00.003-02:00

Les paso un link a fotos de James Foster sobre el congreso, la cena y la salida al delta: http://picasaweb.google.com/WeybridgeWay

Smalltalks 2008 en el diario La Razón

2008-11-25T10:32:00.002-02:00

Salió una referencia a la conferencia en el diario La Razón. Se puede ver en http://www.ee.larazon.com/ediciones/2008/11/25/default.asp

Tienen que elegir la sección UAI (donde dice Tapa, arriba a la izquierda) y luego ir a la página 3 de ese suplemento.

Gracias Gonzalo por haber hecho posible esta referencia.

Comentarios sobre Smalltalks 2008

2008-11-21T17:33:00.001-02:00

Hay varios blogs que comentaron sobre el evento, pero este me pareció interesante referenciar por que es un buen resumén de lo que sintió Alan Knight:

http://www.cincomsmalltalk.com/userblogs/knight/blogView?showComments=true&printTitle=Commodore_64s,_Soccer_Playing_Robots,_and_Lots_and_Lots_of_Meat_&entry=3404719124

Tip 1: Create an Isomorphism between objects and entities

2008-11-18T17:07:00.002-02:00

Este fue el primer tip de la charla de Smalltalks que presenté el viernes pasado. Voy a tratar de repasar todos los tips durante las próximas semanas escribiendo los comentarios que obtuve en el congreso y también esperando que ustedes aporten algún comentario.

Este tip tiene como objetivo "lograr un buen modelo". En realidad, la definición de "buen modelo" que dí está basada en las ideas que Einstein escribe en "Física, la aventura del pensamiento", donde básicamente argumenta que un buen modelo es aquel que soporta todas las observaciones que se realizan de la realidad correctamente. Esta idea combinada con la que Norman ofrece en "The Design of Everyday thing" donde básicamente habla sobre la importancia del "mapping" entre los "entes del modelo mental" que uno se realiza de "la realidad" es que aparece este tip.

La idea es que si logramos mapear correctamente cada ente de la realidad a objetos del modelo computable que estamos haciendo estaremos logrando un buen modelo, puesto que cada observación será mapeada directamente a los objetos existentes, y en caso de no poder ser mapeada es porque aprendimos algo nuevo y por lo tanto hay que crear los objetos correspondiente para soportala.

Algo que hay que tener en cuenta sobre este tip, que no comenté en la charla, es que este es un objetivo, es lo que se debe buscar puesto que lograr ese isomorfismo es casi imposible (sino imposible) puesto que siempre habrá algo nuevo para aprender de la realidad o una nueva manera de organizar lo que entendimos.

Otro punto a tener en cuenta es que realmente uno no mapea los objetos con los entes de la realidad sino con el modelo mental que uno realiza de la realidad, es por ello que existen varios modelos del mismo problema que son pensados desde distintos puntos de vista. Es por este motivo que utilizar metáforas para realizar ese modelo mental es fundamental, puesto que guiará nuestra representación e interpretación de la realidad, nos dará una herramienta para entenderla, cuadrarla. El tema de la metáfora es tan importante que hay filósofos post-modernistas que dicen que no pensamos sino a través de metáforas. Representan a estas como "meta-ideas", o sea ideas sobre ideas.

Uno de los comentarios que recibí sobre este tip fue que en el modelo siempre existen objetos que no aparecen en el dominio del problema. En cierta forma es verdad, hay muchos objetos que aparecen en el modelo que no forman parte del dominio de problema funcional, pero muchos de ellos corresponden al hecho de estar haciendo un modelo computable, o sea que son objetos que representan entes de otro dominio de problema, el computable. No tengo manera de probar que siempre estos objetos serán de este dominio pero mi intuición de dice que si....

Si no fuese así, debería cambiar el "isomorfismo" por aquella relación utilizada para indicar que todos los elementos del codominio se mapeaban al dominio (no recuerdo la palabra ahora).

Más allá de este detalle (no despreciable por cierto), lo importante es no olvidar la consigna de mantener este mapeo como objetivo y recordar la importancia de tener una metáfora que nos guie en el proceso...

A personal Computer for Children of All Ages

2008-11-18T16:53:00.002-02:00

Ese es el paper escrito por Alan Kay en Agosto del 72 donde presenta su idea de la Dynabook. Nunca lo había leído y luego de haberlo hecho no cabe duda de la visión que tuvo en su momento. La parte que más gracia me causo fue la que dice "seguramente una de las primeras aplicaciones que harían sería para evitar que aparezca propaganda..." (palabras más palabras menos, no encuentro exactamente lo que dijo ahora) cuando se refería a la conectividad de la computadora. Vale la pena leer esta paper historico.

Adios Smalltalks 2008

2008-11-17T17:29:00.002-02:00

Como ustedes sabrán, Smalltalks 2008 ha terminado. La verdad que han sido 3 días maravillosos, de charlas muy interesantes y de reencuentros muy lindos. Mi intención era hacer un resumen de todas las charlas pero no podrá ser. Vi que Andrés Valloud hizo una serie de comentarios sobre las mismas en su blog, así que pueden leer sobre ellas ahí.

Algunas charlas que recuerdo sin ningún orden particular son:

1) Claudio Acciaressi y Nicolás Butarelli que hablaron sobre la reimplementación de Collection para traits. Se notó que prepararon mucho esa presentación y fue muy chistosa

2) Dan Rozenfarb que presentó ExpertCare. Es muy interesante ver como Dan fue cambiando el diseño de la aplicación desde utilizar un árbol de decisión a modelar reglas con algo cercano a lógica de primer orden.

3) Gabriel Cotelli que habló sobre la herramienta reflexiva para generar reportes que usamos en XTrade. Gabriel subió a YouTube una filmación de la charla

4) Monty Williams que dió el keynote y comentó casos de éxito de usar Smalltalk en distintos sistemas. Hay sistemas de misión crítica y con miles de transacciones que ni siquiera sabía que usaban Smalltalk/GemStone, muy impresionante

5) DX Browser Tool de Bruno Buzzi o como implementar herramientas de Smalltalk para administrar web services y archivos XML. Bruno mostró cómo se puede simplificar el uso de herramientas que el hombre hace complejas.

6) Ambiente de Aprendizaje de Objetos de Fernando Olivara y Juan Burella. La presentación fue interesante y llegaron a mostrar el ambiente (en una versión anterior) funcionando en Croquet. Si embargo como se encuentran en medio de una gran refactorización la presentación no se lució tanto como podría haberlo hecho.

7) Glorp, de Alan Knigth. Fue muy intersante como mostró este framework, lástima que no haya presentado temas más relacionados con el diseño que creo que hubiese estado lindo.

8) Los roadmaps de GemStone y Cincom Smalltalk. En de GemStone en particular estuvo muy interesante cuando James mostró una herramienta parecida a WebVelocity pero que corre en GLASS

9) Andrés Valloud nos motró como modelo en coding contest y todas las opciones que tuvo en cuenta para hacerlo, una charla muy interesante para aquellos que trabajamos en el problema

10) Leandro mostró como se puede tener comportamiento por instancia en VisualSmalltalk. El truco es muy interesante y la verdad que la decisión de VisualSmalltalk de que los objetos conozcan un method dictionary en vez de su clase directamente me parece una decisión muy acertada. Como dijo Leandro, es darle más importancia al comportamiento que a la clasificación.

11) La charla de Richie sobre SqueakNos, impresionante. Yo había visto correr SqueakNos antes pero esta vez estuvo muy bien presentado y mucho más estable. En la charla mostro como acceder al boot sector de un disco IDE y todo desde Smalltalk! Ojala podamos hacer crecer este proyecto

12) La mejor charla de todas, por lo menos así fue elegida por la gente, la de Gabriel Honoré que mostró un Emulador de Commodore 64 hecho en VisualWorks! La gente aplaudió como loca con cada chiche que mostraba como el sonido, los juegos, podes controlar la pantalla desde un inspector, etc. Una presentación y trabajo impecable, de exportación!!

También estuvieron las charlas sobre MOOSE, Percolación, SqueakDBX, el trabajo de Tesis de Carlos Ferro, Zafiro y la mia.

Respecto de la mia, creo que generó bastante polvo, por lo menos luego de darla estuvimos hablando sobre varias ideas con Valeria y Richie y las diferencias sobre lo que ellos hacían. También tuvimos unas conversaciones intersantes con Andrés Fortier que me ayudaron a entender como transmitir mejor el mensaje que quería transmitir. Por supuesto, como me ocurre ultimamente, me quedé sin tiempo... es que quiero decir muchas cosas!!! pero fue una lástima porque no pude mostrar ejemplos concretos que hubiesen ayudado a asentar lo que transmitía.

Por supuesto estuvo el coding contest que ganaron Guillermo Amaral y Guido Chari. Lamentablemente yo no le encontré la vuelta aunque conseguí un certificado positivo pero de solo 2 millones contra 26 que consiguieron los ganadores. Creo que hubo varios factores que influyeron en que no lograse encontrar la solución: el cansancio y el hecho de no haber estado trabajando en el modelo por casi dos semanas... pero calavera no chilla! y estoy muy contento de haber participado y programado nuevamente después de unos meses de solo contestar mails, puaj!

Por último, el domingo llevamos a Monty, June, James, Alan y Victor al Tigre. Los llevamos a remar hasta la isla Rufino Elizalde, del Buenos Aires Rowing Club. Estuvo espectacular! creo que lo disfrutaron muchísimo y hasta comimos un asado. Lástima que por la sudestada del sábado el agua había inundado la isla y por lo tanto estaba todo barroso, pero igual creo que fue una experiencia inolvidable para ellos.

Espero que todos hayan disfrutado de esta conferencia tanto como lo hicimos nosotros. Los comentarios que me llegaron así lo dicen... y ya estaremos trabajando para Smalltalks 2009!!!

Nos vemos!

Ya llega!! Ya llega!!

2008-11-12T09:23:00.002-02:00

Si señores y señoras, mañana es el día!! mañana empiza la segunda edición del congreso Argentino de Smalltalk!!! Smalltalks 2008. No dejen de ir y participar, les aseguro que estará muy bueno y también se van a divertir mucho!! y habrá muchas sopresas!

Los veo ahí!

PD: Voy a intentar postear un resumen sobre cada charla para mantenerlos al tanto a los que no fueron.

Smalltalks 2008 - Descripción de Charlas

2008-11-04T16:29:00.002-02:00

Me olvide de comentar que en la sección "Charlas" del sitio del congreso hay un link llamado "Ver Propuestas Aceptadas" que lleva a una página con descripciones de las distintas charlas que se darán.

Smalltalks 2008 - Corrección

2008-11-04T14:59:00.001-02:00

En el post anterior puse mal la dirección al sitio web del congreso, el mismo es: http://neuquina.lifia.info.unlp.edu.ar:8001/Smalltalks-2008

Smalltalks 2008 - Inscripción y Cronograma

2008-11-03T17:59:00.002-02:00

Ya está disponible el cronograma del congreso Smalltalks 2008!!! Creo que quedó muy bueno, hay charlas muy interesantes como el Emulador de Commodore 64 escrito completamente en Smalltalk!! (lo vi funcionando y es una masa!) o SqueakNos, la mía por supuesto :-), los temas de persistencia como SqueakDBX y Glorp, sin olvidar los tutorials (uno sobre la arquitectura de GemStone y otro de Futbol de Robots) y las charlas de gente de afuera como Monty Williams (arquitecto de GemStone), Alan Knight y James Forster nuevamente. (El cronograma lo pueden ver en http://neuquina.lifia.info.unlp.edu.ar:8001/ tab Cronograma)

No dejen de inscribirse puesto que por cuestiones de seguridad vamos a ser más estrictos este año con el ingreso.

Entrevista sobre Smalltalks en ClubSmalltalk

2008-10-30T09:11:00.001-02:00

Hernán Galante nos hizo una entrevista muy interesante a los que estamos organizando Smalltalks 2008. Los que la quieran leer está en: http://www.clubsmalltalk.org/web/index.php?option=com_content&view=article&id=153:interview-to-the-argentinean-smalltalk-organization-committee&catid=56:interviews-about-events&Itemid=108

Un poco de Historia...

2008-10-17T10:24:00.003-03:00

La verdad que se me hace complicado mantener el blog con cosas interesantes, no porque no tenga ideas sino porque no tengo tiempo para escribir!

En fin, hoy leí un post en la lista de squeak que me pareció muy interesante para compartir (y no escribir tanto). Es sobre la historia de Eclipse y VisualAge Smalltalk.

http://talklikeaduck.denhaven2.com/articles/2008/10/15/will-it-go-round-in-circles

Smalltalks 2008 - Concurso de Programación II

2008-10-02T10:12:00.002-03:00

Quería comentar que la reglas del concurso ya están disponibles en castellano. Por un tema de tiempo no llegamos a tenerlas disponibles ayer, pero en el grupo del concurso se encuentra posteada las reglas en castellano.

Espero que esto no haya sido un inconveniente. También les comento que en el grupo del concurso se puede postear en inglés y castellano indistintamente.

Smalltalks 2008 - Concurso de programación

2008-10-01T14:20:00.003-03:00

Ya está disponible en el sitio del congreso de Smalltalks 2008 las bases para el concurso de programación! No pierdan tiempo! es un trabajo muy interesante y seguro que lo van a disfrutar y aprender!

Además el incentivo es bueno: 1er Premio un iPod Touch, 2do Premio un MP4 y 3er Premio voucher para libros en Yenny!

Charla de Smalltalk/X - Mis conclusiones

2008-10-01T06:21:00.003-03:00

Se hizo esperar, pero finalmente encontré algo de tiempo para escribir mis conclusiones sobre la charla que tuvimos sobre Smalltalk/X:

* La charla fue muy interesante y dinámica. Claus mostró mucho conocimiento y experiencia tanto en Smalltalk como en la implementación de Smalltalk. La primera parte de la charla la dedicó a mostrar la implementación de Smalltalk/X y sobre el final mostró la herramienta de testing que han desarrollado.

Me sorprendió la implementación de Smalltalk/X, no la conocía y me gustó bastante. Es una VM que no tiene nada que envidiarle a otras implementaciones, todo lo contrario, es muy superior a Squeak y VisualAge por ejemplo. Algunas características son:

a) Utiliza IC y PIC para acelerar el method lookup. Solo VW hace eso que yo sepa y por lo tanto sobrepasa en performance por varios cuerpos a Squeak y VisualAge (hagan la prueba sino)

b) Utiliza un GC incremental cuando realiza el mark & sweep del old space (por supuesto, es un GC generacional típico). Esto es muy bueno porque permite limitar el tiempo de gc y por lo tanto asegurar tiempos de respuestas para aplicaciones real time. No conozco otro Smalltalk que tenga esta característica. Por los menos VisualAge y Squeak no la tienen y me parece que VW tampoco

c) El modelo de treading es muy interesante. Primero utiliza threads nativas lo cual permite hacer uso automáticamente de máquinas con más de un procesador, sin embargo no pueden haber dos threads ejecutando concurrentemente. O sea, por un lado es una ventaja por poder distribuir la carga pero no está completamente implementada la posibilidad de ejecutar de manera concurrente. Segundo, cada ventana tiene su propia thread de ejecución, por lo tanto si por darle "evaluate" una ventana se queda haciendo un loop infinito, esto no "cuelga" las otras ventanas, se puede seguir trabajando de manera "normal" (Finalmente alguién que hizo bien esto!)

d) Tiene la opción interesante de generar imágenes muy chicas y empaquetar todo como exes reales. Aunque personalmente no utilizaría esta opción porque la imagen a mi entender sigue siendo algo muy importante, es una opción interesante cuando es necesario hacer aplicaciones para dispositivos con pocos recursos. Hacerlo traería aparejado mayor tiempo de mantenimiento y desarrollo porque habría que asegurarse de que esté todo lo necesario cuando se crea ese "exe" particular, pero es una opción válida para ciertos ambientes.

e) Es interesante la posibilidad de escribir las primitivas en el mismo ambiente, lo cual permite ver con exactitud cómo está implementado cada método. Una lástima no poder debuggear las primitivas, pero tampoco debería ser un requerimiento muy frecuente.

f) Desde el punto de vista de Smalltalk, es una implementación bastante completa. Tiene SUnit, concexión a BD via ODBC, tiene soporte para aplicaciones web (aunque no soporta SeaSide debido a no poder implementar continuations por no poder reificar el stack de ejecución), tiene el refactoring browser migrado y las herramientas típicas de cualquier Smalltalk.

g) Quizá lo único negativo que podría nombrar es la UI. Tiene un estilo un poco "antiguo" y no tan atractivo, pero es algo lógico puesto que hacer UIs "lindas" lleva tiempo y mucha creatividad. Por supuesto que esto para un programador experimientado no debería moverle la aguja, pero para programadores novatos puede ser un stopper (lo que no entra por los ojos...)

En conclusión, una charla muy completa y muy bien dada desde el punto de vista pedagógico. Se nota que Claus tiene experiencia en lo que habla y tiene mucha didáctica por ser profesor también. La verdad que la disfruté mucho y al día siguiente me bajé Smalltalk/X, lo instalé y jugé un poco con él. Un Smalltalk más para tener en cuenta. Es gratis sin ningún tipo de royalties para desarrollar o vender, completamente gratis. No open source, hay algunas temas que no están abiertos. No hay soporte más allá de la misma comunidad a menos que se page por él (no precisó costos). Es una lástima no compartir esta fabulosa implementación de la VM con otros Smalltalks open source como Squeak, o que Smalltalk/X no haga uso de la UI de Dolphin que es más atractiva... un Smalltalk "casi ideal" sería la VM de Smalltalk/X con el modelo de Squeak o VW (o una mezcla de ambos) y el UI de Dolphin... todo open source por supuesto. Una combinación así sería un caño me parece... igual no creo que suceda, por ahora seguimos viendo islas donde cada implementación trata de seguir mejorando lo que tiene. Eliot Miranda mejorando Squeak, Craig Latta haciendo Spoon, VisualAge tratando de soportar SeaSide, Gilad Bracha implementado NewSpeak, etc. No se si sería factible juntar todos los esfuerzos ni tampoco se si sería productivo, pero si se que sería interesante probar.

Smalltalks 2008 - Novedades

2008-09-18T16:06:00.006-03:00

Por si no se enteraron por otro medio, ya está disponible en el sitio de Smalltalks 2008 la registración para charlas y tutorials! No dejen de presentar sus ideas!. Ah, la fecha tope se movió al 13 de Octubre, así tienen dos semanas más para pensar.... y no se olviden del concurso... tenemos a varios craniotecas pensando y trabajando en el mismo :-)

Acá está el mail con el anuncio:
-----------------------------
Por medio del presente mail queremos informarles las novedades de la
conferencia:

1. Se encuentra habilitado el envío de propuestas de charlas en
http://neuquina.lifia.info.unlp.edu.ar:8001/Smalltalks-2008 sección
"Charlas". Aquí se podrán presentar distintos tipos de trabajos, ya
sea de industria, investigación o educación. La fecha tope para enviar
es el 13 de Octubre.

2. Se encuentra habilitado el envío de propuestas de tutorials en
http://neuquina.lifia.info.unlp.edu.ar:8001/Smalltalks-2008 sección
"Tutorials". La fecha tope para enviar es el 13 de Octubre.

3. Asimismo les recordamos que el 1ro de Octubre publicaremos el
enunciado del concurso de programación. Para mas información ver la
sección del "Concurso de Programación" en
http://neuquina.lifia.info.unlp.edu.ar:8001/Smalltalks-2008

Esperamos verlos a todos en la conferencia!
Comité Organizador de Smalltalks 2008.

OOPSLA 2008 - 50 años de Lisp

2008-09-18T16:06:00.003-03:00

Ya escribí sobre este tema en otro post, pero ya se está formalizando. Miren este mail sino:

Lisp50@OOPSLA
...celebrating the 50th birthday of Lisp at OOPSLA 2008

Monday, October 20, 2008
Nashville, Tennessee, USA
co-located with OOPSLA 2008
participation is free for all OOPSLA participants
registration for at least one conference day at OOPSLA is required

URL: http:www.lisp50.org
Feed: http://lisp50.blogspot.com

Invited Speakers

+ William Clinger, Northeastern University, USA
+ Pascal Costanza, Vrije Universiteit Brussel, Belgium
+ Richard Gabriel, IBM Research, USA
+ Rich Hickey, Independent Consultant, USA
+ Alan Kay, Viewpoints Research Institute, USA
+ Fritz Kunze, USA
+ Ora Lassila, Nokia Research Center, USA
+ John McCarthy, USA
+ Kent Pitman, PTC, USA
+ Guy Steele, Sun Microsystems Laboratories, USA
+ Herbert Stoyan, University of Erlangen, Germany
+ Warren Teitelman, Google Inc., USA
+ JonL White, USA

Titles, abstracts, biographies and schedule will be announced at the
Lisp50 webpage and blog in the coming days and weeks.

Abstract

In October 1958, John McCarthy published one in a series of reports about
his then ongoing effort for designing a new programming language that
would be especially suited for achieving artificial intelligence. That
report was the first one to use the name LISP for this new programming
language. 50 years later, Lisp is still in use. This year we are
celebrating Lisp's 50th birthday. OOPSLA 2008 is an excellent venue for
such a celebration, because object-oriented programming benefited heavily
from Lisp ideas and because OOPSLA 2008 takes place in October, exactly
50 years after the name Lisp has been used publicly for the first time.
We will have talks by John McCarthy himself, and numerous other
influential Lispers from the past five decades. We will also take a look
at the next 50 years of Lisp.

Organizers

+ Pascal Costanza, Vrije Universiteit Brussel, Belgium
+ Richard Gabriel, IBM Research, Hawthorne, NY, USA
+ Robert Hirschfeld, Hasso-Plattner-Institut, Potsdam, Germany
+ Guy Steele, Sun Microsystems Laboratories, Burlington, MA, USA

Sponsored by ACM SIGPLAN

Supported by
+ IBM Research
+ LispWorks Ltd
+ Franz Inc.
+ Clozure Associates

Presentación de Tesis Licenciatura - Tema: Refactoring de Traits

2008-09-12T18:38:00.002-03:00

Seguramente también se hayan enterado de este evento, pero de la misma manera que con la charla, me parece importante publicarlo acá. La realidad es que estoy muy contento con el avance que estoy teniendo con el grupo de tesistas de la UBA. Estamos haciendo trabajos muy interesante.... bue, en realidad ellos están trabajando mucho, yo solo puse las ideas iniciales y de vez en cuando nos reunimos, pero la verdad que estar trabajando con gente motivada, autónoma y con espíritu de investigación es muy reconfortante. Lástima que tenga tan poco tiempo para dedicarles... si le dedicase más tiempo creo que ni mi perro me reconocería!.

En particular,Alejandro ha hecho un trabajo excepcional con esta investigación y la ha presentado en Smalltalks 2007 cuando aún estaba trabajando en ella. Esta presentación será aún mejor, se los puedo asegurar, si tienen la oportunidad de venir no se van a arrepentir. De vuelta, es un trabajo muy interesante y Alejandro ha trabajado muy bien y con mucha fuerza. Además tendremos un jurado de lujo! Máximo Prieto y Gabriela Arévalo! ¿Qué más se puede pedir?

También me emociona pensar que otros grupos estarán exponiendo para fin de este año si Dios quiere, o principo del que viene, uno también sobre traits y otro sobre ambientes de enseñanza con objetos, así que estén atentos!

Ahora les transcribo el mail que mandé invitando a la presentación de tesis:

-----------------------------

Que tal,

el miércoles 17 de Septiembre a las 10 hrs. (aula a determinar), Alejandro Gonzalez presentará su trabajo de Tesis de Licenciatura que trata sobre el estudio e implementación de "Refactorings para Traits".

El mismo se basó en realizar cambios a jerarquías de clases existentes utilizando un nuevo elemento de representación de conocimiento denominado Trait (o Rasgo en castellano). Al ir realizando estos cambios se tomó nota de aquellos procesos comunes que pudiesen ser creados como Refactorings, para luego implementarlos como tal.

El trabajo se realizó con Squeak (una implementación open source de Smalltalk) y se amplió la funcionalidad del Refactoring Browser. El mismo se encuentra disponible para ser utilizado en SqueakSource.

Esta es la primer presentación de un conjunto de tesis que tratan sobre la utilización de Traits en ambientes de objetos que utilizan clasificación como metodología de representación de conocimiento. El resto de los trabajos se irán presentando en los próximos meses.

El jurado estará compuesto por Máximo Prieto, Gabriela Arévalo

Director: Hernán Wilkinson

A continuación se adjunta un resumen:

---

Traits es un nuevo concepto para estructurar programas orientados a objetos.
Este concepto, permite que el comportamiento total de una clase pueda ser construido
composicionalmente a partir de pequeños rasgos de comportamientos llamados traits.

Traits complementa a la herencia simple y es por esto,
que su inclusión conlleva la necesidad de querer refactorizar nuestros diseños,
ya que con ellos ahora se pueden resolver cuestiones antes no resueltas, o mal resueltas, por la herencia.
En particular, aquellas jerarquías cuestionadas por hacer un fuerte uso de la herencia
como único mecanismo para compartir comportamiento, son las que se convierten en candidatas a ser refactorizadas con traits.
Pero estas refactorizaciones no pueden ser realizadas eficientemente sin la asistencia de una herramienta apropiada.

Muchos ambientes de desarrollo incluyen herramientas para refactorizar código.
Éstas soportan, a menudo, refactorings típicos que pueden realizarse en forma semi-automática,
como por ejemplo Push up method y Rename method.
El problema es que, éstas operan sobre conceptos conocidos del paradigma:
jerarquía de clases, métodos, variables de instancia, etc.
Actualmente, ninguna brinda soporte para la refactorización con este nuevo concepto, traits.

En este trabajo se investigan, tanto desde un punto de vista conceptual como implementativo, nuevos refactorings para traits.
El resultado es un nuevo conjunto de operaciones de refactorings que,
inicialmente surgieron de ideas básicas y operaciones típicas al programar con traits,
pero que luego fueron refinándose a medida que las comenzamos a utilizar para realizar diferentes refactorizaciones.

Estos nuevos refactorings se implementaron en Squeak, un dialecto open-source de Smalltalk,
dado que éste es el único ambiente que incluye una implementación sólida de ambos,
el nuevo concepto de traits y una herramienta de refactorings conocida como refactoring browser.

Charla sobre Smalltalk/X y Model Base Testing

2008-09-12T17:57:00.000-03:00

Seguramente ya se entereron de esta charla por las listas de mails de Smalltalk, la facultad, etc. Sin embargo me parecía útil comunicarla acá también. Les transcribo el mail que envié sobre la misma:

--------

Que tal,

el comité organizador de "Smalltalks 2008" tiene el agrado de anunciar la charla que dará Claus Gittinger, co-fundador de eXept Software AG y creador de Smalltalk/X el viernes 19 de Septiembre, a las 19 hrs. en Ciudad Universitaria (los detalle del aula serán dados más adelante).

La misma será una exposición técnica sobre la implementación de Smalltalk/X en primera instancia, para luego incursionar en el tema de "Model Base Testing" en donde mostrará un ejemplo real de uso utilizando la herramienta denominada "Expecco", la cual fue desarrollada por eXept justamente con Smalltalk/X

Para más información sobre eXept y Smalltalk/X pueden visitar: http://www.exept.de/en/home

Para más información sobre "Model Base Testing" y Expecco, pueden visitar: http://www.exept.de/en/products/expecco

Para más información sobre "Smalltalks 2008" pueden visitar: http://neuquina.lifia.info.unlp.edu.ar:8001/Smalltalks-2008

A continuación se detalla el profile de Claus Gittinger:

Claus Gittinger has a 22-year background as a software architect for object oriented software. He is

the creator of the Smalltalk/X programming system.

As a co-founder of eXept Software AG he was defining and supervising development and testing

processes with various customers in telecommunication-, factory automization and automotive

projects.

He is responsible for strategic product planning and the further development of the eXept's expecco

quality management and test automation tool.

He is part-time teaching computer science at the Hochschule der Medien in Stuttgart.

Los esperamos!

Saludos,

Hernán Wilkinson.

Clojure - On state and Identity

2008-09-10T18:33:00.002-03:00

Este paper sobre el lenguaje Clojure me pareció muy interesante. Está muy clara la problemática de los lenguajes actuales (tanto procedurales como funcionales como de objetos) y provee una solución implementativa muy interesante.

Lo que me parece más intersante de la solución que propone es que es fácilmente ampliable para mantener la historia de los objetos y así no tener más la limitación de que los sistemas reflejen sólo un snapshot de la realidad.

Hacer que un lenguaje de objetos soporte la historia de los mismos es un lindo tema de tesis que tengo pendiente. Imaginensé si a ese lenguaje le agregamos persistencia automática en una base relacional (puesto que la gente aún se asusta de las bases de objetos), ¿no tendríamos el COBOL del siglo XXI? :-)

V8 - La Virtual Machine de JavaScript de Google

2008-09-10T18:25:00.002-03:00

Como todos deben estar al tanto, Google sacó un nuevo Browser llamado Chrone que incluye la VM de JavaScript más rápida hasta ahora (http://code.google.com/p/v8/)

Lo interesante de esta VM es que fue hecha por gente que trabajó en la VM de Self y de Strongtalk, ambas VMs famosas por sus aportes a la materia en cuestión.

En particular Self aportó mucho sobre como mejorar la performance en el algoritmo de method lookup, implementando algo que se llama PIC (polimorphic inline cache), utilizado actualmente en la VM de VisualWorks por ejemplo. V8 utiliza una versión simplificada de PIC que es IC (inline cache únicamente). La técnica de PIC también fue utlizada por Strontalk, la VM de Smalltalk más rápida hasta ahora (aunque no realiza garbage collection...).

En fin, me parece que desde el punto de vista técnico es muy interesante leer sobre como funciona esta VM, ver cómo está implementada puesto que el código es open source, etc. Y desde el punto de vista de marketing, es muy bueno tener uno de los grander players apostando en un lenguaje dinámico, lástima que sea JavaScript. Sin embargo lo bueno es que en la página de V8 se hace referencia a Self y Smalltalk, lo cual no es poco.

Smalltalk está muerto! Larga vida a Smalltalk! Bienvenido Smalltalks 2008

2008-08-26T16:03:00.001-03:00

Transcribo a continuación un artículo que salió publicado en el Journal del Lifia acerca de Smalltalks, espero que lo disfruten!
-------
A mediados de Septiembre de 2007, a cuatro locos se nos ocurrió organizar un congreso de un lenguaje de programación al que la mayoría de la gente lo da por muerto o cree que sólo sirve para enseñar: Smalltalk. ¿A quién se le ocurre utilizar ese lenguaje hoy en día? ¿Hay gente en el mundo o más aún, en Argentina que lo utilice?
Aquellos que conocen Smalltalk y las comunidad que existe alrededor de él, sabrán que sí, que hay gente en el mundo y más aún, en Argentina que usa este lenguaje. Pero además saben que aquellos que formamos parte de esta comunidad tenemos características especiales que compartimos con muchas comunidades de otros lenguajes de programación: amor por desarrollar software de calidad y pasión por el lenguaje que utilizamos, en este caso un lenguaje de programación que tiene ya casi treinta años.
Es por eso que cuando se nos ocurrió hacer este evento (ver http://www.dc.uba.ar/smalltalks2007) nuestras expectativas de convocatoria rondaban las 40, 50 personas como mucho. No pretendíamos hacer una conferencia de más de un día y tampoco pensábamos desplegar una logística complicada. Por ejemplo, los anotados debían enviar un mail a una casilla de correo creado para tal fin, la conferencia no tendría costo, etc. El congreso se realizaría en un aula común de la Facultad de Ciencias Exactas y Naturales de la UBA, a principio de Diciembre; y como se decidió hacerlo muy sobre la fecha, no había mucho tiempo para esperar grandes presentaciones, por lo que el único requisito que se pedía era un abstract de no más de una carilla.
Luego de enviar el mail de convocatoria empezamos a recibir inscripciones a un ritmo inesperado. Imaginamos al principio que el ritmo decaería con el acercamiento de la fecha del congreso, pero sucedió todo lo contrario. Cuando superamos los 40 inscriptos tuvimos que empezar a buscar un aula más grande pero al mes superamos los 100! y luego los 150, y luego los 200! A esa altura sólo quedaba como opción utilizar el Aula Magna del Pabellón I, la cual puede albergar cerca de 450 persona. Teníamos miedo. ¿Qué pasaría si de todos estos inscriptos solo venía la mitad o menos? El congreso era gratis, por lo tanto esto podría suceder. No sería agradable ver el aula Magna con 100 personas, sería verla vacía. Pero nos arriesgamos y decidimos utilizarla, decisión que nos alegra haber tomado porque la cantidad de inscriptos llegó a ser 300!, un número impensable para una congreso técnico en Argentina y menos todavía para un lenguaje que se suponía muerto o en el mejor de los casos fuera de moda!
Pero la sorpresa no terminó en la cantidad de gente anotada, siguió con la cantidad de trabajos presentados. Esperábamos recibir propuestas para presentar 6 u 8 trabajos, pero recibimos 30! Indudablemente un día no alcanzaba para presentar todo. Ni siquiera dos días alcanzaban sin que hubiese superposición de presentaciones. Además de las presentaciones argentinas, GemStone ofreció gracias a la publicidad y gran convocatoria que tuvo el congreso, realizar un Workshop sobre GLASS (http://seaside.gemstone.com), un ambiente de desarrollo web que utiliza Seaside (http://www.seaside.st) como framework web y GemStone (http://www.gemstone.com) como mecanismo de persistencia.
Finalmente el cronograma del congreso pasó de ser de un día con sólo 6 u 8 presentaciones nacionales a tres días, con 30 presentaciones, un workshop de un día entero y gente del exterior participando y presentando. ¡¡Totalmente inesperado!! Este evento superó todas nuestras expectativas, consumió todo nuestro tiempo libre (y no libre :-) ), nos volvió locos, "pero ¡la pucha que vale la pena estar vivo!" y este evento nos dio vida a todos, eso lo puedo asegurar.
Y las sorpresas no terminaron en la "cantidad" sino que también tuvimos sorpresas relacionado a la "calidad", característica que se notó en las presentaciones realizadas. Hubo presentaciones de una calidad técnica inesperada, con una claridad de conceptos e ideas que nos sorprendieron. Esto terminó de mostrarnos lo fuerte e importante que es la comunidad Smalltalk en Argentina. Un ejemplo demostrativo de esta importancia es la participación en los premios que ESUG otorga a los sistemas realizados en Smalltalk, que este año de 22 candidatos 6 son trabajos argentinos, el 25% (y me consta que hay aún más trabajos argentinos que se podrían presentar).
Las presentaciones realizadas abarcaron un espectro de temas muy completo. Las empresas locales presentaron sus sistemas y varias herramientas que usan para poder trabajar mejor, los grupos de investigación nos desasnaron sobre temas actuales y novedosos y hubo también exposiciones de los distintos grupos de enseñanza de objetos de diversas universidades.
En el congreso participó gente que vino de Luján, Mar del Plata, Concepción de Uruguay, Córdoba, Rosario, Rafaela, Resistencia, Formosa y varios lugares más del país. De los inscriptos, el 56% provino de la industria del software y el 44% restante de universidades (un balance muy interesante). De las universidades la que llevó más gente fue la UTN con el 36% (una gran sorpresa para todos nosotros), seguida por la Universidad de la Plata con un 31% y luego la UBA con un 21%. ¡Hasta hubo gente que catalogó el evento como "la conferencia de Smalltalk más importante de los últimos años"! (http://doesnotunderstand.free.fr/?p=459)
Trabajamos muchísimo para realizar esta conferencia y no lo habríamos logrado sin la ayuda desinteresada de varias empresas argentinas (Mercap SRL, InfoOil, Snoop, etc.) e internacionales (CaesarSystems, Cincom, Instantiations, GemStone, etc.), así como otras organizaciones como ESUG, LIFIA, STIC y la UBA, que por medio del Departamento de Computación de la Facultad de Ciencias Exactas, nos dió todo el soporte e infraestructura necesaria para que este evento fuera posible. Gracias a ellos pudimos cubrir cosas como el café y las medias lunas, las tazas y remeras referentes al evento, los cronogramas, DVDs y libros sorteados, así como un descuento del 50% a todos los participantes del congreso para asistir a Smalltalk Solutions 2008 en Reno, Estados Unidos (http://www.stic.st/stic?content=sts2008).
Un hecho interesante del evento fueron los videos que recolectamos de personalidades representativas de la comunidad Smalltalk de distintos lugares del mundo, como aquel de ViewPoint Reasearch Institute (liderado por Alan Kay) o de Dan Ingalls quien declaró sus ganas de venir este año a tomar unas cervezas con nosotros (¿quién dice no?).
En conclusión, fueron todas sorpresas y alegrías muy gratas. Valió la pena invertir el tiempo que se dedicó a este evento y los participantes han quedado más que satisfechos, pidiéndonos repetirlo para este año, lo cual estamos haciendo.
Por supuesto que no va a ser fácil igualar o superar el evento del año pasado. No sabemos si se generará más, menos o igual expectativa, no sabemos si vendrá más o menos gente, pero de algo sí estamos seguros: será un congreso excepcional por varios motivos. Uno de ellos es que como nos propusimos, será realizado en otra universidad, la UAI, quienes con la ayuda de Gonzalo Zabala nos abrieron sus puertas para este evento. Nuestra idea es hacer el congreso en una universidad distinta cada año. También estamos trabajando para que el track de investigación y educación tenga más importancia y podamos imprimir los trabajos presentados. Es nuestro objetivo a corto plazo publicar los trabajos en revistas de investigación de reconocimiento mundial, pero no es sencillo coordinarlo. Se está organizando un "coding contest" muy interesante y al cual están todos invitados. El evento será no sólo para gente de la comunidad Smalltalk sino también para todos aquellos programadores que "amen" su trabajo. Traeremos también personalidades bien conocidas de la comunidad Smalltalk internacional para que nos ofrezcan todo su conocimiento. Por lo tanto, no se olviden de agendar estas fechas: 13, 14 y 15 de Noviembre, y si tienen ganas de participar, tanto realizando una presentación como asistiendo a éstas, no dejen de visitar nuestro sitio para anotarse: http://neuquina.lifia.info.unlp.edu.ar:8001/Smalltalks-2008
Los que usamos Smalltalk somos muy pasionales, no hay porque ocultarlo. Esta actitud tiene su lado positivo pero también su lado negativo, puesto que al ser mal utilizada genera rechazo por parte de otros grupos, algo que ha sucedido en algunos casos. Luego de varios años de maduración y de varías "caídas", el grupo de gente que utiliza Smalltalk ha aprendido a sobrellevar su fanatismo de una manera más "social", menos pedante y más amistosa y estos eventos son el resultado de estos cambios. Es por eso que el evento está abierto a todas aquellas personas a las que les guste desarrollar software cada vez mejor y comparta esa pasión por hacerlo correctamente y con calidad.
Espero haberles transmitido en esta nota las energías, el empuje, el entusiasmo que tuvimos y tenemos para la organización de estos congresos. Tenemos muchas ganas y mucha pasión por hacer algo interesante, educativo, atractivo, con libertad y con calidad. No un congreso más, no un congreso dirigido por temas de modas, no un congreso donde nos digan como tenemos que trabajar, sino un congreso donde podamos compartir cómo nos gusta trabajar y podamos demostrar que es posible hacerlo como queremos.

Natural Language Programming

2008-08-15T18:01:00.002-03:00

A partir de un artículo en la última Communications de la ACM, escrito por Mark Guzdiel llegué a unos papers muy interesantes sobre lo que se denomina "Natural Language Programming" o "Natural Programming". La idea es tener lenguajes de programación que estén hechos para los seres humanos y no para las computadoras.
Una de las observaciones que hacen es que los lenguajes de programación actuales están hechos para ser entendidos por computadoras y que por eso son tan detallados los programas y es tan difícil programar. Lo que proponen es hacer que los lenguajes de programación se asemejen más al lenguaje natural y que se pueda de esa manera entender mejor los programas que se escriben.
Más allá de las limitaciones y dificultades que esto tiene, la idea me parece muy interesante porque cambia completamente el ángulo de importancia. Va de acorde con lo vengo diciendo hace rato y que fue motivo de la charla de la ECI y es lograr que "la computadora haga más y el programador menos".
Una sorpresa que me llevé, que ya a esta altura está empezando a dejar de ser sorpresa, es que es un tema de investigación "antiguo", de hecho los papers fundadores de este movimiento son del '70! La verdad que cada vez más me doy cuenta que hay que ir a buscar en nuestra historia para descubrir los buenos trabajos (será que me estoy volviendo viejo? :-) )
En fin, les paso algunos nombres porque se los pueden bajar de internet sin problema:
* Natural Language programming: Styles, strategies, and contrasts, L.A. Miller (1970)
* Studying the Language ad Structure in Non-Programmers' solutions to programming problems, J. F. Pane et. al
* The influence of the Psychology Of programming on a Language Design: Project Status Report, J.F. Pane et. al.

Espero los disfruten!

Smalltalks 2008 - Registración y CFP

2008-08-14T09:27:00.002-03:00

Ya está habilitado en el sitio web de Smalltalks 2008 la opción para registrarse al evento y la de sumitir papers de investigación (dentro de poco estará la opción de presentaciones de industria y workshops).
¡No dejen de anotarse! ¡Este año tenemos que romper el record del año pasado!

Los IFs no ofrecen información Meta

2008-08-08T10:10:00.003-03:00

Hay un comentario de Gabriel (gaboto) en el post de la conferencia de la ECI donde me pide aclarar un comentario que hice en la presentación relacionado a los IFs. El comentario tenía que ver con el hecho de que los IFs no tienen información "meta". Lo voy a tratar de explicar con el ejemplo de la presentación.
En dicho ejemplo, una de los cambios de diseño que mostré fue reemplazar una serie de IFs por objetos que se encargan de "tipificar" un objeto. Al haberlo hecho hay mucha información que se está poniendo en el código que antes no estaba. Ahora para tipificar un objeto no se utiliza una construcción tan genérica como el IF sino una más concreta que se encarga justamente de "tipificar" objetos. En pocas palabras, a partir de ese momento cuando un programador lee el código se dará cuenta que se está tipificando un objeto simplemente por ver qué objeto (clase en este caso) se está usando.
Algo similar sucede con los patrones; cuando se ve un "state" se entiende para qué está, su función, etc. Si en vez de un "state" hubiese un conjunto de IFs o CASEs, habría que leer lo que está escrito, interpretarlo, etc. para llegar a la conclusión de que se está programando un "state" (a menos que exista un comentario que diga eso, pero así y todo, no se puede deducir información automáticamente de un comentario, solo lo puede interpretar un ser humano).
Un IFs, lo único que indica es que se está tomando una decisión, pero no da indicios sobre qué decisión, por qué, etc., para obtener esa información alguien tiene que "interpretar" el IFs, y solo los seres humanos lo pueden hacer (al menos por ahora... :-) ) De la otra manera no solo le resulta directa la interpretación al ser humano sino que también se puede utilizar esa información de manera automática. Por ejemplo, si se quiere ver todas aquellas clases cuyas instancias son tipificadas, se busca las referencias a la clase que implementa esa responsabilidad y listo. Si se quisiese hacer estadísticas sobre la cantidad de tipos que existen, se puede a partir de estas referencias ver la jerarquía de tipos sobre las que trabajan y obtener todas las subclases de la clase raíz de cada jerarquía y obtendríamos dicha información, etc.
En pocos palabra, no es que el IFs no indique nada sobre lo que se está haciendo, sino que al ser tan genérico se pierde información, información que luego debe ser reconstruida por el programador cada vez que lo lee. De la otra manera, al utilizar un objeto más específico existe información que puede ser interpretada más fácilmente y de manera automática. A esto me refiero con información "meta". Estos objetos que reemplazan al IFs no solo hacen lo que tienen que hacer sino que ofrecen información "más allá de lo que hacen", información sobre el código en el cual están siendo utilizados, o sea, meta-información sobre el programa.
Bueno, espero haber logrado explicar mi idea. Cualquier duda chiflen!

La Imagen de Smalltalk

2008-08-05T11:36:00.003-03:00

Muchas veces se discute si es bueno que Smalltalk tenga un imagen, es más, recientemente hubo una discusión al respecto en la lista de Squeak-Dev.
El problema que se le achaca a la imagen es que es difícil de "integrar" con el resto del ambiente. La verdad que si hay algo que no me gustaría perder de Smalltalk es el concepto de imagen y es más, me parece que es una característica que todo lenguaje tendrá que incluir en su evolución.
De la misma manera que hace 10 años la gente discutía sobre si era bueno tener un VM o Garbage Collection hasta que salió Java y empezó a verse sus ventajas, me parece que lo mismo pasará con la imagen. Seguramente salga en algunos años algún lenguaje que tenga una imagen y como será un lenguaje nuevo todos usarán porque estará "copado" y de ahí en más no se discutirá sobre la conveniencia o no de tener una imagen.
De hecho, la "imagen" existe en los ambientes de desarrollo actuales pero en una forma más cavernícola. En Eclipse por ejemplo, la "imagen" está compuesta por todos los archivos .java, las configuraciones, etc. Lo que sucede que esa "imagen" no está compuesta por objetos sino por elementos más antiguos como archivos, texto, etc. y que hacen por lo tanto que el ambiente sea más arcaico y menos manipulable.
Para mí la imagen "siempre existió", pero con otras características y con menos capacidades como aún vemos en varios ambientes de desarrollo. Es por eso que creo que la evolución inevitable de todo "lenguaje" debe ir hacia una "imagen" más estilo Smalltalk.
En conclusión, me parece que antes de que la imagen desaparezca, la imagen aparecerá con más fuerza en algunos años.... veremos si me equivoco.

Visitors en la presentación de la ECI

2008-08-05T11:23:00.002-03:00

Hay varios que me preguntaron sobre el test de los visitors que mostré en la presentación de la ECI. En otro post de este blog ya había hablado del tema, el link es: http://objectmodels.blogspot.com/2007/10/cmo-asegurar-la-evolucin-de-un-sistema.html

En si, el código del test es el siguiente:

testVisitorsImplementVisitorProtocol

| acceptingVisitorsRoots visitorProtocols visitorImplementors invalidVisitorImplementors |

acceptingVisitorsRoots := MCPAcceptingVisitorRootFinder allAcceptingVisitorRoots.

visitorProtocols := acceptingVisitorsRoots collect: [ :anAcceptingVisitorRoot |
MCPVisitorProtocol for: anAcceptingVisitorRoot ].

visitorImplementors := visitorProtocols
inject: OrderedCollection new
into: [ :implementors :aVisitorProtocol |
implementors addAll: aVisitorProtocol implementors; yourself ].

invalidVisitorImplementors := visitorImplementors reject: [ :aVisitorImplementor |
aVisitorImplementor isValid ].

self assert: invalidVisitorImplementors isEmpty

Instancias de MCPAcceptingVisitorRootFinder se encargan de buscar la raíz de una jerarquía de clases que acepta visitors. Para ello busca las clases que implementan #accept: y dada un jerarquía devuelve la clase que más arriba se encuentre en la misma.
MCPVisitorProtocol modela el protocolo que debe implementar un visitor. Lo deduce a partir de todos los mensajes que se envían en el método #accept: de una jerarquía de clases. Dado un VisitorProtocol se puede obtener todas las clases que lo implementan. Las implementaciones de un protocolo de visitor está modelado con la clase MCPVisitorImplementor que entre otras responsabilidades sabe responder si es una implementación válida de ese visitor.
Bueno, si desean más detalles de la implementación pregunten!

Presentación de ECI 2008

2008-08-04T16:50:00.002-03:00

El viernes di la presentación de técnicas y herramientas que usamos en Mercap en el marco de la ECI. Creo que salió muy bien, por lo menos me fui contento. Lástima no haber tenido más tiempo y haber cometido un par de equivocaciones con la imagen que había que usar (por estar apurado levanté otra imagen...)
Para aquellos que estén interesados, la presentación está disponible acá: http://www.mercapsoftware.com/ECI2008.pdf

The Story of the Ribbon - La UI de Office 2007

2008-07-18T16:26:00.002-03:00

Pocas veces vi presentaciones interesantes de gente de Microsoft, pero tengo que decir que esta vale mil veces verla... no se la pierdan, es sobre el UI de Office 2007. El link es http://blogs.msdn.com/jensenh/archive/2008/03/12/the-story-of-the-ribbon.aspx

Lisp cumple 50 años!

2008-07-08T16:10:00.001-03:00

y como me gustaría estar en esta conferencia: http://www.franz.com/services/conferences_seminars/lisp_50th-birthday.lhtml

Alan Kay sobre la enseñanza de computación

2008-07-08T14:49:00.002-03:00

Un amigo me pasó este link muy interesante al blog de Mark Guzdial, http://www.amazon.com/gp/blog/post/PLNKVUNBWIDAS9YQ
donde critica un nuevo plan de estudios de Ciencias de la Computación e Ingeniería de Software que propone la ACM. Lo interesante de este blog es que Alan Kay opinó sobre esto y la verdad que no tiene desperdicio todo lo que dice. El blog es largo así que si no tienen tiempo les aconsejo solo leer lo que dice Alan Kay.
Alan hace hincapié nuevamente en la importancia de utilizar el método científico para desarrollarnos como personas y sociedades. También refuerza mucho la necesidad de conocer lo que hicieron en el pasado las personas que trabajan en esta profesión porque sino estamos no reinventando la rueda sino "una rueda pinchada". Comenta que en otras disciplinas como física no pueden darse el lujo de no saber que pensó Newton o Einstein, sin embargo en computación hay gente que no conoce que hizo Engelbart. (A mi me pasa cuando doy clases que los alumnos no conoces a Turing, ni que hablar de Church). Esto hace que estemos en una continua infancia, que nunca crezcamos y seamos adultos. Además comenta que se perdió el espíritu de investigación que existía con ARPA/PARC donde se buscaban nuevas soluciones constantemente, ahora todo está más orientado al "resultado inmediato".
También Mark y Alan hablan de un curso especial que está dando Alan Kay el cual desconozco pero voy a buscar información porque parece interesante.

Charla en la ECI 2008

2008-07-07T14:00:00.003-03:00

Este año voy a dar una charla en la ECI (Escuela de Ciencias Informáticas) que organiza el Departamento de Computación de la Facultad de Ciencias Exactas. La descripción de la charla la pueden ver en http://www.dc.uba.ar/events/eci/2008/conferencias/mercap
La misma será una charla técnica en la cual mostraremos las herramientas y técnicas que usamos en Mercap para hacerle la vida más fácil y animada al programador.
Espero verlos!

MagLev o Ruby corriendo en GemStone

2008-06-30T18:27:00.001-03:00

La gente de GemStone está encontrando la manera de empezar a hacer más conocido su producto.
Miren esta demo de Avi Bryant sobre MagLev, una implementación de Ruby corriendo en la infraestructura de GemStone.
http://www.vimeo.com/1147409
La verdad que es muy buena y está muy bien dada, creo que dieron en la tecla en la presentación

Más sobre TDD

2008-06-30T15:57:00.002-03:00

Siempre me costó encontrar un buen ejemplo para enseñar TDD, pero creo que finalmente he encontrado un problema interesante para resolver mientras se enseña esta técnica.
El problema consiste en modelar un árbol genealógico. Es muy interesante porque se puede empezar por resolver el problema de obtener los padres de una persona y luego los abuelos y luego los tatarabuelos. Haciendo esto se encuentra una recursión que puede ser modelada primero con mensajes y luego con objetos, todo utilizando refactorings!.
Luego se puede continuar con encontrar hermanos, primos, tíos, etc. para luego cuando está todo reificado crear composiciones de búsqueda... un lindo ejercicio, este sábado lo utilice en el postgrado de la UCA con un buen resultado (según me parece).

Como hacer TDD

2008-06-14T12:47:00.000-03:00

Hace un par de semanas cuando estaba revisando como iban los trabajos prácticos de POO, vi una confusión sobre lo que significa hacer TDD. Muchos grupos habían escritos varios test pero no habían corrido dichos tests. O sea, seguían trabajando de manera clásica C o Java, donde se escribe todo primero y luego se prueba, en vez de trabajar de manera dinámica, a la Smalltalk, donde se escribe y prueba constantemente.
Es interesante ver que cambiar este hábito es uno de los puntos más costosos e interesantes de este curso. Que los alumnos entiendan que la computadora está para "usarla" y no simplemente para escribir texto es muy difícil de lograrlo y es de esas cosas que hasta que no lo hacen no lo entienden.
En fin, hago este comentario para que todos aquellos que hacen TDD, no se olviden que los pasos son:
1) Escribir UN test
2) Hacer que el test funcione
3) Hacer que todos los test corran
4) Hay que mejorar el diseño?
a) Si hay que mejorarlo, hacerlo, refactorizar, etc. Ir a 3.
b) Si el diseño es aceptable, ir a 1

En estos pasos creo que está claro que luego de escribir UN test hay que hacerlo funcionar, no vale escribir varios test y luego hacerlos funcionar a todos juntos.
De vuelta, es importante darse cuenta que haciendo lo último, estamos manteniendo muchas ideas, soluciones, problemas, etc. en nuestra cabeza en vez de descargarlas a la computadora, y recuerden que los seres humanos cuanto más cosas tenemos en la cabeza más nos equivocamos y olvidamos

Smalltalks 2008

2008-06-13T18:16:00.002-03:00

Quería comentarles que ya hicimos el anuncio de Smalltalks 2008. Este año será en otra fecha y otro lugar, pero esperamos tener la misma calidad de presentaciones y cantidad de gente y por qué no, mejorarla.
Estamos trabajando para que venga gente "importante" a dar key notes y lo anunciaremos a su debido tiempo. También estamos trabajando para hacer un "coding contest" y que hayan tutoriales interesantes.
El lugar elegido esta año para hacer el congreso es la Universidad Abierta Interamericana que tiene unas instalaciones muy lindas y nos han abierto sus puertas con muy buena predisposición.
El sitio web del congreso este año será http://neuquina.lifia.info.unlp.edu.ar:8001/Smalltalks-2008
Aún estamos trabajando para hacer la inscripción automática y no por mail, etc. así que hay algunas páginas que están bajo construcción.
Espero verlos a todos en el congreso nuevamente!

Por qué escribir de manera inversa?

2008-06-10T11:14:00.006-03:00

Estos días de "reposo" que tuve que hacer, los aproveché para ver algunos videos de Abelson y Sussman que son realmente muy recomendables.
Ellos hacen mucho hincapié en los mimos principios que usamos nosotros en POO y DAO, es muy interesante ver como piensan en el MIT y como lo hacían hace más de 20 años atrás!
Sin embargo, viendo uno de los ejemplos que mostraban me di cuenta que no siempre uno cumple lo que dice. Por ejemplo, vean este código:

Más allá de que es un poco difícil de entender la sintaxis porque está escrito en Scheme, lo que quiero remarcar es que para entender lo que hace hay que leer de abajo para arriba. La idea es que esta función sume los primeros n fibonaccies que son impares, y para ello utiliza el patrón
map/filter. Se debe leer, como dije, de abajo para arriba:
1) enum-interval 1 n -> crea un intervalo de 1 a n (a)
2) map fib (a) -> mapea los números del intervalo a su fibonacci correspondiente (b)
3) filter odd (b) -> filtra aquellos fibonacci que son pares, o sea, se queda con los impares (c)
4) accumulate cons '() (c) -> Acumula los resultados en una lista usando un lista vacía como valor inicial
Ahora, si estamos abogando por escribir código entendible, que se pueda leer fácilmente, etc. por qué para leer esta función tengo que hacerlo de abajo para arriba en vez de arriba para abajo que es más natural?
Me parece que sería mejor algo así (ahora en Smalltalk):

interval := 1 to: n.
fibonacciNumbers := interval collect: [ :aNumber | aNumber fibonacci ].
oddFibonacciNumbers := interval select: [ :aNumber | aNumber odd ].
^oddFibonacciNumbers

Al hacerlo así, se puede leer de manera natural, de arriba hacia abajo, de izquierda a derecha como van realizándose el computo.
Tiene una desventaja implementativa respecto de la primera versión y es que guarda todos los fibonacci para luego filtrarlo para quedarse con los impares mientras que la versión Scheme si el fibonacci no es impar, no lo guarda. Se podría lograr lo mismo haciendo:

oddFibonacciNumbers := OrderedCollection new.
fibonacciNumbers := 1 to: n do: [ :aNumber | | fibonacci |
fibonacci := aNumber fibonacci.
fibonacci odd ifTrue: [ oddFibonacciNumbers add: fibonacci] ].
^oddFibonacciNumbers

No es tan claro como la versión anterior, por lo que se podría abstraer en algo así:

(1 to: n)
add: [ :aNumber | aNumber fibonacci ]
into: OrderedCollection new while:
[ :aFibonacciNumber | aFibonacciNumber odd ]

De esta manera queda mejor expresada la idea que se quiere implementar.

Ojo con el ojo

2008-06-09T17:54:00.002-03:00

Simplemente quería hacer un comentario de tipo personal. El jueves pasado me realizaron un operación de retina del ojo izquierdo... los Wilkinson tenemos un par de problemas genéticos con los ojos... a mi me tocó algo que no es tan grave que se llama pit de papila que es un agujero en la retina. En fin, entró un poco de líquido por ese lugar, separó la retina del nervio óptico y dejé de ver algunos "pixels".
La operación fue muy interesante, pude ver todo lo que pasaba adentro del ojo porque tenía una fibra óptica que iluminaba todo. Tengo la operación grabada así que si alguien está interesado en verla me avisa!! jaja.
En fin, ahora estoy recuperándome, en una especie de reposo donde solo puedo ver con un ojo puesto que el operado está medio "atontado" por unas gotas que me estoy poniendo para que la retina cicatrice bien.
Es increíble el avance que hay en este tipo de operaciones. Me operaron en menos de una hora y salí caminando como si nada, es más, salí muy interesado en toda la operación, seguramente por el estado de "atontamiento" que tenía por el sedante que me dieron... según mi mujer parecía chico con juguete nuevo jaja.
Voy a ver cuanto puedo escribir con un solo ojo durante una semana!!!

VM de Squeak más rápido que VisualWorks

2008-06-09T17:52:00.002-03:00

Parece que Eliot Miranda está trabajando en hacer una VM para Squeak muy rápida, basado en todo su conocimiento de la VM de VisualWorks. Según dice en su blog, su intención es que sea más rápida que la de VisualWorks... veremos si lo logra. Su blog está en http://www.mirandabanda.org/cogblog/

Ejemplos de buena implementación

2008-05-27T17:10:00.003-03:00

En la materia de POO, uno de los ejercicios que tienen que hacer es implementar un modelo de medidas y otro un autómata finito determinístico y no determinístico. Son ejercicios muy interesantes y que dan buenos ejemplos de problemas de modelado e implementación.
A continuación transcribo alguna de las cosas que les comenté por mail a los alumnos y que me parecen interesantes en general:

1) En el ejercicio de las medidas, la implementación del mensaje #*, que se puede utilizar para hacer cosas como: "diezMetros * 5" o "diezMetros * dosMetros", no utiliza polimorfismo sino un "if" para solucionar el problema de multiplicar por un número o por una medida. Por ejemplo:

Measure>>* aMeasure

^aMeasure class = self class
ifTrue: [ ... multiplicación de medidas, en muchos casos puesto el código acá directamente en vez de factorizarlo en un mensaje ]
ifFalse: [ ... multiplicación por un número ]

Esta solución adolece de varios problemas:
a) Restringe la solución a multiplicar medidas y cualquier otra cosa, asumiendo siempre que la otra cosa va a ser un número, lo cual está implícito y por lo tanto puede generar errores en la evolución del modelo. Para evitar este problema de evolución, una correcta solución sería:

^aMeasure class = self class
ifTrue: [ ... multiplicación de medidas, en muchos casos puesto el código acá directamente en vez de factorizarlo en un mensaje ]
ifFalse: [ (aMeasure isKindOf: Number)
ifTrue: [ ... multiplicación por un numero ]
ifFalse: [ Exception!!! -> El modelo no está preparado para multiplicar por cualquier otra cosa ]

b) La opción anterior, por supuesto que sigue estando distante de una buena solución, por el motivo que comente en el punto a (que restringe la multiplicación a lo que conocemos ahora que se puede multiplicar), pero también porque queda claro si nos fijamos con cuidado que el colaborador externo aMeasure no es un buen nombre, porque si es una medida, cómo puede ser un Number?. Esto tiene mal olor. Es este caso puede ser interpretado como que falta una abstracción que permita "juntar" el concepto de medida y de número en algo más abstracto, que en el caso de VisualWorks se llama ArithmeticValue. Por lo tanto, Measure debería subclasificar ArithmeticValue (igual que Number) y el colaborado externo se debería llamar "anArithmeticValue" en vez de aMeasure

c) Para no restringir la multiplicación a medidas y números, hay que utilizar la técnica que se denomina "double dispacth". La idea de esta técnica es que las decisiones la tomen los objetos enviándose mensajes en vez de los programadores por medio de un "if". La solución correcta para este caso sería:

Measure>>* anArithmeticValue

^anAritmeticValue multiplyMeasure: self

Measure>>multiplyMeasure: aMeasure

"En este caso estoy seguro que aMeasure es instancia de Measure, puesto que el mensaje lo envió una Measure"
^... (multiplicación de medidas)

Number>>multiplyMeasure: aMeasure

"Soy un número y me piden multplicar aMeasure por mi"
^Measure amount: aMeasure amount * self unit: aMeasure unit (o algo así)

Esta solución erradica el if y está preparada para el día de mañana si alguien observa que se puede multiplicar una medida por algo que no sea ni una medida ni un número... algo quizá medio difícil de ver en primera instancia, pero la puerta queda abierta para esa posibilidad (algún loco le gustaría poder multiplicar por un punto por ejemplo. Para el caso de VisualWorks no parece loco hacerlo puesto que Point subclasifica ArithmeticValue como también lo hace Complex)
Fijense que también el código queda automáticamente factorizado y en el caso de querer multiplicar por algo que no tiene sentido, por ejemplo un punto, automáticamente se genera un doesNotUnderstand y no hay que explícitamente manejar ese caso en el código, los objetos se encargan.

2) Otro ejemplo de código que tiene mal olor es este que pongo a continuación y tiene que ver con la creación de una función no determinística de un atómata finito:

funcionNoDeterministica
| dictionary |
dictionary := Dictionary new.
dictionary
add: (Association key: #(1 'a') value: (Set new add:7;add:6 ));
add: (Association key: #(7 'a') value: (Set new add:3 ));
add: (Association key: #(3 'b') value: (Set new add:5 ));
add: (Association key: #(6 'b') value: (Set new add:2));
add: (Association key: #(6 'a') value: (Set new add:4));
add: (Association key: #(4 'b') value: (Set new add:2; add:5)).

^TransitionFunction dictionary: dictionary.

Si lo analizamos un poco, veremos que:
a) Nombre "dictionary" no agrega valor, no representa su rol en el contexto. En esta caso es difícil pensar un mejor nombre y creo que tiene que ver con el problema de usar un diccionario para representar las transiciones, pero esto es solo una suposición.
b) Se utiliza el mensaje #add: en vez de #at:put:
c) No queda claro qué representa la key ni el value. Por qué se usa como key un Array? y el value? Parecería por el código que se espera que el value sea un Set, pero qué termina siendo?... observen bien el código.... termina siendo un número puesto que el mensaje #add: devuelve el colaborador externo, no el receptor del mensaje. Esto demuestra además que los test realizado no son buenos, no cubren todos los casos.
d) No sería más claro tener algo así:

| transitions |

transitions := OrderedCollection new
add: (Transition from: 1 to: 7 by: $a);
add: (Transition from: 1 to: 6 by: $a);
add: (Transition from: 7 to: 3 by: $a);
....
yourself.

^TransitionFunction with: transitions

Igualdad de Set

2008-05-15T11:34:00.003-03:00

Esta semana hubo una discusión muy interesante en la lista de la materia de la UBA de POO sobre el problema de la igualdad de Set. El problema surgió porque un grupo haciendo un TP compararon Sets y les dió false cuando esperaban que el resultado sea true. Por ejemplo, si evaluamos:

(Set with: 1 with: 2) = (Set with: 1 with: 2)

el resultado es false y no true como se esperaría intuitivamente.
Fácilmente se puede deducir que este comportamiento se debe a que el mensaje #= no está redefinido en Set de tal manera que verifique si su contenido es el mismo, sino que usa la implementación otorgada por Object que define la igualdad como identidad, o sea, dos objetos son iguales si son idénticos, lo que significa que ocupan "la misma posición de memoria".
Hago esta aclaración puesto que la identidad de Smalltalk no es lo mismo que la identidad "filosófica". En Smalltalk pueden existir dos o más objetos que representen el mismo ente de la realidad y que por lo tanto cuando se los compare por identidad devuelvan false, sin embargo en la realidad hay un único ente que posee esa identidad. Por ejemplo:

Date today == Date today

Esta colaboración devuelve false, sin embargo el día de hoy (el ente de la realidad) es único e idéntico a si mismo. Es por este motivo que nunca hay que usar el mensaje #== a menos que explícitamente se necesite verificar si dos objetos ocupan la misma posición de memoria, algo que solo sucede en aquellos modelos relacionados con problema computacionales (por ejemplo frameworks mapeo relacionales, modelos de objetos distribuidos, etc.).
Volviendo al tema de la comparación de conjuntos, luego de varios emails de idas y vueltas en la lista (y un par de errores de mi parte), quedó claro que no se puede fácilmente implementar ese comportamiento y por otro lado tampoco es sencillo darle una semántica clara a esta comparación cuando se están utilizando conjuntos definidos por comprensión (aporte de Daniel Altman que quedó plasmado en la tesis que hizo junto a Hernán Tylin).
Uno de los problemas que surge al implementar el #= en Set es que se debe definir si solo se será true para aquellos casos en que se comparen conjuntos. Algo que yo había pensado es que la comparación debería devolver true si las colecciones comparadas tenían los mismos objetos, más allá de como están implementadas, pero la realidad es que no es sencillo implementarlo así y tampoco tiene sentido semánticamente. Por ejemplo:

(Set with: 1 with: 2) = (OrderedCollection with: 1 with: 1 with: 2)

¿Debería dar true o false?. Cualquier decisión que se tome al respecto es arbitraria. Por lo tanto el #= solo debería devolver true si se comparan conjuntos. Esa es la decisión que tomaron los implementadores de Squeak, donde el #= en Set está definido de la siguiente manera:

= aSet
self == aSet ifTrue: [^ true]. "stop recursion"
(aSet isKindOf: Set) ifFalse: [^ false].
self size = aSet size ifFalse: [^ false].
self do: [:each | (aSet includes: each) ifFalse: [^ false]].
^ true

Fijensé que es necesario que aSet sea instancia de Set o de alguna de sus subclasses. Esto restringe la comparación a que solo devolverá true si se comparan conjuntos. Sin embargo tiene la desventaja de no poder implementar un conjunto fuera de la jerarquía de Set y poder compararlo por igual con un Set puesto que siempre dará falso.
Una vez hecha esta salvedad, surge el problema de cómo implementar el #hash en Set, puesto que al haber implementado el #=, tengo que implementar un algoritmo de hash que cumpla con la condición que dos objetos iguales deben tener el mismo hash. Para la implementación de Object, el hash viene dado utilizando un número que se asigna a cada objeto que se crea y que se almacena en su header (fijensé que no se puede usar la posición de memoria puesto que la misma puede cambiar debido al garbage collector).
La implementación de Squeak es la siguiente:

hash

| hash |

hash := self species hash.
self size <= 10 ifTrue: [self do: [:elem | hash := hash bitXor: elem hash]].
^hash bitXor: self size hash

Podemos observar que se realiza un trade-off entre obtener un buen número y performance. Un buen número estaría dado a partir del hash de los objetos que contiene el conjunto, pero recorrer todo un conjunto puede ser time-consuming y por eso se limita a hacerlo solo en el caso de tener 10 o menos elementos.
Por lo tanto, implementar el #= en Set como uno intuye que debería funcionar no es tan sencillo, tiene sus complicaciones y trade-offs.
Una solución que me propuso Nicolás Kicillof, quién está trabajando en Microsoft en USA, es hacer como hacen ellos en su lenguaje de verificación en donde cada vez que se crea un conjunto, se verifica si el mismo no existe y de existir se devuelve el mismo. O sea, hablando mal y pronto, usan los conjuntos como los símbolos de Smalltalk. Esto implica que los conjuntos son inmutables y por ende tienen que tener un buen algoritmo de búsqueda para asegurarse de no tardar mucho cuando tienen que verificar si ya existe el conjunto (lo cual nos lleva nuevamente al hash...)
Otra solución es la que propone Daniel Altman, la cual crea una nueva manera de ver el problema completamente distinto y que me parece sumamente interesante y acertada. Transcribo lo que Daniel escribió en la lista porque no tiene desperdicio:

"[...] un Set en computación sea distinto del de la matemática, es el dinamismo que hay en el mundo de los objetos, cosa que no ocurre en principio en la matemática.
Es decir, un objeto matemático nunca tiene un estado que cambia.
Basta probar que dos conjuntos tienen los mismos elementos para demostrar que son iguales. Qué pasa en Squeak? Los elementos contenidos en un conjunto cambian a lo largo del tiempo.
Acá entra en juego una consideración bastante importante: es lo mismo hablar de conjuntos como simples “contenedores de elementos” (o sea, básicamente una estructura de datos) que hablar de un conjunto como un ente que tiene una semántica propia?
Para mí, los conjuntos interesantes son los segundos, los que tienen semántica. En ese caso un cambio en el ambiente, o en algún objeto cualquiera, pueden hacer que un elemento pertenezca o deje de pertenecer al conjunto. (por ejemplo, imaginen el conjunto de los objetos que responden true al mensaje #foo).
De ahí se desprende que la manera de comprar la igualdad de conjuntos sería comparar su semántica."

Este comentario quedó a mi entender claramente definido con un ejemplo que escribió más adelante en otro mail:

"Ejemplo: tenes el conjunto de las facturas impagas de una empresa por una
lado, y el conjunto de todas las facturas de la empresa por otro. Esos
conjuntos pueden tener los mismos elementos si nadie pagó ninguna factura,
pero son claramente distintos."

Un concepto muy interesante, ¿no les parece?

Ventajas del código autodocumentado

2008-05-08T11:33:00.002-03:00

Este año hay un grupo muy activo en POO lo cual es muy bueno porque preguntan y hacen cosas más allá de lo que comúnmente sucede en esta materia.
Por ejemplo, el otro día en la lista de POO un alumno preguntó como hacer una búsqueda de algún String particular en los métodos. Pareciera que en VisualWorks no hay manera de hacerlo directamente usando las herramientas de desarrollo que ofrece, pero como esto es Smalltalk no cuesta nada escribir un conjunto de colaboraciones para hacerlo. Así se los propuse y, debido a que es un grupo muy interesante, generaron una solución.
La solución que generaron fue:

| resultado aBuscar bloque |

resultado := OrderedCollection new.
aBuscar := (Dialog request: 'Texto a buscar:' initialAnswer: '' windowLabel: 'Buscar' for: nil).
bloque := [:class :selector :aString | | method |
method := class compiledMethodAt: selector.
( method allLiterals anySatisfy: [:lit | lit isString and: [aString match: lit]])
ifTrue: [ resultado add: method definition]
].
Object allSubclasses do: [:class | class selectors do: [:sel | bloque value: class value: sel value: aBuscar ]].

RefactoringBrowser
openListBrowserOn: resultado
label: 'Resultados de búsqueda'
initialSelection: nil

Me parece interesante analizar los errores que posee dicho fragmento de código y como se puede escribir de otra manera para que sea más simple de entender. Como errores podríamos enumerar:
1) No tiene en cuenta el caso de presionar Cancel cuando se pregunta por el string. En dicho caso buscará el String ''
2) No tiene en cuenta aquellas clases que no tienen superclase que no sea Object
3) No busca el string en Object puesto que hace Object allSubclasses en vez de Object withAllSubclasses

Respecto a como está escrito, los nombre de las variables que usaron no están muy buenos. Dichos nombres deberían ser más explicativos, por ejemplo "resultado" no dice mucho sobre el objeto que referencia.
El objeto "bloque", también es un poco confuso, no solo por el nombre sino por como termina participando en las colaboraciones. Me imagino que la intención fue refactorizar el código puesto que de estar escribiendo esto en una clase ese "bloque" estaría representado por un método. Ahora, de ser así, seguramente ese método no se activaría al enviar el mensaje #bloque, lo que demuestra que "bloque" no es un buen nombre para dicho objeto.
Mi propuesta para resolver este problema es:

| methods stringToLookFor |

methods := OrderedCollection new.
stringToLookFor := Dialog request: 'Texto a buscar:' initialAnswer: '' windowLabel: 'Buscar' for: nil.
stringToLookFor isEmpty ifTrue: [^self].

Class rootsOfTheWorld do: [ :aRootClass |
aRootClass withAllSubclasses do: [ :aClass | | methodContainingStringToLookFor |
methodContainingStringToLookFor := aClass methodDictionary values select: [ :aMethod |
aMethod allLiterals anySatisfy: [ :aLiteral | aLiteral isString and: [ stringToLookFor match: aLiteral ]]].
methods addAll: methodContainingStringToLookFor ]].

RefactoringBrowser
openListBrowserOn: (methods collect: [ :aMethod | aMethod definition ])

label: 'Resultados de búsqueda'
initialSelection: nil

Esta solución resuelve los errores del script anterior. Creo que es un poco más fácil de leer, pero el hecho de tener tantos bloques anidados complica bastante su lectura. Para hacer un poco más entendible el script, utilizo la variable methodContainingStringToLookFor para explicar qué hace el conjunto de colaboraciones "aClass methodDictionary values select: ...". De esta manera no es necesario leer toda las colaboraciones para entender qué resulta al evaluarlas.
Sin embargo, la mejor solución sería modelar esto en una clase (olvidarnos del script...), puesto que al hacerlo se podría refactorizar bastante y hacer que el código quede más "autodocumentado".
De hacerlo, obtendríamos algo así:
...>>methodsContaining: aString

^Class rootsOfTheWorld inject: OrderedCollection new into: [ :methods :aRootClass |
methods addAll: (self methodsContaining: aString inAll: aRootClass withAllSubclasses).
methods]

...>>methodsContaining: aString inAll: aCollectionOfClasses

^aCollectionOfClasses inject: OrderedCollection new into: [:methods :aClass |
methods addAll: (self methodsContaining: aString in: aClass) ]

..>>methodsContaining: aString in: aClass

"Lamentablemente VisualWorks no define le mensaje #methods en Behavior, por eso trabajo con el methodDictionary. Esto rompe el encapsulamiento pero es una solución de compromiso para no modificar Behavior"
^aClass methodDictionary values select: [ :aMethod | self does: aMethod includes: aString ]

...>>does: aMethod includes: aString

^aMethod allLiterals anySatisfy: [ :aLiteral | aLiteral isString and: [ aString match: aLiteral ]].

Creo que así queda mucho más lindo y fácil de entender. Fijensé como desaparece la necesidad de definir la variable methodContainingStringToLookFor debido a que fue reemplazada por el envío de un mensaje, #methodsContaining:inAll: , que a mi gusto además transmite mejor la intención de qué están haciendo los objetos.
Fijensé también que los métodos #methodsContaining:in: y #does:includes: podrían haber sido implementados en Behavior y CompiledCode respectivamente, de tal manera que quedasen como #methodsContainingString: e #includesString:
Me parece interesante este caso como ejemplo de cómo se puede mejorar la legibilidad del código y de cómo así y todo en algo tan sencillo pueden haber varios errores.

Programming as a Threory Building

2008-05-07T13:40:00.002-03:00

Debido al curso que estoy dando en la UCA, volví a reeler el paper de Peter Naur que se llama "Programming as a Theory Building".

Es interesante que cuando uno relee lecturas, le impresionan partes distintas a las lecturas anteriores. Eso me pasó esta vez, donde lo que más me impresionó fue esta parte donde habla del "status" del programador: (si quieren leer todo el artículo, vayan a http://www.zafar.se/bkz/Articles/NaurProgrammingTheory)

"More generally, much current discussion of programming seems to assume that programming is similar to industrial production, the programmer being regarded as a component of that production, a component that has to be controlled by rules of procedure and which can be replaced easily. Another related view is that human beings perform best if they act like machines, by following rules, with a consequent stress on formal modes of expression, which make it possible to formulate certain arguments in terms of rules of formal manipulation. Such views agree well with the notion, seemingly common among persons working with computers, that the human mind works like a computer. At the level of industrial management these views support treating programmers as workers of fairly low responsibility, and only brief education.

On the Theory Building View the primary result of the programming activity is the theory held by the programmers. Since this theory by its very nature is part of the mental possession of each programmer, it follows that the notion of the programmer as an easily replaceable component in the program production activity has to be abandoned. Instead the programmer must be regarded as a responsible developer and manager of the activity in which the computer is a part. In order to fill this position he or she must be given a permanent position, of a status similar to that of other professionals, such as engineers and lawyers, whose active contributions as employers of enterprises rest on their intellectual proficiency.

The raising of the status of programmers suggested by the Theory Building View will have to be supported by a corresponding reorientation of the programmer education. While skills such as the mastery of notations, data representations, and data processes, remain important, the primary emphasis would have to turn in the direction of furthering the understanding and talent for theory formation. To what extent this can be taught at all must remain an open question. The most hopeful approach would be to have the student work on concrete problems under guidance, in an active and constructive environment."

Ejercicio de Distancia

2008-05-02T16:38:00.002-03:00

El otro día hicimos en la facultad, durante POO, un ejercicio que me ha dado muy buenos resultados. El ejercicio consiste en modelar medidas de distancia, o sea un modelo capaz de expresar cosas como "3 metros", "5 centimetros + 10 metros", etc.
Es increíble como un tema que parece tan sencillo genera tantos modelos distintos, tantas ideas distintas sobre como resolverlo y ofrece una gran cantidad de temas para hablar y discutir.
También es interesante porque es un tema que se puede ampliar a medidas de cualquier tipo, como volumen, velocidad, tiempo, riqueza, etc. y por lo tanto como ejercicio siguiente deben hacerlo.
Lo que implemente este año a diferencia de los anteriores, es que para el modelo de medidas genéricas ellos tienen que escribir los test usando TDD, mientras que en el de distancias nosotros les proveemos los test y ellos solo los tienen que hacer andar.
Aún así, dándole los test, los diseños son distintos.... da para pensar no?

Charla de Patrick Chanezon, Google Developer Advocate

2008-04-18T17:26:00.002-03:00

Les paso un dato sobre una charla de un tema bastante "hot" actualmente que se dará en la FCEyN de la UBA (Ciudad Universitaria). Copio el mail que me llegó:

El viernes 2 de mayo a las 19 hs, en el Aula Magna del Pabellón I, Patrick Chanezon, Google Developer Advocate, ofrecerá una perspectiva técnica de OpenSocial, el nuevo estándar abierto de Google para redes sociales.
La charla se titula "OpenSocial, a standard programming model for Social Web" y será en inglés.
Resumen:
OpenSocial define un set de APIs que corren en diversos sitios sociales, entre los que se encuentran MySpace, hi5, LinkedIn, Friendster, Vostu, Sonico, Plaxo, Ning, orkut y Salesforce.com. Con OpenSocial, los desarrolladores solo necesitan aprender una API que luego les permitirá crear aplicaciones sociales para utilizar en cualquiera de aquellos
sitios, así llegando a más de 200 millones de usuarios en todo el mundo.
Como está basada en estándares web como HTML y JavaScript, los desarrolladores no necesitan aprender un lenguaje de programación customizado. OpenSocial es una especificación abierta: cualquier sitio que mantenga una red social puede implementarlo y así convertirse en
OpenSocial container.
En estas charlas, explicaremos OpenSocial, sus beneficios y utilidades; mostraremos ejemplos de aplicaciones y containers OpenSocial; y daremos un panorama de las oportunidades que ofrece.
Patrick Chanezon es API Evangelist de Google desde 2005. Actualmente, sus mayores intereses giran en torno a OpenSocial API y software social, Google APIs, REST, SOAP y Ajax, Java, Groove, JavaScript, PHP, Ruby y Python. Anteriormente, se desempeñó en Sun Microsystems, AOL y Netscape como Software Architect, B2B, Technical Evangelist, Tech Lead y Training
Manager en portales, weblogs, RSS y open source.
Más en su blog en http://wordpress.chanezon.com/

Sigo vivo y videito

2008-04-14T16:40:00.003-03:00

Hace rato que no escribo nada, principalmente por falta de inspiración y llenar un blog con pavadas no es mi estilo (bah, en realidad todo lo que escribo son pavadas! :-) ), pero no quería dejar que pase mucho tiempo y siga sin escribir algo. Se me pasaron muchas cosas por la cabeza, pero al no haberlas escrito ya se me olvidaron (me estoy volviendo viejo también).
En fin, un par de cosas que recuerdo que quería comentar es que empezó POO nuevamente este año en la UBA con el grupo de gente más grande de los últimos años, están cursando aproximadamente 35 alumnos lo cual es mucho para el promedio de 15 que veníamos teniendo. Parece que los cambios que estuvimos haciendo están dando resultados, la gente ya no le tiene "miedo" al final de la materia, ven que es "cursable" y siguen aprendiendo bastantes cosas nuevas, lo que me pone muy contento.
Por otro lado seguramente esté dando clases en el postgrado de la UCA también, lo cual es un esfuerzo pero vale la pena. Aunque ya dí cursos de postgrado, siempre es bueno tener contacto con gente de mayor experiencia en el campo que los cursos de grado.
También les comento (aunque seguro que lo leyeron en el blog de Andrés) que estamos trabajando para Smalltalks 2008, de apoco, pero va asomando...

En fin, no mucho sobre objetos este post, así que les dejo un video, que para aquellos no acostumbrados a Smalltalk les puede resultar interesante: http://simberon.com/videos/SmalltalkDemo.html

Saludos.