June 2010 - Posts
Ya he escrito sobre el:
Proyecto Hogwarts
y publicado dos posts sobre el tema TDD (Test-Driven Development)
Un ejemplo de TDD
Ejemplo de TDD: Implementando una pila (Parte 1)
Vuelvo al tema, después de mudanza, consolidación de libros, y algo de gripe o símil gripe.
Quiero hoy proseguir con el ejemplo de la pila. El ejemplo había quedado usando una Stack de .NET (decisión tomada para facilitar la demo). Ahora, en este siguiente paso, refactorizamos la implementación para usar una List de .NET, en lugar de Stack. Hacemos este cambio para mostrar que podemos modificar la implementación interna, y estar seguros de que todo sigue funcionando porque hemos escrito los tests correspondientes.
También en el este ejemplo refactorizamos el tests, apareciendo por primera vez el atribute [TestInitialize].
Finalmente, se agrega Code Coverage, que comentaremos en detalle más adelante.
Les dejo acá el video (pueden verlo directamente en Youtube en Pueden ver el video en http://www.youtube.com/watch?v=nDxwLvyMwag con opción a pantalla completa):
Les dejo el código del ejemplo desarrollado: TddStack02.zip
Estamos trabajando para que este curso quede en línea, además de tener material para un instructor de curso presencial. Además de estar escribiendo material para los siguientes cursos:
- Inversion of Control y Dependecy Injection
- Mocks
- Principios SOLID
- Algún ejemplo de aplicación con todo esto aplicado
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
Gracias al bueno de @jgabardini (blog) (y a la intermediación del bueno de @MartinSalias, (blog)), el próximo viernes 2 de Julio voy a dar una charla en la Universidad de Buenos Aires, en Ciencias Exactas, Pabellón 2. Los detalles en:
Charla: Introducción a Ajax y Javascript
Será de 15 a 17hs, en Pabellón 1, aula a designar, y es abierta al público, sin costo.
ACTUALIZACION: Me informan que será en el Aula 7, Primer piso, de ese Pabellón 1. Si no saben donde queda, pregunten en Seguridad, queda me dicen cerca de la entrada del Pabellon 1, al lado del bar.
Es parte de las actividades del equipo UTI SIS, que ya organizaron otras charlas sobre Single Sign On, Integración Continua, SVN , y otros. Visiten los enlaces, algunas de las charlas tienen video, y otros están en proceso.
La idea de esta charla es ser una introducción a cómo funciona Ajax. Como dice la página
Investigaremos que es Ajax que se basa en dos pilares:
* El componente XMLHttpRequest, nacido en el Internet Explorer para otra misión, y luego adoptado a varios engines de Javascript de navegadores de código abierto
* Javascript, un lenguaje basado en prototipos, con un gran flexibilidad
Luego de ver como es Ajax puro, programado contra tecnologías dinámicas en el servidor, entraremos en la utilización de librerías. La más popular actualmente es JQuery.
* Nuevas funciones definidas por la librería, extendiendo Javascript
* Funciones de Ajax
* Uso de algunos plugins, con tecnologías en el servidor
Y una discusión hacia dónde va todo esto.
Veremos lo dúctil que es el lenguaje Javascript, una especie de lenguaje olvidado por mucho tiempo, pero que hoy goza de una gran actividad. Es curioso como todo Ajax fue surgiendo sin un diseño previo, juntando tecnologías que habían sido creadas por separado. Y hoy alimenta gran parte de la actividad de programación de aplicaciones.
Pueden leer algo del material que estoy consultando en mis tags
http://delicious.com/ajlopez/ajax
http://delicious.com/ajlopez/javascript
http://delicious.com/ajlopez/jquery
Pueden leer el post de Martin Salias sobre Javascript – la programación del futuro
Y el material que usé hace unos años en mi curso de Ajax: Aprendiendo Ajax
Seguramente el equipo de Juan Gabardini publicará el video de la charla, y yo publicaré por acá el material.
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
Gracias a un tweet de @CReport, encontré este video de demostración: un robot que juega al pool:
Es una creación de la gente Willow Garage. Su “motto”: desarrollar robótica open source.
El equipo que llevó adelante este logro se llama PoolShark. Usaron el robot PR2, con el que está experimentando la gente de Willow Garage. El equipo comenzó a trabajar el lunes 7 de Junio, entrenando el robot a jugar, y al llegar el viernes, PR2 comenzó a jugar como lo ven. Muy bueno! Usaron una librería open source llamada FastFiz para simular la física de pool.
Pueden leer más detalles en:
The PR2 Plays Pool
Leo ahí:
The Poolshark team dealt with numerous technical challenges throughout the week: engineering a special grip and bridge so the PR2 could hold the cue, a ball detector, table localization, visualizations and input tools, shot selector, and more
Lo interesante de este trabajo es que pusieron a un robot a enfrentar un desafío en el mundo real. Usando ese “approach” tuvieron que resolver temas como: entrada difusa, falta de precisión, respuesta en tiempo real, problemas de luz, etc…
Hay otro video, de 2009, sobre el resultado de el trabajo de internos en PR2:
Más info en:
Intern PR2 Challenge 2009
Noten que uno de los miembros del Advisory Board era Larry Page, de Google. Hay una descripción del programa Beta de PR2
El entrenamiento de este robot parece prometedor. Muy buen trabajo!
Más videos en: http://www.youtube.com/user/WillowGaragevideo. Info sobre los robots de Willow Garage: http://www.willowgarage.com/pages/robots
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
En mis anteriores posts:
AjSharp Distribuido: un Roadmap
Distributed AjSharp: a Roadmap
AjSharp Distribuido: Primeros pasos
Distributed AjSharp: First Steps
escribí una breve descripción de lo que quiero para un AjSharp distribuido (mi intérprete de código abierto), y mostré unas pocas “screenshots” de programas en ejecución distribuida. Examinemos y corramos un ejemplo simple pero concreto.
Podemos lanzar el intérprete interactivo con el comando de línea
AjSharp.Console
Podemos agregar una lista de archivos .ajs con código fuente, para ser ejecutados inmediatamente:
AjSharp.Console program1.ajs program2.ajs
La idea, en este primer ejemplo distribuido, es lanzar dos instancias del intérprete, y en una, lanzar un servidor, y en otra lanzar un programa cliente que se comunique con el servidor. Ni bien tenga la conexión con éste, el programa cliente envía comandos a ejecutar en el servidor.
Primero, el código del programa servidor:
server = new RemotingHostServer(10000, "Server");
PrintLine("Server started");
La clase interna RemotingHostServer lanza un servidor de remoting. El primer parámetro es la puerta TCP, y el segundo parámetro el nombre lógico del servidor. Se pueden lanzar varios servidores en la misma instancia del intérprete. En nuestro ejemplo, sólo necesitaremos uno.
Ahora, el código para el nodo cliente:
remote = new RemotingHostClient("localhost", 10000, "Server");
at remote PrintLine("New Node");
nodeid = System.Guid.NewGuid().ToString();
// evaluate a subroutine at server
at remote
sub(id)
{
for (k=1; k<=10; k++)
PrintLine("Hello, server, from node " + id);
}
with (nodeid); // local parameter going to server
exit;
El objeto RemotingHostClient conecta con un servidor. Su constructor toma el nombre de la máquina destino, el puerto de TCP a usar, y el nombre lógico del servidor. Usando esos parámetros, internamente arma una dirección de remoting, usando un canal TCP.
Ahora que tenemos una conexión, con el comando at ejecutamos un comando en el servidor remoto. La sintaxis es:
at <server> <cmd>
Entonces
at remote PrintLine(“New Node”);
imprime un mensaje en la consola del servidor, no en el cliente. Otra variante es:
at <server> <functionorsub> with (<parameters>);
que evalúa una función o subrutina en el servidor, pasando una lista de parámetros cuyos valores se evalúan en el ambiente del cliente.
Preparé un ejemplo empaquedo, con el AjSharp ya compilado, que se puede bajar de mi Skydrive: AjSharpDistributed01.zip.
En una consola del sistema operativo, ejecutar
StartServer.cmd
Este comando arranca una nueva consola, que ejecuta el código Server.ajs.
Para ejecutar un nodo cliente
RunNode.cmd
Este es la típica salida en el código del servidor, luego de lanzar dos nodos:
Como siempre, pueden bajar el código completo desde:
http://code.google.com/p/ajcodekatas/source/browse/
en el directorio trunk/AjLanguage. Estoy escribiendo más ejemplos distribuidos: ejecutar un archivo de código fuente local en el servidor, ejecutar código en un servidor cuando un nuevo servidor informa su existencia, agentes distribuidos, etc…
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
El año pasado me encontré con Clojure, un dialecto de Lisp que compila a Java. Estuve codificando AjSharpure (ver AjLisp Family: Implementing Lisp Interpreters in C#)(La familia AjLisp, implementando intérpretes Lisp en C#), un intérprete tipo Clojure (no un compilador) en .NET (si necesitan una más completa implementación en .NET, hay un ClojureCLR, compilado usando DLR, Dynamic Language Runtime).
Clojure tiene varias características interesantes, especialmente las estructuras persistentes (persistencia acá no es grabar en una base de datos, sino tener listas, diccionarios, árboles “inmutables”; cuando uno agregar algo a una lista, la lista original queda igual, y se construye una nueva lista…), concurrencia, agentes, y más. Una de sus características es su soporte de STM, Software Transactional Memory. Más sobre estos temas en links al final de este post. De acuerdo a:
http://en.wikipedia.org/wiki/Software_transactional_memory
In computer science, software transactional memory (STM) is a concurrency control mechanism analogous to database transactions for controlling access to shared memory in concurrent computing. It is an alternative to lock-based synchronization. A transaction in this context is a piece of code that executes a series of reads and writes to shared memory. These reads and writes logically occur at a single instant in time; intermediate states are not visible to other (successful) transactions.
Hace unas semanas, leí:
Clojure concurrency Part 4
Ese artículo describe la conducta de “ref”, “dosync” y operaciones relacionadas sobre “ref”. Quería experimentar con esas características, pero en mi intéprete AjSharp. Así, que escribí una clase Reference, y agregué soporte de transacciones al lenguaje.
Ahora, puedo escribir:
reference = new Reference();
reference <- 1;
result = @reference;
La clase Reference es una “built'-in”. En AjLanguage/AjSharp el operador <- es equivalente a ref.SetValue(newvalue). Ahora, agregué el operador @ para obtener el valor, y es equivalente a ref.GetValue() (incidentalmente, GetValue and SetValue son los métodos de las interfaces de Channels y Futures, ver:
AjSharp: Implementing Futures
AjSharp: Implementando Futures
Channels and Go Routines in AjSharp (Part 1)
Canales y Go Routines en AjSharp (Parte 1)
Channels and Go Routines in AjSharp (Part 2)
Canales y Go Routines en AjSharp (Parte 2)
En esos posts, todavía escribía <-channel o <-future para OBTENER el valor desde un channel o future; ahora, estoy decidiendo poner como obsoleta esa notación, en favor de @channel, @future, que me parece más clara).
Decidí hacer que las operaciones de get/set de valor sean explícitas, usando esos operadores, en vez de hacerlas transparentes. Eso mismo había decidido para manipular canales y valores futuros.
Pero, ¿cómo se usa una referencia? Bien, empieza a cobrar sentido con la nueva palabra clave transaction:
channel1 = new Channel();
end1 = new Channel();
end2 = new Channel();
reference1 = new Reference();
reference2 = new Reference();
reference1 <- 1;
reference2 <- 2;
go transaction
{
reference1 <- @channel1;
result2original = @reference2;
end1 <- @reference1;
}
go transaction
{
channel1 <- @reference2;
reference2 <- @reference2 + 1;
result1original = @reference1;
end2 <- @reference2;
}
result1 = @end1; // 2
result2 = @end2; // 3
Las dos transacciones son lanzadas con el comando go (ver los posts citados más arriba para ver go routines en AjSharp). La primera transacción espera a recibir un valor de la segunda, usando un canal que está en la variable channel1. Los valores en reference1, reference2 en la primer transacción son los originales, aunque al mismo tiempo están siendo cambiados en la segunda. Esto es, una transacción ve un “snapshot” de los valores almacenados en referencias, tomados al comienzo de su vida. Un cambio en un valor de una referencia durante una transacción, es confirmada al final de la transacción, y entonces, se vuelve visible al resto de la transacción. Pero las transacciones que aún se encuentren en ejecución, ven el valor del “snapshot”. Si una transacción altera el valor de una referencia que ha sido alterado por otra transacción concurrente, se lanza una excepción.
Mi implementación es sencilla e ingenua. Podría mejorarla. Pero por ahora, los tests dan verde, y es lo bastante buena para mis experimentos. Internamente, cada referencia tiene un valor actual visible, un posible valor actualizado por una transacción en ejecución (no se admiten DOS valores actualizados), una lista de valores de “snapshots”, para alimentar a transacciones que aún estan en ejecución. Una instancia de Machine, asociada al thread en ejecución mantiene una lista de referencias con “snapshots”, y una lista de transacciones en ejecución.
Mis enlaces:
http://delicious.com/ajlopez/clojure
http://delicious.com/ajlopez/clojure+concurrency
http://delicious.com/ajlopez/clojure+tutorial
http://delicious.com/ajlopez/stm
http://delicious.com/ajlopez/clojure+stm
Como siempre, pueden bajarse el código en:
http://code.google.com/p/ajcodekatas/source/browse/
en el directorio trunk/AjLanguage.
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
Ya había escrito sobre una reunión en Marzo:
Agile Open Buenos Aires 2010 – Calidad en el desarrollo de software
Ahora viene una nueva reunión, mañana sábado 5 de Junio, en Buenos Aires, de 9hs a 17:30hs, en el bar del Pabellón II de Ciudad Universitaria. Esta vez, la reunión estará centrada en temas de programación. Pueden leer más detalle en:
Agile Open Buenos Aires 2010 – Coding / Programando
Leo en Invitaciones:
SEGB, junto con Ágiles Argentina, organiza este evento orientado a la difusión e intercambio de experiencias sobre metodologías ágiles. En este caso el tema es la faceta más técnica.
Los eventos Agile Open se originan en Bélgica en el 2005 pero se realizan en todo el mundo. El primero en Latinoamérica se realizó en Buenos Aires en marzo del 2009. En el país ya se han realizado 9 eventos, en 7 ciudades (Buenos Aires, Córdoba, Tandil, La Plata, Bahía Blanca, Mar del Plata y Rosario). Agile Open se organizan y realizan usando Open Space Technology.
En este evento en particular el foco será en las prácticas y herramientas que utilizan los equipos que realizan desarrollo ágil de software, por ejemplo Pair Programming, B/TDD, Integración continua, Coding Katas, Coding Dojos, y las distintas herramientas que utilizan los asistentes, como por ejemplo Ruby y Rails, Groovy y Grails, PHPUnit, PHPCodeSniffer, Project Mess Detection, jXMLCoverage, JUnit, Mockito, NoSQL.
Dónde: Bar del Pabellón II – Ciudad Universitaria
Cuándo: 5 de junio, 9:00hs – 16:00hs
Registrate: http://bit.ly/AOBsAsProg (y poder ver las sesiones propuestas)
SEGB es: Secretaría de Extensión, Graduados y Bienestar de la Facultad de Ciencias Exactas y Naturales de la Universidad de Buenos Aires.
El evento se desarrollará según el modelo Open Space:
Esta forma de organización de eventos permite realizar, con poca preparación previa, eventos de alta calidad en forma auto-organizada. Funciona para reuniones desde 5 personas hasta reuniones de varios miles de personas.
Es particularmente apto para encuentros en los que se deben resolver problemas complejos y en los que los asistentes tienen interés y pasión por tratar. En los Agile Open se utilizan como forma de difundir conocimiento e intercambiar experiencias.
El interés y la pasión se logra por un proceso de autoselección en la registración: una vez definido el Tema de la conferencia, los asistentes a los que les interesa el tema se anotarán, y al ser en un día no laboral, no dependen tanto del interés de las empresas en las que trabajan como en su deseo personal de participar. A su vez, los temas a tratar en cada sesión son propuestos y votados por los asistentes.
La dinámica durante el evento es:
* Se explica el formato y sus pocas reglas
* Los asistentes proponen sesiones (presentaciones, paneles, workshops, ...)
* Votación de sesiones (todos los asistentes votan)
* Armado de agenda (se asignan las sesiones votadas a los horarios y aulas)
* Se realizan las sesiones.
* Se hace un cierre
Encontré esta información en el post del bueno de Juan Gabardini:
Agile Open Buenos Aires 2010 - ¡Programando!
Atención: Se viene también un Agile Open en Bahía Blanca, el sábado 7 de Agosto:
Agile Open Bahía Blanca 2010
Recuerden que este año, la reunión anual latinoamericacna se realiza en Lima, Perú, en Octubre, más información en:
http://agiles2010.agiles.org/
La comunidad Latinoamericana de Metodologías Agiles en
http://www.agiles.org/
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
Ya escribí sobre el tema software para salud/medicina, en:
Primeras ideas para Hospital Information System de Código Abierto
Hacia un Hospital Information System de Código Abierto
Hacia una Historia Clínica Digital de Código Abierto
Desde hace un tiempo, estoy coleccionando información sobre el tema, en especial enlaces. Uno de los temas que surge en este tipo de aplicaciones, es HL7 (Health Level 7). ¿Qué es HL7? Podemos leer en el sitio:
http://www.hl7.com.au/FAQ.htm
Just as people from different countries with completely different native tongues are only able to communicate with each other if they can speak a common language, computer applications can only share information if they communicate with a common protocol. For people or computers to be able to share clinical data with one another, they must both:
- have functions to be able to physically communicate, e.g. speak & hear, send and receive documents and data files, share data and information. This is called "functional interoperability".
- speak a common language (in terms of nouns, verbs, grammatical structure, etc.) and share the same vocabulary that allows them to understand complex medical conditions and processes. This is called "semantic interoperability".
A group of healthcare computer systems users started developing the HL7 protocol in 1987 to create a common "language" that allows healthcare applications to share clinical data with each another. Over time the HL7 interoperability protocol became a nationally, internationally and globally accepted and accredited standard.
Es decir, HL7 es un standard para intercambiar datos, usando un lenguaje común, entre aplicaciones de salud. La misma gente de ese sitio, produjo este video:
Atención: hay una versión HL7 v2.x y luego apareció un V3 donde se pasó a un formato de mensaje XML (antes en la V2 los mensajes eran líneas de texto).
Mi colección de enlaces es
http://delicious.com/ajlopez/hl7
El sitio madre de HL7:
http://www.hl7.org
Un pantallazo de lo que es, se puede ver en la página de la Wikipedia
http://en.wikipedia.org/wiki/Health_Level_7
Un breve curso introductorio de 30 minutos:
Intro to HL7
Vean que ahí menciona que en V3 cambia el formato de serialización de mensajes: pasa a XML. Es un “gran” cambio con respecto a V2. Aparece Clinical Document Architecture (CDA). Recursos sobre CDA en: http://hl7book.net/index.php?title=CDA
Ayer, el bueno de @HiperiX me envió enlaces a sus posts:
Working with HL7 Part 1 | Blog of Gonzalo Brusella
Working with HL7 Part 2 | Blog of Gonzalo Brusella
Si quieren programar produciendo y consumiendo HL7, me parecieron potables:
http://hl7api.sourceforge.net/ (proyecto código abierto en Java)
http://nhapi.sourceforge.net/home.php (port a .NET)
Pero no vi que tuvieran soporte de V3.
Un glosario de HL7
HL7 Glossary Terms (pdf)
Tutorial interesante, uno de los primeros que leería:
HL7 Overview
Un interesante sitio, con material de V2, V3, CDA, etc:
HL7Book
Más tutoriales en
http://delicious.com/ajlopez/hl7+tutorial
Recursos y herramientas en:
HL7 Resources
HL7 Tools, Utilities and Resources
http://delicious.com/ajlopez/hl7+tools
Sobre el formato de los mensajes V2:
Understanding HL7 messages
Más técnicos sobre V2:
http://www.pbgh.org/programs/documents/LabDemoFinalReportAttach3.pdf
HL7 Format Details
Sobre mensajes en V3, con validación en línea, y ejemplos de instancia en:
http://tl7.intelliware.ca/validateMessage.faces
Los mensajes V3, al ser XML, se pueden describir en XSD. Alguien que intentó tomar los XSD para generar clases:
HL7 v3.0 MessageHandling
Tengo que leer con más detenimiento, el “approach” de
A software factory approach to HL7 Version 3 Solutions
Vean cómo ahí plantea un escenario donde hay DISTINTAS aplicaciones, de posiblemente distintos proveedores de software, que intercambian mensajes HL7:
Me pareció muy informativo, desde el punto de vista de desarrollo:
Understanding HL7 Version 3 from Developers perspective
Una comparación corta de V2 vs V3:
HL7 Standard
Dos productos comerciales:
Chamaleon HL7 Messaging Toolkit
Iguana HL7 Interfaces
Igualmente, una advertencia: no armaría un dominio de aplicación de salud, basado en lo que dice HL7. Los dominios se arman sobre la realidad, como una representación de la realidad. Lo bueno de HL7 es que es un destilación de la realidad donde nació: tiene conceptos médicos en los mensajes que puede ser interesante representar en nuestro dominio (dependiendo de la necesidad de nuestro cliente). Pero no confundiría el mapa con el territorio: basar un dominio en HL7 no veo que sea el camino. Basar un dominio en HL7, es como basar un sistema de comercio electrónico en lo que tiene que ir en los mensajes EDI, o una aplicación en general según lo que va en un XML.
Lo que sí veo es que una aplicación médica, en todo caso, deberá tener en algún momento un mapeador de su dominio a HL7.
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
El viernes que viene, 4 de junio, se organiza una reunión/cena de socios y amigos del MUG de Argentina, Grupo de Usuarios Microsoft, ver más info en:
Reunión de Socios y Amigos del MUG
Esta no es la única reunión planeada. Seguramente más adelante, en Octubre, tendremos más reuniones, con charlas, supongo todo un día, para festejar. Pero ya comienza el festejo del aniversario MUG.
El MUG, como lo llamamos por acá, fue fundado 1995, cerca de Octubre, que recuerde. Pero primero tuvo una pre-historia. Lo que sigue, lo escribo de memoria, así que sería bueno que alguien lo confirme o enmiende.
En la segunda mitad de 1994, MP Ediciones, editorial que producía entonces varias revistas dedicadas a la computación, como PC Users, sacó a funcionar un BBS (sí, se acuerdan los BBS? Y del ruido del modem al conectar? Como diría Olmedo: Éramos tan pobres… :-) llamado MP Online. Cuántos usuarios y foros! Fue quizás el más popular de su tiempo. Creo que me inscribí en diciembre de 1994, me dieron como nick ajlopez (de ahí el origen del mismo, las iniciales de los nombres más el apellido). Una de promociones que había lanzado era pertenecer también al Club Byte, un grupo formado por MP Ediciones bajo el impulso de Microsoft Argentina. Así que también me inscribí en el Club Byte.
Lo bueno del Club es que MP Ediciones nos brindaba un salón para reuniones semanales. Se podía inscribir gente de todo el país. MP Ediciones tenía su sede (creo que la sigue teniendo) en la calle Alsina. Ahí nos reuníamos, los que estábamos cerca de la ciudad de Buenos Aires. No éramos muchos, a veces cinco, a veces veinte, a veces treinta. Pero éramos entusiastas. Ahí habré dado una de mis primeras charlas de esos tiempos. Ahí conocí a Gustavo Palau, Mauricio Grimberg, Bernardo Najlis (B52), Pablo Quarracino, Korn (no estoy seguro de haber escrito bien el apellido), Sebastián Barraza, y muchos más (disculpen si no recuerdo a todos). Recuerdo un día, Mauricio Grimberg llegaba para dar una charla, pero casi no se acordaba que tenía que darla: estaba más preocupado por un trámite que tenía que hacer en MP Ediciones, que en ir al salón.
Eran buenos tiempo. Sebastián Barraza, uno de los más entusiastas, fue contratado por la gente de MP Ediciones para promover el Club Byte. Así que tenía una oficina chica, y trabaja desde ahí, y en el BBS, y nos apoyaba y promocionaba las reuniones. Charlábamos de objetos, yo comentaba sobre Java, que había aparecido a la luz en 1995, de ahí que en el BBS, sbarraza me escribió una vez: “ajlopez? Angel J. Lopez? Vos sos Angel ‘Java’ Lopez” (algo escribí sobre el tema en El origen de mi nickname). Y de ahí me quedó (dos años después, en 1997, publiqué un libro sobre “Java, la programación del futuro”, por MP Ediciones).
Las reuniones estaban muy buenas. Era una forma de encontrarse con gente con los mismos y distintos intereses. Yo recordaba lo que había leído en Fire on the valley y otros libros, sobre los clubes de computación americanos de los setenta, como Homebrew, y me entusiasmaba que comenzara a formarse algo así acá en Argentina.
No sé qué pasó, Microsoft decide abrirse del proyecto de MP Ediciones, y en una reunión en el salón, el mítico Carlos “Billy” Reynoso anuncia la formación del MUG Argentina (Microsoft User Group, entonces, que le quedó; ahora es Grupo de Usuarios Microsoft). Seguía el Club Byte, pero el MUG aparecía como entidad aparte. Podíamos seguir en uno, o en los dos grupos, como quisiéramos. Yo seguí en los dos.
Si bien Microsoft formó (medio a mano) una comisión inicial directiva, en los primeros tiempos el núcleo activo de participantes, que seguimos luego en el MUG, nos seguimos reuniendo, esta vez en una esquina, en un bar a la vuelta de MP Ediciones. Recuerdo a los que mencioné, especialmente a Gustavo Palau que estaba años después a ser el presidente del MUG. En algún momento, Pablo Quarracino ofreció su oficina, en la Av. Alvarez Thomas, cerca de la estación de tren Chacarita, para reunirnos ahí una vez por semana, luego de las 18hs, como eran también todas las anteriores reuniones: luego del horario de trabajo. Nos reuníanmos los lunes, y hacíamos planes para el naciente MUG.
Luego, fueron pasando los años. El MUG tomó lugar físico en la oficina del primer presidente (perdón, no recuero el nombre), un proveedor de Internet y otros servicios. Poco a poco se fue consolidando, se fueron agregando socios. Recuerdo que ya en los tiempos de Club Byte, Bernardo Najlis (B52) había propuesto escribir un boletín (yo propuse que tenía que estar en Internet), y al poco tiempo, él mismo puso manos a la obra, y así nació lo que hoy es la revista del MUG, ahora editada entre varios socios, como Gustavo Bachrach y, hasta hace poco, el propio Pablo Quarracino.
El MUG comenzó a dar charlas en Exo, empresa de capacitación y elementos de computación, en su sede de Av. Huergo. Ahí teníamos también reuniones. Luego de las reuniones, a la noche, nos repartíamos en autos, e íbamos a una parrilla cercana, en la Av. Independencia. Más adelante, el MUG con nuevo presidente, Palau, ocupó un lugar dentro de las oficinas de un nuevo socio que llegaría también a presidente, Pomerantz, y nos reuníamos en algún restaurante cerca de Av. Rivadavia y Larrea, que recuerde. Debe ser en alguna de esas cenas, fue la primera vez que ví y conocí a Oscar Turquet (hoy gran motor de la actividad del MUG, lo que fue un cambio, para mejor: debe ser uno de los primeros cargos rentados de la asociación, lo que permitió que Oscar se dedicara todo el tiempo a la asociación). No recuerdo si fue en el Club Byte o luego en estas reuniones, aparecieron más programados Visual Fox, como Pomerantz, Lanstein, Burstein, Copkin (hoy en la comisión), el bueno de Martín Salías (que debe ser el único de los nombrados que lee este blog… snif.. :-), y otros más, que formaron un grupo, dentro del MUG, el GUFA (Grupo de Usuarios Fox Argentina) muy activo.
Podría seguir escribiendo anécdotas. Como el gran esfuerzo que fue armar el MUG Day, todo un día de conferencias en un cine del Village Recoleta. Ahí tuvimos de invitado a Les Pinters, gran programador americano de xBase y Visual Fox, que estaba recuperándose de la pérdida de su hijo, y comenzaba a dar sus pasos en nuevas tecnologías de Microsoft. Fue un gran evento. Pero económicamente, fue deficitario. Eso provocó un problema con la filial argentina de Microsoft: no sé los detalles, pero el MUG le quedó debiendo a Microsoft, que había prestado (no aportado) dinero para el evento. Incluso, en aquel entonces, había una especie de tensión, de lucha entre Microsoft, como empresa, y el MUG. Microsoft trató de formar sus propios grupos de usuarios, más bajo su control. Pero el MUG, cuya fuerza reside en la participación de sus socios, sobrevivió a todo eso, y hoy es el grupo de usuarios más fuerte y activo de la región. (Años después, Microsoft vió la luz, y hoy hay buenas relaciones entre Microsoft y un MUG independiente).
Eso es lo bueno del MUG: la gente. Es lo que le da su fuerza.
Quince años, felicitaciones a todos los que lo hicieron posible, a los que están, los que no están, a todos!
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez