Angel "Java" Lopez

NHibernate en SQL Azure

lopez — Tue, 03 Nov 2009 16:12:26 GMT

El viernes pasado, estuve hablando con Fabio Maulo (@fabiomaulo) de varios temas: de desarrollo de software, enseñanza de la programación, y por supuesto, sobre NHibernate. Ambos vivimos en Buenos Aires, Argentina, y fue un placer hablar con él, como siempre. Yo sigo a Fabio en Twitter, y soy un subscripto a su blog. Fabio ha estado colaborando con el proyecto NHibernate desde hace años, y es un reconocido desarrollador en la comunidad .NET.

Me contó detalles de un sitio que construyó con un equipo, usando NHibernate. Lo interesate es que corre sobre SQL Azure. Pueden verlo en línea (es un sitio mexicano):

http://salondetokio.autocosmos.com.mx/

Fabio y su equipo trabajaron duro para armar este sitio, en menos de mes (estoy esperando que el equipo de Fabio comente más detalles en posts, por ahora, puedo hablar sobre lo que se conoce públicamente).

Curiosamente, el sitio está ejecutando sobre WebForms, pero sin usar ViewState, y sin tener un tag de Form en varios de los tags Body de las páginas que he examinado. Espero que Maulo y su equipo escriban explicando los detalles de implementación. El código está basado en el patrón Model View Presenter, ha sido escrito con tests automáticos, mocks, stubs, comenzando desde cerca de la presentación, hasta llegar a la persistencia. ¡Vamos Fabio! ¡Estamos esperando detalles sobre el proceso seguido y las decisiones de arquitectura! :-)

Más información sobre NHiberante y SQL Azure:

NHibernate on the cloud: SQL Azure Tests de NHibernate sobre SQL Azure, según Ayende

Quick news NHibernate with SQL Azure Los primeros pasos de Fabio en el tema: “All work… even the SchemaExport.” !!

NHibernate dialect for SQL Azure Ajustes para el SchemaExport

Estoy coleccionando enlaces sobre NHibernate y Azure en:

http://delicious.com/ajlopez/nhibernate+azure

Hay una excelente serie de posts de Brad Adams, explicando Azure en general, SQL Azure, NHibernate, Silverlight, RIA .NET Services, y más:

Index for Business Apps example for Silverligth 3 RTM and .NET RIA Services July Update

Relacionado a NHibernate y Azure, en esa serie:

Part 20: NHibernate
Part 23: Azure

¿Conocen otro proyecto que use NHibernate en “el cloud”?

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Aventuras de Programación Extrema en C#

lopez — Mon, 02 Nov 2009 09:06:08 GMT

El viernes pasado estuve visitando las oficinas del Microsoft User Group de Argentina, acá en Buenos Aires. Tenía que dictar un curso de .NET, pero hubo un corte de luz (al parecer frecuente en estos días de alta temperatura; Buenos Aires está sufriendo cortes de luz, mucha carga en los aires acondicionados creo). Ni lerdo ni perezoso, me entretuve unas horas aprovechándome de la biblioteca del MUG, sobre la que tendría que postear más. Los socios del MUG tienen acceso a los volúmenes de la biblioteca, y hay libros de temas como Windows Server, programación .NET, Test Driven Development, programación en general, desarrollo web y más.

Así que, no teniendo más deberes de los que ocuparme ni más preocupaciones en el alma (como Descartes ante la estufa… :-), me dediqué a la lectura. Estuve leyendo un libro de ASP.NET 3.5 (no tengo el autor acá), estuve hojeando el clásico “Práctica de la Programación” de Kernighan y y estaba por encarar el Sistemas Operativos de Tanenbaum (al que sigo desde las primeros avisos en la Dr.Dobbs, al principio de los ochenta, sobre compiladores multilenguajes). Pero un libro me llamó la atención, había sido devuelto a la biblioteca el jueves, por el bueno de @lmpetek: el Extreme Programming Adventures in C#

Excelente libro, escrito por Ron Jeffries, acreditado XPer, uno de los tres “fundadores” de XP (Extreme Programming), junto con Ken Beck y Ward Cunningham. Pueden seguirlo en Twitter por @RonJeffries. Leo en la página del libro en Microsoft Press:

See how eXtreme Programming (XP) works—and learn Microsoft .NET and C# programming in the process!
See eXtreme Programming (XP) in action at the hands of an XP master—and learn Microsoft .NET and C# programming in the process! In this fast-paced, hands-on exposition, Ron Jeffries—one of the leading voices and practitioners in the XP community—demonstrates that you can write well-designed, resilient code incrementally and safely, while minimizing your investment in speculative up-front design. As Jeffries builds his sample application, you get firsthand insights into what successful XP development looks like, complete with real-world challenges such as the eleventh-hour change order. For further practice and study, you can download all the author’s code—including the missteps—so you can see XP and agile concepts in action and assess how they fit into your own work.Pair program with an XP master, discovering how to:

Streamline and simplify the software development process

Work more effectively as part of an XP development team

Reduce missteps by designing, testing, and refining code in increments

Receive clearer specifications and feedback from customers

Write cleaner, more expressive code—and weed out more bugs

Conserve resources by planning and reassessing progress as you go

Maintain a sustainable work pace—and avoid burnout

Step up delivery dates, shipping the most crucial features first

Improve customer satisfaction!

Jeffries va explicando, cómo un equipo de dos personas (uno es él mismo) van aprendiendo sobre C#, .NET, mientras desarrollan el software XMLNotepad. Es muy interesante de leer, porque explica paso a paso lo que van haciendo: cómo hacen spikes, pequeñas exploraciones, luego vuelven a tests, avanzan poco a poco, escriben y se ponen de acuerdo con los tests de aceptación, las historias de usuario, cómo generan un modelo testeable, mockean parte de la interfaz de usuario, etc. Si Uds. tienen dudas sobre cómo es el desarrollo con Programación Extrema, si quiere conocer los detalles de un caso concreto, éste es el libro. Pueden aprovecharlo, sepan o no C#: la parte técnica no es la más importante, es la explicación detallada la que hace de este libro, un excelente recurso.

Hmm… ya va siendo hora de tener un sistema de biblioteca para el MUG, no? Podríamos armarlo usando XP… :-)

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Smalltalks 2009 en Buenos Aires

lopez — Sun, 01 Nov 2009 14:41:03 GMT

La comunidad Smalltalk de Argentina ha vuelto a tener actividad en estos últimos años. Ejemplo reciente fue su activa participación en el ESUG: 2009 International Smalltalk Conference. Y como prueba están las dos ediciones de las conferencias Smalltalks. Se viene la tercera edición:

Smalltalks 2009

Se realizará del jueves 19 al sábado 21 de Noviembre, en la Facultad de Ciencias Exactas y Naturales de la Universidad de Buenos Aires. Tienen que visitar el enlace e inscribirse. Hay invitados especiales, a destacar (copiado “sin vergüenza” :-) desde esa página):

Dan Ingalls

Is a pioneer of object-oriented computer programming and the principal architect, designer and implementor of five generations of Smalltalk environments. He designed the bytecoded virtual machine that made Smalltalk practical in 1976. He also invented Bit blit, the general-purpose graphical operation that underlies most bitmap graphics systems today, and pop-up menus. He designed the generalizations of BitBlt to arbitrary color depth, with built-in scaling, rotation, and anti-aliasing. His major contributions to the Squeak system include the original concept of a Smalltalk written in itself and made portable and efficient by a Smalltalk-to-C translator. Read more

¿Qué podría agregar a Dan Ingalls? Vean su trabajo de investigación reciente en Sun, por ejemplo, el Web Browser as an Application Platform: The Lively Kernel Experience. Pueden seguirlo en Twitter como @daningalls pero no escribe mucho. Aunque no relacionado tanto con Smalltalks, no puedo dejar pasar el video sobre Lively Kernel:

(Please visit the site to view this media)

Stephane Ducasse

Since September 2007, He is research director at INRIA Lille leading the RMoD Team. He was the leader of the RECAST Project. He was co-responsible of the version 3.9 of Squeak the open-source Smalltalk developed by the team of A. Kay (Turing award 2003). He is the president of ESUG. He is developing Moose an open-source reengineering platform. He is co-responsible of Pharo an open-source Smalltalk.

Read more

Alex Warth

Alessandro Warth is a computer scientist at the Viewpoints Research Institute, where he is working on the "Steps Toward the Reinvention of Programming" project. His current research interests include tools for rapid language prototyping, and improving the modularity of dynamic languages.

Pueden visitar la página del bueno de Alessandro y seguirlo en Twitter como @alexwarth.

Tim Mackinnon

Tim has been programming with objects for 15 years, however it was when he heard Kent Beck describe Extreme Programming at OOPSLA 98 and again at OT99 that he found a process that balances quality, delivery and happiness. Tim was a member of the team that created UML Modeler for VisualAge Smalltalk, he has also worked at Dashboards Software where he pioneered their use of Extreme Programming. He then built up the XP team at Connextra and was responsible for techniques such as Mock Objects and Heartbeat retrospectives. He is now a senior developer at ThoughtWorks where he is mentoring teams on XP and Retrospectives.

No escribe mucho, pero puede leer su blog Pintside Thoughts.

James Foster

As a junior-high student in 1971, James discovered the local university's computer lab and learned Basic, Fortran, and assembly. After trying other careers (commercial aviation and law), he returned to computer programming and was introduced to OOP on the Macintosh in the 1980s. Since then James has worked on large systems (primarily in healthcare) and introduced agile practices to the teams he has lead. James Foster is on the Smalltalk Engineering Team at GemStone Systems, Inc. and is an evangelist for the Seaside web framework.

Pueden seguir su blog Programming Gems (on Gem Stone) James’s comments on programming GemStone/S, Seaside and Smalltalk.

Y por supuesto, gran parte de los smalltalkers de Argentina (algunos esparcidos por el mundo, otros trabajando en empresas locales, otros en emprendimientos personales) asistirán al evento. Hace dos años escribí sobre la actividad de desarrollo y empresas: Creando con Smalltalk en Argentina.

Más información sobre el evento en Smalltalks 2009 Squeak News

Para los interesados en la actividad Smalltalk en español, y en especial en Argentina, ver:

Fundación Argentina de Smalltalk (Sitio soportado por plataforma GLASS (Gemstone/Linux/Apache/Squeak/Seaside)).
Club Smalltalk (vean ahí la participación argentina en la ESUG 2009)

y participen de la lista:

http://groups.google.com/group/clubsmalltalk

Mi colección de enlaces:

http://delicious.com/ajlopez/smalltalk
http://delicious.com/ajlopez/squeak
http://delicious.com/ajlopez/seaside

Me hubiera gustado participar (por ejemplo, presentando lo que estoy haciendo como máquina virtual en .NET, o revivir algo de lo que hice tratando de emular a Piumarta), pero en estos días estoy bastante concentrado, en muchos cursos, poca programación, luchando con el “Efecto Coto” (si ni siquiera tendré Semana Sabática este semestre… snif… :-).

(Nota adicional: el por qué de tantos enlaces en cada post mío ;-)

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Tales from the Scrum: Anti-patrones de Sprint

lopez — Thu, 29 Oct 2009 11:34:52 GMT

Recordemos: el Sprint es la iteración en Scrum: puede durar una, dos semanas, o un mes. Eso se decide según el proyecto y el equipo. En los primeros tiempos de Scrum se elegía un mes, pero ahora se prefieren sprints más cortos: una de las razones es para responder a cambios más rápidos.

El Sprint se inicia con una reunión de Sprint Planning, donde se expone el estado actual del Product Backlog (la lista de requerimientos del producto que estamos armando), y se arma el Sprint Backlog (la lista de tareas que se eligen para ese Sprint). El Sprint termina con la reunión Sprint Review, donde se presenta el nuevo estado del producto. Cada día, el equipo se reúne, y realiza la reunión diaria de Scrum, para informar el estado y comprometerse a las tareas de ese día. El ScrumMaster va acompañando al equipo para que aplique Scrum de forma efectiva.

De vez en cuando, aparecen, aún equipo saludables, algunas actitudes y actividades que podemos denominar anti-patrones: no están alineadas con los principios de lo ágil y de Scrum. Veamos algunas:

- Tomar demasiadas tareas para el Sprint: el equipo, entusiasmado (o presionado), toma más tareas que las que son materialmente cumplibles. Un equipo maduro conoce su fuerza y capacidad, y sabe hasta dónde puede llegar en cada Sprint.

- No partir bien las tareas del Sprint: Relacionado con lo anterior. Una de las actividades de la Sprint Planning es enumerar las tareas que serían necesarias para avanzar con los items más prioritarios del Product Backlog (armado por el Product Owner). La lista de tareas tiene que estar bien armada (no olvidarse de ninguna). Luego se evalúa el tiempo y esfuerzo necesario para cada tarea. Y acá he visto muchas veces esto: el equipo no parte la tarea en subtareas. Si una tarea no se parte de esa manera, es más difícil evaluarla. Yo recomendaría partir cada tarea en subtareas que puedan evaluarse en tiempo de horas. Si una tarea es “armar los reportes contables”, no dejarlo así enunciada. Pasarla a la lista de subtareas, y evaluar una por una. Por ejemplo: una lista de esos reportes, y a su vez, dividir en programar el reporte, verificarlo, documentar en el manual de usuario, armar el script de instalación, e instalarlo en el servidor de pruebas. Si no se parten adecuadamente las tareas, no podemos evaluar bien el tiempo que emplearemos. No tiene que ser una partición definitiva: se puede ir refinando con el correr del Sprint. El llevar el detalle a subtareas de horas, que puedan realizarse en fracciones de días, tiene también otra ventaja: quedan disponibles para que se tomen en la reunión diaria: la tarea de cada miembro debería ser poder terminada en el mismo día. Sino, debería anunciar qué parte de la tarea toma, y a qué punto de avance se compromete a llegar en ese día.

- Una tarea para un miembro: cada día, debería cada miembro del equipo tomar una tarea, para seguir avanzando en el cumplimiento de lo que se comprometió para este Sprint. Pero puede pasar, que una tarea queda por siempre asignada a un miembro del equipo. No es la idea de Scrum: un miembro no toma esa tarea para él por todo el Sprint. La tarea es del equipo. Que haya un miembro del equipo más capacitado para llevarla a cabo, no implica que sólo él se encargue de la tarea. Debería por lo menos hacer “pair programming”, ir educando a alguien más en el equipo, para no caer en eso de “esta tarea es para Juan” y sólo para él.

- Entregar trabajo no terminado: Iba a poner “o terminado parcialmente”. Pero no debería existir ese concepto en un Sprint. La idea es entregar una tarea, bien terminada, bien hecha. Prefiero que un equipo tome una sola tarea, y la termine bien, a que encare cuatro tareas y finalmente, a cada una le falta algo para ser considerada realmente “hecha”. Muchas veces, el equipo piensa que de esta forma va avanzando: entregar 10 tareas, aunque no estén bien terminadas. Y piensa que así es mejor. Pero la experiencia muestra que el trabajo adicional de revisarlas y completarlas más adelante, no se puede soslayar. O si lo salteamos, habremos entregado producto sin una calidad y terminación adecuada. No hay que “patear para adelante” este tipo de cosas.

- No verificar el trabajo: En el trabajo de cada, se va cumpliendo con las tareas, pero no se verifican. Así, puede pasar que lo que un miembro consideró como terminado, en realidad le falta algún detalle. Hay que recordar que el trabajo debe ser entregado de forma tal, que tenga la menor cantidad de errores o problemas al usarlo. No es cuestión de “termino tal tarea, cualquier problema me lo van a informar en el próximo Sprint”. No es la idea. El espíritu es

- Tener un Sprint de “estabilización del producto”: Como las tareas se fueron entregando de forma no “totalmente hecha”, se elige un Sprint para “pulir” el producto, revisando lo entregado, para mejorarlo y corregir pequeños temas. De nuevo, no es la idea: no debería haber, en lo posible, este tipo de “estabilización”. En vez de haber entregado esas tareas de forma parcial, se deberían haber entregado menos tareas, pero bien terminadas. Como digo, el producto de cada Sprint debe venir “en paquete con moñito”: evitar la entrega parcial.

- No hacer “pair programming”: si bien Scrum no exige esto, he visto que es común que alguna disciplina ágil, como la programación de a pares, se saltea siempre. Ya sea porque el equipo es pequeño y hay muchas tareas, o por la razón que sea, todas las tareas se ejecutan individualmente. El trabajo de a pares facilita la terminación de la tarea, dos cabezas piensan más que una, hasta se verifica mejor el trabajo entregado, y tiene un beneficio adicional: la integración del equipo.

- Demasiados cambios en los requerimientos, entre Sprints: Esto va más allá del Sprint, pero puede pasar: de Sprint a Sprint, los items del Product Backlog y sus prioridades, van cambiando demasiado. Lo que era prioridad hoy, mañana ya no es. Lo que se pidió para este Sprint “porque era importante”, resulta que para el próximo sprint ya no se tiene en cuenta. Tal cantidad de cambios, es indicación de una falta de rumbo. Y puede llegar a desmotivar a un equipo: ve que cada cosa que va armando, al final, no se usa, y se tiene que dedicar a cada momento a otra cosa.

- Olvidarse de la retrospectiva: una reunión importantísima del marco de trabajo Scrum. Parece que esta reunión muchas veces queda en el camino. Con el gusto diario de hacer tareas, con la concentración que implica el Sprint Planning, con la excitación de la entrega en el Sprint Review, al final, no hay tiempo o nos olvidamos de hacer la reunión de retrospectiva. Un gran error: es la gran oportunidad del equipo para reflexionar sobre lo que está haciendo y sobre la salud del proceso.

- Saltearse algún Daily Standup Meeting (la reunión diaria): Alguna vez, por temas de tiempo, de organización de un día en particular, se saltea esta reunión. Si una parte del equipo no puede asistir (ejemplo: fue a una reunión de capacitación), se debe acordar: o la realizamos igual, aunque sea con dos miembros, y luego, si se reintegra el resto del equipo, hacemos una sincronización; o la pasamos ese día a otro horario. Pero les recomendaría no saltearse esta reunión.

El primer paso para ir corrigiendo estas situaciones, es darse cuenta: esa es la función de la retrospectiva. El segundo paso: no corregir todo de una, sino ir encarando problema por problema: comprometerse mejorar en un punto, y revisar la mejora en la próxima retrospectiva.

Post relacionado: Tales from the Scrum- Anti-patterns de la reunión diaria

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Segunda Nerddinner en Buenos Aires

lopez — Wed, 28 Oct 2009 15:44:44 GMT

Hace un par de meses ya tuvimos la primer nerddinner de Buenos Aires, ahora se viene la segunda!

Pueden ver los detalles en:

http://www.nerddinner.com/1236

Pueden inscribirse ahí, o contactar a los organizadores @PabloZaiden @Rodolfof por Twitter. Es el jueves 5 de Noviembre, 21 horas, se espera cerveza y pizza, y conversaciones nerd a full!

La anterior (y primera en Buenos Aires) se desarrolló en http://www.lamaie.com.ar (donde suelo comer empanadas que corto con cuchillo), buen lugar, cervezas, y pizzas. Asistieron una veintena de nerds locales, y hubo interesantes discusiones, de todo tipo, desde multitouch hasta “mi mac enciende más rapido que tu Windows 7”. Nerd a full… :-)… Por ejemplo, el bueno de @Rodolfof me explicó su trabajo en el “metadata framework” que estuvieron implementando en Lagash,

La segunda será en la pizzería San Carlos, en Rivadavia 4548:

Según el bueno de @Rodolfof ahí se reunía la gente de FidoNet en los 90. Yo no iba a esas reuniones. Pero recuerdo la pizzería (y café) de la época de principios de los 80. Iba a desayunar ahí, cuando llegaba de Quilmes, a trabajar en un cliente que vendía máquinas y sistemas (en aquel entonces, se vendía todo junto). Tenía que programar con Ohio Scientific, computadoras Ontel, alguna Cromenco, bueno… éramos tan pobres… :-)

Siempre pueden organizar una nerddinner en su ciudad, Uds. mismos, visitar la portada del sitio:

http://www.nerddinner.com

Ven ahí las que están siendo planeadas para los próximos días, en todo el mundo:

La aplicación que soporta al sitio está hecha con ASP.NET MVC, y está publicado el código en:

http://nerddinner.codeplex.com/

Para entender cómo lo fueron haciendo en ASP.NET MVC, se pueden bajar un .pdf desde http://tinyurl.com/aspnetmvc. Pueden probar de ejecutarlo en Mono, leer: http://www.jprl.com/Blog/archive/development/mono/2009/May-14.html

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Resultado de la VAN ALT.NET Hispano sobre Generación de Código

lopez — Tue, 27 Oct 2009 16:15:40 GMT

Gracias a la comunidad ALT.NET Hispano, quedó publicado el video de la VAN (des-conferencia virtual) sobre Generación de Código, al que fui invitado. Ahí presenté mi proyecto personal preferido, AjGenesis, generador de código, escrito en .NET, y publicado en código abierto. Pueden ver el resultado en:

VAN – Septiembre 26 de 2009 – Generación de Código

Ahí encontraran el video, enlaces, lecturas, y la presentación que utilicé, para descargar.

Al final de mi presentación, hubo discusión y preguntas. Uno de los puntos mencionados, fue cuales serán los próximos pasos de AjGenesis. Algo comenté ahí, pero me gustaría contestar algo más en detalle por acá:

- En principio, es un proyecto que me gusta, y que me ha resultado muy flexible. Y al que voy a seguir incorporando características.

- Hay desarrolladores que lo usan, pero son pocos, o por lo menos, no publican resultados, o escriben posts (en estos últimos 5 años, debe haber 4 post sobre AjGenesis NO escritos por mí, solamente; tampoco es mencionado mucho en las listas de correo, sobre desarrollo de software en general, que frecuento (debe haber dos o tres menciones en los últimos 3 años)). Entonces, como digo en la des-conferencia, “lo uso yo y mi tía Carlota”… :-)

- Hay que mejorar la documentación. Por ahora, estoy escribiendo posts casi todos los meses sobre el tema.

- Lo que me gustaría encarar, es poner en línea el tema de Code Generation as a Service, que menciono en la charla.

Como comento hacia el final de la presentación, cuando expongo sobre generación de código, lo hago mostrando ideas e implementaciones con AjGenesis, porque me siento más cómodo. Pero, por supuesto, hay multitud de otras herramientas, más documentadas, con más soporte, con más comunidad, que pueden usar. La idea de la presentación es que tengan contacto con lo pragmático de generar código, y que vaya quedando en claro por qué estamos hoy generando código: ante la multitud de tecnologías, frameworks y librerías, es un poco difícil zafar de escribir y escribir código. Y como las tecnologías, frameworks y librerías son buenas, en general, es difícil también, hoy por hoy, prescindir de ellas. He dejado enlaces a otras herramientas en la página de la VAN.

Otro camino a explorar sería abandonar todo eso, y buscar la simplicidad. Algo expongo en ¿Es tiempo de volver a la simplicidad?. Pero, yendo a la realidad, de todos los días, eso todavía no está, y quien sabe cuándo volveremos o conseguiremos eso. Así, que caemos de nuevo en tecnología, frameworks y librerías.

Como expongo en el post citado, otro camino, que algunos de Uds. habrán recorrido, habrá sido armarse su propio framework y librerías. Ante la calidad y cantidad de librerías disponibles, y todas las necesidades a cubrir, es un camino algo difícil de recorrer actualmente. Y aún recorrido ese camino, muchas veces nuestro framework necesita que trabajemos incorporando código o archivos de configuración, que bien podemos generar automáticamente desde un modelo.

Si es la primera vez que visitan este blog, y quieren conocer por qué le dedico tanto tiempo a la generación de código, y encontrar una explicación más detallada de lo que planteo en la charla y en los párrafos de arriba, les recomiendo leer primero mi post Sobre la generación de código. Más enlaces, más relacionados con AjGenesis, en Ver la luz con generación de código y AjGenesis :-)

Como verán en el video, y en algunos enlaces que están en la página de la VAN, y leen los posts anteriores sobre generación de código y AjGenesis que ya he escrito, la idea no es solamente generar código, sino generar código desde un modelo: llevamos años eludiendo modelos, solamente dibujándolos (en UML, por ejemplo), pero sin utilizarlos como instrumentos para implementar efectivamente un sistema. La conversión de un modelo a código concreto, ha quedado en nuestras manos. Y ante la cantidad del trabajo, es hora de “elevar el nivel de abstracción”, y comenzar a basarnos en modelos. De alguna forma, eso es lo que hicimos cuando pasamos de programar en lenguaje de máquina, a ensamblador, y luego, a lenguajes de programación: nos olvidamos de los detalles, y le dejamos ese trabajo a la propia máquina. Estamos generando código cada día: ya no armamos el .exe a mano (como en los tiempos de la ENIAC), sino que hay herramientas (compilador ¿recuerdan?) que pasa nuestro modelo (el programa escrito en un lenguaje de modelado de instrucciones, llamado lenguaje de programación) a código ejecutable (instrucciones para nuestros procesadores).

El tema es que desde hace años, nos hemos quedado en ese nivel de abstracción. Menciono en la charla, que hubo excepciones: hubo algunos avances y adoptamos modelos para olvidarnos de los detalles, en algunos casos. Un caso que menciono: Visual Basic (el clásico, de los noventa). Cuando apareció Visual Basic, ya no hubo que programar ventanas, botones y eventos de Windows, en C, ocupando decenas de líneas para hacer un simple “Hola, mundo” (era lo que yo llamo la “Era Petzoldiana”). Ahora, con un modelo gráfico, arrastramos botones, cajas de textos, y voilá: tenemos el código de un formulario (vean que en .NET, tanto en VB.NET como en C#, todavía es más evidente que generamos código: el diseñador genera el código correspondiente a crear los controles, ponerles las propiedades, por nuestra cuenta y orden).

Bueno, basta por ahora. Pasen y vean el video, vean las discusiones, y participen de la comunidad ALT.NET Hispano.

Si les interesa el tema de la generación de código, hay una lista de correo, sobre el tema, en español. Pueden ver los mensajes y suscribirse, en:

http://groups.google.com/group/codegeneration

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Code Kata: Capturando páginas web

lopez — Mon, 26 Oct 2009 09:31:03 GMT

Para practicar, como Code Kata (y también, como prueba de concepto para un proyecto relacionado con Hacia una Historia Clínica Digital de Código Abierto), estuve codificando un programa de Web Scraping. Pueden bajarse el código completo desde: Web Scrapping Example (pensé que en inglés era “scrapping” con doble p, así que quedó por ahora con ese nombre :-)

La solución, escrita en C#, contiene un proyecto de librería de clases, uno de tests de Visual Studio, y un programa de demostración, del tipo consola. Fue interesante codificar un mini HTML parser (simple, que no contempla todos los casos, sólo los necesarios para el trabajo), que soporta el análisis de páginas mal formadas. El usar TDD (Test-Driven Development) me permitió ir codificándolo de forma de estar seguro de lo que necesitaba como resultado, y además, que ese resultado fuera el correcto. Ejemplo de test simple:

[TestMethod]

public void ParseSimpleTag()

    HtmlParser parser = new HtmlParser("<html>");

    HtmlToken token = parser.NextToken();

    Assert.IsNotNull(token);

    Assert.AreEqual(HtmlTokenType.Tag, token.TokenType);

    Assert.AreEqual("html", token.Name);

    Assert.IsNull(parser.NextToken());

Para capturar las páginas, usé System.Net.WebClient, con código tan simple como:

private string GetContent()

    WebClient webclient = new WebClient();

    return webclient.DownloadString(this.address);

Como demostración, en el programa de consola, parto de explorar la página:

Medline Plus Drugs

Lanzando el programa de consola, aparece la salida, capturando algunos cientos de páginas, sobre información de drogas medicinales (efectos, posología, contraindicaciones, etc):

Exploro las páginas que apuntan a la información de drogas por letra, obtengo los enlaces a cada droga, traigo el contenido de la página, extraigo la información que me interesa (descartando el principio y el fin de la página) por cada droga. Un ejemplo de página:

Al final, genero una página de índice:

Podría implementar un mejor parser de HTML, y algunas operaciones más de extracción de datos. Pero para lo que quería obtener, me bastó. Y fue una buena experiencia de TDD.

Si usan la información generada, recuerden de leer los términos del sitio original (entiendo que necesitan una autorización para usarlo de forma comercial, no parece que haya problema en capturar los datos en un utilitario no comercial).

¿Por qué no explorar directamente la web para obtener estos datos? Porque el contexto de la prueba de concepto que me impuse, es que los médicos y enfermeros no tienen acceso a Internet desde todas las máquinas donde van a estar trabajando.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Tales from the Scrum: No esperemos a Superman

lopez — Sat, 24 Oct 2009 14:18:29 GMT

En estos días, buscando ejemplos de antipatrones de Scrum, me encuentro con el “Hero-Driven Development” (visiten todo el blog Scrum is Scrum). Hace poco comentaba sobre las “prima donnas” en desarrollo en Tales from the Scrum- No somos Q. El caso que quiero comentar ahora, es distinto. El desarrollador super héroe de nuestra historia, puede ser un tipo apreciado, querido por el equipo, reconocido en su campo. Es uno de esos desarrolladores que puede programar mucho más que los demás. Steve Mc Connell los llama 10X Developers. Pero puede causar problemas. Veamos (basado en el blog que mencioné):

Problema: En el medio del desarrollo, surge un problema. Puede ser una configuración de Windows Communication Foundation, un tema de mapeo de Hibernate, una instalación en JBoss. No importa. El problema es complejo, y bastante técnico. De pronto, se abre la ventana, y entra nuestro “programador héroe”, reluciente en su traje. Se sienta, mira el código, entiende el problema, y lo va solucionando. El equipo, arrobado, se queda atrás, mirando, cómo nuestro Superman del código, va resolviendo el más intricado nudo de desarrollo. El héroe, concentrado, no habla ni explica. Parece relajado, lo que hace es “pan comido” para él. Entonces, en un momento, para, el problema está solucionado, levanta la vista, mira al equipo, y sale volando por la ventana, directo hacia el atardecer. Gran música de fondo.

Contexto: El equipo no sabe cómo solucionar el problema técnico que surgió. Es algo en lo que tienen poca experiencia. Trataron de solucionarlo, pero no pudieron, y están entrando en pánico. Pasan las horas, y no avanzan. Todo está empantanado. Entonces, encienden la señal, para llamar al super héroe.

Fuerzas: Vivimos en tiempos de cumplir los compromisos que asumimos para la iteración. Queda poco tiempo para la entrega. Todo indica que necesitamos una solución rápida.

Solución: No hay que buscar solución rápida. Primero, habría que haber previsto el riesgo tecnológico, desde el propio equipo. Los miembros deberían haber anotado que en algún momento se toparían con una tecnología que no conocen, y tendrían que haber tomado la tarea asignándole más tiempo. Pero bueno, supongamos que no se pudo hacer eso. El problema de arriba, es que el equipo delega la solución FUERA del equipo. El equipo, de alguna forma, “se lava las manos”. La actitud del superhéroe también conspira para eso. No es ése el camino. El equipo no debería perder “ownership”, propiedad y responsabilidad del producto, y de cada pequeño o gran problema. El desarrollador super héroe, que los hay, debería haberse integrado al equipo, compartiendo su conocimiento. Debería actuar como consultor del resto del equipo, pero trabajando con él. Y cada cosa que haga, con el equipo, será considerada como cualquier otra tarea de otro miembro: deberá cumplir con los estilos pactados, las métricas adoptadas, la definición de “hecho”. No debe ser un miembro “distinguido”. Lo que haga, debe estar público y lo más entendible posible para el resto del equipo. Tal vez no consigamos una solución tan rápida como la de arriba. Pero seguramente, a largo plazo, estaremos construyendo un equipo más responsable.

Recuerden: uno de los grandes entregables, en Scrum, es el equipo.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

VAN sobre Boo con Rodolfo Finochietti

lopez — Fri, 23 Oct 2009 09:22:26 GMT

Vuelven las VAN (Reuniones Virtuales) de ALT.NET Hispano. La próxima, es este sábado 24 de Octubre, a las 18:00 GMT/UTC (Greenwich) (En Buenos Aires, con GMT-3, serían las 3 de la tarde). El tema será, principalmente, el lenguaje Boo, a cargo del bueno de Rodolfo Finochietti (@rodofof).

Pueden ver detalles en

VAN sobre Boo con Rodolfo Finochietti, Sábado 24 de Octubre

Será en parte, continuación de la anterior

Alt.NET Hispano- VAN con Martín Salías y lenguajes en .NET

Pueden ver el video resultado de esa anterior reunión en:

Virtual ALT.NET sobre Lenguajes

Son todos temas como los que tratamos en algún TechNight de Buenos Aires, el año pasado: lenguajes de programación e implementaciones en .NET (ahí dejé bastantes enlaces sobre los temas que ahora están siendo actualizados en esta serie de VANs).

Según adelanta Rodolfo, el tema será:

Básicamente mi exposición se va a centrar en porque me gusta Boo. Todos los lenguajes estáticos en .NET son bastante similares (con el DLR esto cambio un poco), y esto creo yo tiene una razón que voy a explicar en el charla. En cambio Boo no se parece un lenguaje .NET. Su diseñador (Rodrigo De Oliveira) lo creo como un herramientas que le facilita la construcción de aplicaciones.

Resumiendo: Voy a hacer una intro al diseño de lenguajes estáticos en .NET y después me voy a centrar en Boo y sus características.

Recuerden:

Si no conocen qué es una reunión VAN, pueden consultar VAN meetings. Para ver cómo se desarrolla una VAN de ALT.NET Hispano, y qué software necesitan para asistir, ver Descripcion-de-Reuniones-VAN. Pueden ver el historial de anteriores reuniones VAN (visiten las que dieron, por ejemplo, sobre NHibernate, WPF y demás) (yo ya participé en VAN sobre Scrum y en otra sobre generación de código, que quedará publicada en estos días). Supongo (pero confirmen) que la URL de entrada de la VAN de Martín será http://snipr.com/virtualaltnet. Cualquier cosa, pueden consultar la lista de correo de ALT.NET Hispano. También pueden suscribirse para proponer nuevos temas, y colaborar con la comunidad.

Visiten el sitio de Boo si quieren averiguar más sobre el lenguaje, y lean el Boo Manifesto. Tomé la imagen del blog http://blogs.codehaus.org/people/bamboo/archives/boo.html.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Tales from the Scrum: No somos Q

lopez — Thu, 22 Oct 2009 10:22:39 GMT

No se si conocen o recuerdan al personaje de Q, que apareció en el capítulo presentación de Star Trek: Next Generation. Dotado de poderes sin límites, el personaje interpretado por John de Lancie ha aparecido en varios episodios, siendo uno de los favoritos de la audiencia trekkie. En la tercer temporada de Next Generation, en el capítulo Déjà Q le quitan los poderes, y pasa a ser un simple mortal, que tiene hasta que comer para sobrevivir. Se le sugiere integrarse a la tripulación de la Enterprise, pero él responde que no está acostumbrado: “Es difícil trabajar en grupo cuando se es omnipotente”.

Q nunca podría ser un buen miembro de equipo Scrum. Recuerden: Scrum es un marco de trabajo para producir software EN EQUIPO (se puede extender para otras actividades, pero siempre en equipo). La idea de equipo en Scrum es fuerte: miembros con distintas habilidades y competencias, que trabajan coordinados para ir armando, iterativamente, el producto que el cliente necesita. En general, se usa la figura del Scrum Master para mantener el equipo dentro de las buenas prácticas, como mantener la reunión diaria, evaluar correctamente el Sprint (iteración), actualizar el backlog de sprint, ver que se arma y priorice lo mejor posible el product backlog, etc.

Pero, en el día a día, lo que cuenta es el trabajo en equipo. No hay lugar para “prima donnas” o “Qs” en un equipo Scrum. Claro que puede haber miembros con más “seniority” en un tema técnico, o en alguna habilidad (como diseño gráfico, o base de datos). Pero lo importante es que toda tarea, y su resultado, queda a cargo del equipo. No hay “me corto solo” en Scrum. No hay actitudes de “yo lo hago mejor, y hago esto, y nada más”. No hay “yo me encargo de la base de datos, lo demás no”. No hay “esto lo hago yo, porque lo hago mejor que Uds.”. Debe haber “esta tarea la tomo yo, si quieren, hago pair programming con X, y dejo claro cómo lo hice, para que mañana otro pueda seguir con esta tarea”. Si no se puede llegar a esa actitud, por lo menos, debemos luchar para conseguirla, y marcar nuestra falta en las retrospectivas (recuerden que para eso están las reuniones de retrospectivas: no para marcar errores, sino para detectar malas prácticas, o formas de trabajo no efectivas, y mejorarlas).

Cada tarea es del equipo.

Tomemos un ejemplo en concreto. Puede que haya en el equipo alguien ideal para escribir el manual de usuario de una parte del sistema que estamos armando y entregando (ciertamente, hay manuales de usuario, y es muy probable que se algo que para el cliente tiene valor de entrega y nos lo pida; sino, es, en general, un buen “over-delivery” que hace que el producto entregado tenga mejor recepción y uso). Supongamos que esa persona, llamémosla Juan, se recibió de “Technical Writer”, o que es el que mejor conoce esa parte del sistema. ¿Será él el que tome esa tarea? Un día, al comienzo, en la reunión diaria, Juan tome la tarea. Pero bien puede ser que sea una tarea que insuma varios días: hay que escribir una tabla de contenido, un glosario de los términos, una introducción, un paso a paso, sacar “screenshots” y ponerlos en el documento, escribir sobre el proceso A, el B, el C… En definitiva: la tarea puede partirse en varios pasos. Y entonces, seguramente otros miembros del equipo podrán colaborar con alguna de las subtareas. El miércoles, Juan está enfermo, y falta. Pedro, que estuvo colaborando con él, bien puede seguir con la tarea: aprendió cómo se organiza el material, cuál es el ejemplo que se estaba desarrollando en el manual, y puede seguir con el tema. Mientras tanto, el documento va quedando publicado en el repositorio de código del equipo. José “odia” hacer documentación. Pero igual revisa el documento parcial producido, y descubre que un “screenshot” no corresponde con lo el ejemplo que se explica. María detecta que se está usando mal el tiempo verbal. Francisco, que está desarrollando otra parte del sistema, y es el menos familiarizado con el tema del manual, apunta que no se entienden algunos términos, que el creador original del documento toma por sabidos por todo el mundo.

Cuando al final del Sprint, el documento es entregado, casi todos los miembros del equipo pasaron por la producción del mismo: escribiendo, revisando, juntando material, mejorando una parte, sugiriendo cambios. Y ese entregable, es responsabilidad del equipo. Si luego se detecta que hay un error tipográfico o de concepto, es el equipo el que se hace cargo de ese defecto.

Trabajando en equipo, hasta capaz le ganamos a Q y todo… :-)

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Una interfaz multitouch de 10 dedos

lopez — Tue, 20 Oct 2009 09:03:14 GMT

Este es un video de demostración, donde se ve en acción un dispositivo multitouch de la gente de http://10gui.com/:

Over a quarter-century ago, Xerox introduced the modern graphical user interface paradigm we today take for granted.
That it has endured is a testament to the genius of its design. But the industry is now at a crossroads: New technologies promise higher-bandwidth interaction, but have yet to find a truly viable implementation.
10/GUI aims to bridge this gap by rethinking the desktop to leverage technology in an intuitive and powerful way.

(Please visit the site to view this media)

Más información en http://10gui.com/background/. Pueden seguir a Clayton Miller en Twitter: @claymill.

Es interesante ver la idea del pad de dibujo ahora llevado a ser multitouch. De esta manera, podríamos agregar capacidades multitouch a cualquier monitor o hardware, sin necesidad de usar un display multitouch. El problema: los dedos quedan fuera de nuestra visión. La solución que encontró esta gente de 10gui es que los dedos se detectan y se siguen en pantalla, donde se marca su posición. Funciona de manera similar a como hoy manejamos el mouse, sirviéndonos de guía el cursor en pantalla.

El otro punto interesante es eso que dieron en llamar “con10uum” y la interacción por conjuntos de dedos. Imagino que será similar a aprender un instrumento musical: hay que practicar los movimientos, pero con algo de esfuerzo inicial los gestos por dedos parecen prácticos.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Enseñando a programar (Parte 1)

lopez — Mon, 19 Oct 2009 09:47:00 GMT

El tema que señala el título de este post es un tema amplísimo, del que habría tanto para decir y discutir. Veamos de tratar algunos puntos, que surgen de experiencia personal, e ideas sin probar que van rondando mi cabeza desde hace unos años.

Primero, una aclaración: si bien gran parte de mi actividad semanal (en estos tiempos, más del 60% del tiempo que empleo), está dedicado al dictado de cursos (en empresas e institutos acá en Argentina, o en charlas en distintas ciudades) me considero no un instructor de programación, sino un desarrollador de software que por esos accidentes de la vida terminó dedicando tanta cantidad de sus horas al dictado de clases. Pero no soy una persona pedagógica, o que haya estudiado para enseñar sino, como muchos otros instructores, soy alguien que programa y que muestra algunos temas de programación, desde mi propio óptica personal (hace años que no doy un curso oficial o de Sun o de Microsoft, prefiero dar mis temas a mi forma y con mis temarios).

Segundo: prefiero programar que enseñar. Contrariamente a lo que algunos de Uds. podrían pensar, para mí enseñar no es la mejor forma que imagina de pasar mi tiempo profesional, por lo menos en cursos presenciales de la forma en que me toca ahora dictar. Prefiero escribir, leer, programar ejemplos, pruebas de conceptos, aplicaciones completas, describir temas en posts, antes que estar dictando una clase presencial (una charla es otra cosa: es más interesante, es para presentar un tema, y llamar a la acción a los asistentes, sin tener que seguir por semanas hablando de lo mismo). Cuando tengo, digamos, un curso para las 18:30, ya sé que ese día no puedo trabajar hasta las 18hs en un proyecto, o no puedo irme a almorzar tarde, o no puedo salir de viaje a otra ciudad, o no puedo… o voy a salir demasiado tarde para ir a cenar tranquilo, o pasar por tal lado, o … y mil cosas más. Un curso es un clavo en el medio de cualquier agenda a armar. También pasa que un curso que no es nocturno, parte al medio cualquier día de trabajo, especialmente cuando trabajo en un equipo Scrum. Como los cursos tienen días ocupados durante varias semanas, también se me complica organizar cualquier visita al interior de mi país, para dar una charla sobre un tema. En definitiva, curso presencial con muchas clases, es un incordio para cualquier agenda.

Y una de las cosas que más me cansan, a esta altura de mi vida, es hablar, hablar y hablar durante horas en un curso. Vuelvo a mi cubil, a veces, bastante cansado y congestionado, nada más de hablar. Imagino que en cualquier momento comienzo a dar una clase mostrando cosas en el proyecto y explicando lo que hago escribiendo en el Notepad… :-)

Hechas esas confesiones personales, respiro hondo, y paso a comentar algunos problemas que detecto en los cursos que conozco, los míos.

Muchos de mis cursos se pueden circunscribir a estos tipos:

- Grupo de gente que conoce algo de programación, que pueden estar en distintos niveles, y quieren aprender un tema de tecnología, ejemplo: ASP.NET o JSP.

- Curso con máquina o sin máquina y proyector

Bien, comienzo por los temas que veo que no están del todo bien y se pueden mejorar, o cambiar completamente por otro “approach”.

Notemos que los cursos presenciales tienen un gran problema: son, justamente presenciales. Hay que combinar los horarios de todos los que quieren participar, reservar tal tiempo a tal hora y lugar; también tienen que estar todos presentes. Esto es un resabio de como se enseñaba en las universidades que comenzaron a aparecer en la Edad Media: como no había libros, el papel no existía o era caro y los profesores escasos, la única forma de enseñar era presencial: juntar un grupo que tenía que escuchar a un profesor mientras daba un tema. En aquellos años incluso se estudiaba para ejercitar la memoria ante la escasez de elementos para tomar apuntes.

Pasaron los siglos y veo seguimos con el mismo esquema. Algunos problemas derivados de esto:

- Cada asistente tiene que venir, a cada clase. Si llueve, si está complicado en el trabajo, si se enferma, por lo que fuera se pierde una clase que en generle al es irrecuperable presencialmente. Tiene que estar disponible cada día al horario en que se dicta el curso, por varias semanas a veces. Y si un día se le complica asistir lo más probable es que falte o que llegue tarde y no pueda aprovechar bien la clase.

- Cada asistente mismo tiene que estar con el ánimo más despierto, durante varias horas, para captar todo lo que se dicta en el curso.

- Como un curso presencial implica asignar recursos escasos, como lugar, proyector o máquinas, sala, etc., entonces cada clase dura por lo menos 3 horas durante las cuales o se dan demasiados temas, de tal forma que no hay tiempo de asimilar, o se dan pocos y el curso se encarece por durar más tiempo.

- El instructor tiene que explicar algo que ya explicó, probablemente, cuarenta veces.

- Como los asistentes, el instructor también tiene que estar con todas las luces, explicar de forma clara y tener todas las neuronas prendidas en cada clase, que se repite y repite a lo largo del año.

- No siempre el lugar de dictado es el adecuado: o no está cerca o no tiene todos los elementos en condiciones.

- No todos los asistentes tienen el mismo nivel de conocimientos inicial con lo que no todos van aprovechando el contenido de la misma forma.

- Si trabajan con máquina, el curso se alarga. Se necesita más tiempo para corregir ejemplos en cada máquina. También pasa que algunos asistentes terminan antes y otros quedan trabados. Coordinar las distintas velocidades es difícil de manejar. Muchas veces sugiero trabajar de a grupos, con poco éxito. Pasa cuando los asistentes son particulares que no se conocen entre sí y hay una máquina por persona: la gente prefiere encarar por su cuenta, en solitario, cada ejercicio. Esto trae como consecuencia que la clase se alarga. O hay que alargar el curso completo, con el consiguiente aumento del costo final.

- Aun teniendo práctica para captar un tema, un asistente puede necesitar su tiempo para entenderlo. Necesita practicar y jugar con un ejercicio un tiempo. No siempre es posible disponer de ese tiempo: muchas veces porque hay que seguir con otro tema.

- Si no trabajan con máquina, muchas veces los asistentes no se toman el tiempo para practicar. Hay varias razones: están tomando el curso en el trabajo pero no tienen máquina adecuada para practicar. O están tapados de trabajo y no tienen tiempo. O sus jefes no les asignan tiempo para practicar. O podrían practicar en una máquina personal, al volver a casa, pero ahí también: hay otros temas de que ocuparse. Me ha pasado dejar ejercicio a un curso y que de los veinte integrantes sólo uno o dos practicó algo entre dos clases. Cuando esto se repite, a lo largo de las clases, llega un momento que el contenido que se trata no se asimila porque no se practicó lo anterior. Llegados a ese punto, sin práctica de lo ya tratado es difícil captar todas las facetas del contenido nuevo. También a algunos asistentes se les complica instalar todo lo que necesitan para practicar. Una vez, recuerdo, puse un ejercicio entre clases en un curso de cuarenta personas. Lo escribí mal planteado a propósito. A la siguiente clase, solo uno de los asistentes se dio cuenta del problema: era el único que lo había encarado.

- El lugar de dictado puede estar a varios kilómetros de donde un asistente vive y trabaja.

- Si el curso es en el propio trabajo, un asistente puede sufrir interrupciones, o por tener un tema "urgente" para solucionar, debe abandonar la clase.

- Si el curso es en el trabajo, pero después o antes de hora de oficina, a muchos no les es fácil participar por tener otras actividades o no poder llegar más temprano.

- De vez en cuando me pasa que algunos asistentes no tienen mucha motivación para hacer el curso: los “mandaron” al curso y no tienen un soporte, un apoyo, de parte de sus empleadores, para sacar provecho del mismo (especulo, pero eso puede ser también un “test de proactividad” de su empleador o contratante).

- Otras veces, el asistente está motivado porque necesita trabajar pero hace tiempo que no toma un curso. Las tecnologías nuevas lo sobrepasan y termina necesitando de más tiempo para aprovechar el contenido.

- Si el curso es por cuenta de cada integrante, no lo paga una empresa, entonces probablemente tenga que asistir después de hora un día de semana o un sábado. En esos horarios también tendrá que pelear su tiempo con otras actividades, familiares, o de estudio formal.

- El temario es introductorio para un lenguaje de programación, pero no se enseña a programa. Se pide explícitamente que se conozca de programar y de base de datos. Y algunos asistentes no tienen esos conocimientos en firme.

- Otro caso es cuando el temario es intermedio o avanzado. Puede pasar que de los que asisten, algunos ya saben varios puntos del temario y se aburren. Mientras, otros necesitan repasar o incluso aprender un tema, porque no llegan al nivel que se necesita para el curso. Esto pasa cuando los cursos son para asistentes de distintas empresas o que se inscriben por su cuenta.

- Cuando el temario lo arma una empresa, el que arma el temario pide todos los temas habidos y por haber, pero luego no se asigna tiempo para que los asistentes practiquen en el medio del trabajo de cada día.

- Prácticamente todo el material que doy queda disponible en mi sitio personal. A la quinta o sexta clase del curso, alguien se acerca y me pregunta: ¿dónde puedo bajar los ejemplos? Yo me pregunto entonces: ¿cómo hizo para seguir las anteriores clases, si nunca repasó los ejemplos que YA se dieron? Detecto acá que no han tenido tiempo para practicar entre clases.

Y en mi caso en particular, muchas veces los cursos no se abren por falta de inscriptos: se necesita un número mínimo para costear los activos inmovilizados (proyector, máquinas si es con práctica, lugar, instructor) que no siempre se cubre. También me pasa armar una lista de correo para los asistentes del curso (por ejemplo, en los míos de Java) . Luego de dos años, les cuento que solo cuatro personas, entre decenas que asistieron, se inscribieron para hacer más preguntas.

No quisiera afirmar que siempre es así como describo arriba. Pero me asombra la cantidad de veces que algunos de esos “anti-patrones” aparecen, por lo menos, en muchos de los cursos que me ha tocado dictar. Así que pienso, desde hace algún tiempo, que debo mejorar en algunos temas. O motivar más, o hacer algo para que estos anti-patrones no aparezcan tan frecuentemente. Una sorpresa agradable: los cursos de Scrum son los más participativos de todos: son casos donde prácticamente no prácticamente no aparecen estos “issues”.

Y un tema, disculpen, más personal: otra “constante” que detecto. Ante un curso de cuarenta personas, pregunto cuántos conocen mi blog. Sólo uno levanta la mano. Pasan las semanas, y al final del curso, después de dos meses, pregunto de nuevo. Y ahora, son 1 o 2 las manos levantadas. Así que algo tengo que hacer: o mejorar los contenidos o escribir más claro o de temas que les interesen más. Muchas veces escribo para que lo explicado quede más claro. Si algo no se entiende en una clase presencial, quisiera que se pueda leer y releer por acá. Pero veo que he tenido poca llegada en ese tema, por lo menos en los asistentes a mis cursos presenciales.

Pero también detecto y especulo un patrón: los que programan y no leen blogs (mío o de cualquiera), en general, no se mantienen actualizados y necesitan cursos presenciales. Los que programan y leen blogs son otro grupo: se mantienen actualizados y no necesitan cursos presenciales, apenas algunas charlas introductorias como primeros pasos en un tema. Luego, ellos mismos aprenden de una nueva tecnología, patrón, estilo arquitectónico o herramienta.

Habiendo repasado estos puntos, ¿cómo se podría mejorar? Tengo algunas ideas al respecto, tomadas de otros ámbitos, y de lo que veo que puede funcionar, pero son temas para seguir en la segunda parte de este post. Mientras tanto: ¿tienen alguna sugerencia?

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

¿Es tiempo de volver a la simplicidad?

lopez — Fri, 16 Oct 2009 16:16:00 GMT

En estos días Ted Neward escribió un interesante post “Agile is treating the symptons, not the disease” donde citaba una frase pronunciada por Billy Hollis en el Patterns and Practice Submit de esta semana, en Redmond. Leo ahí:

“A lot of software written back in the 90's was written by 1 or 2 guys working for just a few months to slam something out and see if it was useful”

“The problem is the complexity of the tools we have available to us today preclude that kind of software development.”

Yo veo el problema más asociado con tecnologías que con las herramientas. Puedo tomar como ejemplo los servicios web. Para mí, los servicios web no son una herramienta como lo son una librería, un compilador o una IDE. Los servicios web son tecnología. Muchas de las herramientas que usamos (Eclipse, Visual Studio, …) luchan contra la complejidad de las tecnologías. Uno o dos programadores todavía pueden crear una maravillosa librería de código abierto. Pero traten de escribir con el mismo equipo una aplicación empresarial que involucre base de datos, comunicaciones, seguridad, administración, instrumentación, y más. Hay tantos detalles en las tecnologías que usamos para implementarlo, que la complejidad de cualquier aplicación no trivial puede (y frecuentemente es) abrumadora.

Volvamos a los servicios web. ¿Visitaron la página de la Wikipedia sobre el tema, recientemente? Encontrarán docenas de especificaciones. Podrían pasar semanas o meses, tratando de entender y comprender todas los detalles técnicos que se encuentran en WS-Trust, WS-Addressing, WS-Transaction, WS-PutYourWordHere. Pienso que la adopción de estilos REST es una reacción contra esa locura (estilo a la REST, no veo tan adoptado los principios REST, o lo que se llama RESTFul). De vez en cuando, hay librerías que acuden a nuestra ayuda, y otras veces aún esas librerías fallan. Mi ejemplo preferido de un intento fallido de ocultar la complejidad de los servicios web, es Windows Communication Foundation (WCF). Escribí sobre el tema en Windows Communication Foundation configuration madness.

La complejidad en software no es mala por sí misma. Puede llegar a ser buena. El software influye en casi toda actividad humana. La popularidad de Internet, alimentada por una “killer application” como la World Wide Web, influye en las actividades nuestras de todos los días. Como desarrolladores de software, estamos contribuyendo a ese progreso. No perseguimos estar en nuestra zona de confort sino que buscamos agregar valor a nuestro software. Y si eso implica mayor complejidad, no debemos evitarla.

En la actualidad, los requerimientos de los clientes son más desafiantes: acceso de múltiples usuarios, en cantidad masivas, escalabilidad, procesamiento distribuido para cumplir con la carga, disponibilidad en línea 24 horas, 7 días a la semana. Todos son requisitos que usualmente se incluyen en las aplicaciones empresariales modernas. Y no hay soluciones simples para cubrir todos esos temas.

Dicho todo esto, veamos que la complejidad está con nosotros pero puede ser combatida. Yo paso gran parte de mis horas de trabajo enseñando programación, y el resto del tiempo, lo paso desarrollando sistemas. He sufrido la complejidad del estado actual de cosas tanto en la enseñanza como en el desarrollo de software. La cantidad de detalle a tener en cuenta (seteo de ORMs, configuración por inyección de dependencias, preparación de los tests, librerías de mocks, configuración de WCF o JBoss o EJBs….) es tan grande que nuestras mentes están perdidas en el medio de tal jungla de detalles.

¿Recuerdan la “Era Petzoldiana” (en honor a Charles Petzold, autor de libros de programación para Windows)? Cantidad de líneas de código a escribir para producir un simple programa “Hello world” que corriera en Windows. Entonces, en esos años, apareció Visual Basic. Fue un modo efectivo de esconder la complejidad de la API de Windows, salvando a toda una generación de desarrolladores de pelearse con handles y valores LONG donde las coordinadas del mouse venían en mensajes de Windows. Esa API de Windows, así desnuda, era (y es) un infierno, un verdadero infierno.

¿Recuerdan cuando era necesario leer VTOCs en discos de IBM? ¿Escribir Job Control Language? ¿Escribir macros en ensambladores? Para cada una de esas herramientas, aparecieron otras nuevas que contribuyeron a ocultar la complejidad usando un “viejo truco”: elevar el nivel de abstracción. En vez de pensar en registros y sectores, comenzamos a manejar variables y comandos SQL.

Yo pienso que fue al final de los ochenta, principios de los noventas, cuando el desarrollo de software en el ámbito de las PC alcanzó el tope en la razón poder/complejidad. Ejemplos que se me ocurren: Turbo Pascal, Visual Basic, Access. Con ellos, teníamos gran cantidad de poder de programación acompañado de baja complejidad. Desde entonces, veo que estamos en caída libre. El “viejo truco” de “elevar el nivel de abstracción” no fue adoptado de nuevo: todavía estamos construyendo software usando lenguajes de tercera generación, lo que podríamos considerar los macro ensambladores de los sesenta.

Como decía, una forma de escapar de este estado de cosas es ir al siguiente nivel de abstracción. Ya alguna vez hemos olvidado manejar registros e instrucciones Branch and Link Register, y hemos adoptado lenguajes de programación generales. Ahora, necesitamos escribir software en un nivel más alto. Mi apuesta: Domain Specific Models y Domain Specific Languages. Pero es sólo una apuesta. Usando DSLs, DSMs, generación de código (¿se dan cuenta que cada día que usan un compilador C# o Java, están “generando código” AHORA MISMO?) podremos apalancar la tecnología existente, ocultando la complejidad subyacente.

Con tantos lenguajes, librerías, tecnologías a usar, no hay una simple solución para ocultar todo este lío. Noten que hay varias tipos de complejidad. Una es la complejidad en los requerimientos de los clientes: lógica de negocios, requerimientos functionales y no funcionales. Eso está bien, es parte de nuestro trabajo. Pienso que las metodologías ágiles están atacando ese tipo de complejidad. Pero también existe la complejidad tecnológica. Y ese tipo de complejidad, debería ser más atacada. Debemos parar esta vuelta a la era Petzoldiana (recientemente, encontré el concepto de Complejidad Accidental, en una charla de Rich Hickey talk (hmmm… creo que él la llamaba complejidad incidental). Leo en la página de Wikipedia accidental complexity:

Accidental complexity is complexity that arises in computer programs or their development process (computer programming) which is non-essential to the problem to be solved. While essential complexity is inherent and unavoidable, accidental complexity is caused by the approach chosen to solve the problem

)

Otros posts interesantes, disparados por el inicial de Neward:

El de Jeffrey Palermos Response: “Agile is treating the symptoms, not the disease” by Ted Newardç
Uno de Phil Haack Software Externalities
La respuesta de Ted Neward a Haack Haacked, but not content; agile still treats the disease

Tengo tanto para comentar de estos posts. Pero por ahora, sigo con el tema inicial.

Me gustaría recordar un punto más: la complejidad no es el único desafío en el desarrollo del software. Todo proyecto exitoso tiene dos desafíos: enfrentar la complejidad y manejar el cambio. Son esos los problemas que las metodologías ágiles nos ayudan a enfrentar: combatir la complejidad con “baby steps”, pasos de bebé. Hay que recordar cómo se come un elefante: pedacito a pedacito. Y nos ayudan a no temerle al cambio, al contrario: tenemos que abrazarlo, adoptando disciplinas ágiles que disminuyan el costo de cambiar en el medio del desarrollo.

Otro punto: con la adopción de Internet, nuestra actual cultura de desarrollo de software está floreciendo, poblada de ideas, implementaciones de referencia, librerías y herramientas de código abierto, patrones y estilos de arquitectura, mejores prácticas, frameworks, paradigmas de programación, y lenguajes. Por ejemplo, hay una nueva camada de lenguajes dinámicos, montados sobre Java y .NET. Todo indica que la caja de Pandora ya fue abierta: no veo una forma fácil de cerrarla.

En el post de Ted Newerd que citaba al principio, él escribió:

Let me rephrase Billy's talk this way: Where is this decade's Access?

Tengo algunas ideas al respecto, sobre cómo podría ser el próximo Access. Pero quedará eso planteado para otra clase.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Tales from the Scrum: Un día en el equipo

lopez — Tue, 13 Oct 2009 09:20:03 GMT

Una de las cosas que hay que destacar de Scrum, por si es la primera vez que lo ven, es el trabajo en equipo. Los miembros del equipo realizan una reunión diaria inicial, el Standup, se reparten las tareas, y van trabajando físicamente juntos durante el día, programando, diseñando, haciendo pruebas del software, etc… Hace un tiempo, encontré este video, donde, oh! sorpresa! el ScrumMaster es el bueno de Tobías Mayer (@tobiasgmayer) (visiten su blog Agile Thinking, y su iniciativa WelfareSCM (entramiento Scrum de bajo costo), también el video que grabó sobre el tema en InfoQ).

(Please visit the site to view this media)

Vean cómo se trabaja a veces de a pares, a veces en solitario. El ScrumMaster (el que acerca la cara y hace muecas…:-), va acompañando al equipo, de forma intermitente. El lugar físico es importante: todos se ven, todos están en contacto directo. Vean cómo van organizando las tareas en papeles. A la derecha, parece que tiene el tablero de control.

Para los que no lo vivieron, es así: los miembros van avanzando en tareas, tienen reuniones de diseño, o para discutir dudas y caminos. No hace falta comer en el mismo lugar :-) pero pueden hacerlo.

Pueden leer un post de Tobías que traduje al español en Tales from the Scrum: El corazón de Scrum.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Desarrollando aplicaciones en .NET

lopez — Mon, 12 Oct 2009 17:08:40 GMT

En esta semana, comienzo a dictar el curso presencial que había anunciado en un anterior post:

Preparando un curso de .NET: aplicaciones, patrones y arquitectura

organizado por la gente del Microsoft Users Group de Argentina. Gracias a todos los que dejaron sugerencias sobre el temario, ahí, y en listas de correo que consulté. Es un curso pago, pueden obtener más información en la página de inscripción al curso.

El temario a desarrollar es ambicioso:

Arquitectura de aplicaciones .NET
Capas lógicas, capas físicas
El gran Service Layer
Persistencia
Object Relational Mapping
NHibernate, otros ORMs
Reglas de Negocio
Test-Driven Development
Rhino Mocks, Moq, otros
Inyección de dependencias
Spring Framework y otros
Separando responsabilidades
Conceptos de Autorización, Autenticación, y Seguridad Federada
Patrones en presentación: MVC, MVP, otros
Tecnologías de presentación: WinForms, ASP.NET, ASP.NET MVC, conceptos de WPF, Silverlight
Propuestas de Microsoft de Arquitectura
Modelo de Dominio
Domain-Driven Development
Desarrollo en equipo
Conceptos de Metodologías Agiles, XP, Scrum
Repositorio de Código
Integración Continua

además de algunas alternativas “exóticas” a explorar, como para amenizar estos temas. Presentaré ejemplos propios y otros de código abierto que están publicados en Internet.

La idea es ir transmitiendo algunas de las técnicas e ideas que se están usando, para llevar a cabo un desarrollo en .NET. Bien podría dar un curso similar en Java: ambas plataformas son lo bastante maduras como para que podamos usarla en todos estos temas, y más. Y mucho de lo que se usa hoy en .NET, nació primero en Java y otras tecnologías.

Mi idea es ir volcando por aquí, en este blog, algunos apuntes, resúmenes, notas de lo que dicte en el curso presencial. También compartir por acá enlaces sobre los temas que visitemos (más ejemplos, posts, herramientas, librerías). Es una forma de pasar en limpio, todo lo que entre todos tratemos en el curso, para que no quede solamente para los que asisten. Siempre dejo los ejemplos de los cursos que dicto en mi sitio, en Cursos y Seminarios: Ejemplos, Enlaces y Recursos, pero esta vez quisiera ir más lejos, y poner por escrito gran parte de lo que desarrollemos en el curso.

Son varios temas: intentaré mostrar cómo se derivan de unos pocos principios y necesidades, en principio, de la complejidad y el cambio que acompañan a cualquier sistema de software no trivial y exitoso de estos días.

(Tomé la imagen de este post de http://www.leansoftwareinstitute.com/blog/, creo que refleja la belleza y complejidad de construir software).

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Microsoft MVP (Most Valuable Professional) otro año más, y el futuro del software

lopez — Sat, 10 Oct 2009 14:36:00 GMT

El pasado 1ro. de Octubre, me confirmaron que nuevamente, en este año que sigue, soy Microsoft MVP. Pueden ver detalles del programa en:

http://mvp.support.microsoft.com/

Quiero agradecer a Néstor Portillo (@nportillo) y Fernando García Loera (@ferglo) por su apoyo en todos estos años. También, a Carlos “Billy” Reynoso, quien me propuso como MVP en 2002 (vio la luz!! :-), luego de haberme convocado también en los 90 para participar de charlas y reuniones. Y a la gente del Microsoft User Group, del que participo desde hace casi 15 años, por el constante trabajo para armar una comunidad en la que podemos participar todos.

Me gustaría que otras empresas tuvieran un programa similar a los Microsoft MVPs. No sé si hay programas como éste en Oracle/Sun, IBM. En Argentina, la empresa que más se ha preocupado (con altibajos, hay que reconocer) ha sido Microsoft. Recuerdo los tiempos de Sun lanzando Java por estos lares, en los noventa. Estaba más preocupada por captar periodistas que a programadores. Si alguna vez me invitaron a una charla en los noventa, fue porque escribía para una revista, sino, ni enterados la gente de Sun de que hay programadores de este lado del ecuador.

Recuerdo mis primeros contactos con la tecnología Microsoft, al leer la Dr.Dobb’s Journal, donde se comentaban algunos productos. ¿Recuerdan Lattice C? Microsoft lo compró para ser su primer Microsoft C. ¿Alguien recuerda el Lisp de Microsoft? Creo que se lo habían comprado a una cía de Haway. Conocí más de la historia de esos tiempos en varios libros; en especial, recuerdo “Fire in the Valley”. También ahí aprendí de Apple, MITS y demás pioneros en la microcomputación. En esos tiempos, había multitud de “computadoras personales”, con distintos sistemas operativos y lenguajes. En muchas de ellas, Microsoft tenía software para ofrecer. Pero todos conocemos que el mercado despegó con la llegada de la IBM PC. Recuerdo que para editar con el edlin, booteaba con un diskette, lo retiraba, y ponía el segundo, porque ahí estaba el editor de línea. Como diría Olmedo: “Eramos tan pobres…. " :-). Si bien llegó Apple a mi país, Argentina, en aquellos años había que ser descendiente directo de los que desembarcaron en el Mayflower para poder acceder al programa de desarrollo de aplicaciones de la empresa de la manzanita. Algunos detalles más de esos tiempos, en

Treinta años en desarrollo de software

Creo que, como entonces, vivimos tiempos fascinantes en el tema de desarrollo de software. Me gustaría escribir acá algunos puntos a estudiar, a seguir de cerca, en estos años que se vienen (espero que para mí, sean otros treinta años… :-)

Primero, quiero destacar la existencia de dos plataformas de desarrollo: Java y .NET. Entiendo por plataforma de desarrollo a lenguaje(s), librería de clases extensa, soporte de desarrollo de distinto tipos de aplicaciones (desde consola a web a distribuidas). En el 95, comencé a conocer Java, y desde entonces, me ha parecido una de las mejores cosas que ha pasado en la historia del desarrollo de software. Con todas las críticas que se le pueden hacer (EJB una terrible cosa que aún me dá escalofríos (antes de acostarme, veo abajo de mi cama a ver si hay algún Entity Bean escondido), Sun como karma, empresa que no supo mover a la comunidad de desarrollo, que en muchos casos se tuvo que arreglar sola (Hibernate como ejemplo?)), Java ha sido lo que hizo que las máquinas virtuales, clases y objetos, frameworks, threads, serialización, modelos de dominio, salieran de lo académico o del nicho, y pasaran a la corriente principal de desarrollo. Desde fines de los noventa, no he pasado casi una semana, sin dar algún curso o charla sobre Java, y tecnologías asociadas. Es un “must be know” para cualquier desarrollador de software de este milenio.

Y Microsoft, vió la luz, y se reinventó a sí misma: abandonó VB, VBScript, ASP, C++ con la infame MFC (Microsoft Foundation Classes), ATL, COM (que nunca despegó para multiplataforma, como hubiera querido Don Box, y aún Miguel de Icaza con el proyecto Bonobo), y cambió como empresa, por lo menos en las herramientas de desarrollo. Parecía como si hubiera hecho todo por otra empresa: no más COM como tecnología necesaria; teníamos al fin una máquina virtual (un empleado de Microsoft morirá en la tortura antes de llamar “máquina virtual” al CLR, pero, es lo que es.. :-); plétora de lenguajes nuevos, totalmente montados sobre esa máquina virtual. Realmente, es como si hubiera habido otra empresa que creó todo eso. Un gran movimiento por parte de Microsoft, que ha sabido adaptarse a los tiempos que le tocan: como ejemplo, recuerden el giro a Internet que dió la empresa, a finales del 95.

Así que tenemos dos temas para seguir con atención: Java y .NET.

Otros temas: el desarrollo de aplicaciones, ¿dónde va? Veo que sigue habiendo aplicaciones de escritorio. Pero preveo que la lucha y la innovación vendrán en otras áreas (enlaces al final):

- Aplicaciones Web: dentro de la empresa, los sistemas de gestión serán migrados a todo web. Si bien la interfaz web no es la mejor, la aparición de Ajax, librerías maduras de Javascript, tecnologías en el servidor (ASP.NET, ASP.NET MVC, veremos hacia donde va Java, luego de no haberse adoptado JSF por todo el mundo, Ruby y Python con desarrollo web), hoy no es descabellado ver cada vez más aplicaciones internas, expuestas en el browser.

- Rich Internet Applications: usar JavaFX, Silverlight, Air, o lo que aparezca. Pero crear aplicaciones, que mediante algún plugin liviano en el cliente, permitan tener la experiencia de usuario del tipo de aplicaciones locales que tenemos ahora.

- Software as a Service, tanto aplicaciones web (Google Apps) como RIA, el software de gestión y otros tipos, que hoy consumimos localmente, veo que estará cada vez más ofertado directamente en la web. Habrá que ver quienes serán el target: ¿las pequeñas empresas que no tienen un equipo de IT? ¿las medianas y grandes, que están cansadas de soportar un equipo de IT y desarrollo semi a a medida?

- Desarrollos Web2.0: la interconexión de aplicaciones mediante protocolos livianos (desde REST hasta cualquier otra cosa, olvidando los pesados Web Services, especificación que veo que se encamina a la over-complexity), modelos pubsub montados sobre Twitter o similares, la aparición de Service Bus online.

- Cloud computing: lo veo de dos formas: como una forma de virtualización as a service, y como una forma de aplicación escalable hacia afuera. La primera será más fácil de programar (es como venimos hasta ahora, pero “hosteando” en otro lado). Nos ahorramos el setup de la máquina, licencias, mantenimiento del equipo. Lo de escalable hacia afuera, más cercano a la idea de “cloud”, ejecutando en varias máquinas, habrá que estudiar cuán de difícil o fácil es el cambio de modelo de programación. Ejemplo: sharding de base de datos, ¿será lo suficientemente transparente para como venimos programando?

- Mobile: o debería llamarlo, la aparición del software en múltiples dispositivos. Esto es una rama que tenemos que estar atentos. La industria de desarrollo está por dar un salto, o ya lo está dando: tal vez, el mayor desde la aparición de la computadora personal. La cabeza de playa son los teléfonos móviles. Pero lo que veo es: sistemas operativos para pequeños dispositivos (Android, Windows Mobile) con soporte de desarrollo (Android SDK, .NET Compact Framework), que harán que podamos escribir software para casi cualquier cosa, cualquier “widget” que tengamos (teléfonos personales, otros dispositivos, aparatos inteligentes), comunicados por Internet. La convergencia de: dispositivos inteligentes, Internet, herramientas de desarrollo maduras, es “the next big frontier”.

- Lenguajes dinámicos: podrá haber lenguajes aislados (como los originales Ruby y Python) pero veo que cada vez más se montarán sobre las dos plataformas, .NET y/o Java. Veremos que pasa con esto: lo que veo, es que tienen comunidades fuertes, que impulsan nuevas cosas, nuevas ideas (o reimplementaciones frescas de otras ideas), que en otros ecosistemas más maduros es difícil de que prendan. Recordemos Ruby On Rails como un ejemplo.

- Web Semántica: ahí afuera hay un mundo de información, que por primera vez está disponible, no sólo para seres humanos, sino para nuestras aplicaciones. La aparición de formas de aprovechar inteligentemente esta montaña(cordillera diría) de información, es un camino que veremos donde llega. Las iniciativas de web semántica son lo más promisorio. Pero también puede que “la liebre salte por otro lado”: desarrollos aislados, que encuentren una forma de comunicarse o de aprovechar lo existente.

- Aplicaciones distribuidas: los que leen mi blog (yo, y mi tía Carlota), saben de mi interés en aplicaciones distribuidas. Habrá que seguir de cerca el tema message passing, o el más prometedor y flexible, agentes. Multithreading, multicore, son simplemente una antesala a Multimachine. Ese es el camino a al escalabilidad, y superar el bloque de la Ley de Moore: multicore está bien, pero multimachine is the solution (pregúntele a Google). Sharding de base de datos, escalabilidad, datos y objetos en memoria distribuida en máquinas (más barata y rápida que los discos).

- Memoria: El último párrafo me trae a cuento esto que siempre nombro: el uso intensivo de memoria. La memoria cada vez es más barata, y más accesible. Pensemos en qué tipo de aplicaciones podemos lograr. Me imagino una base de objetos o de datos, totalmente en memoria, en máquinas distribuidas, donde el file system sea solamente otra forma de backup.

- Concurrencia y Paralelismo: un tema a estudiar. Vean lo que va surgiendo con Clojure, Software Transactional Memory, hasta NetLogo. Vería de cerca paralelismo distribuido, como MapReduce, High Performance Computing, y alrededores.

- Lenguajes funcionales: recuerdo APL, pero no con cariño. Pero vean el surgimiento de Erlang, la forma en que se usó para el desarrollo de aplicaciones, el “revival” de Lisp con Clojure y cía, F# por parte de Microsoft, Haskell, algo mixto con Scala en Java. Sumaría a los declarativos, como Prolog. ¿Será el siglo del lambda? Para mí, es hermoso que esos temas vuelvan a estar en el tapete. Todo desarrollador de software debería sumergirse en estos temas, en lo que podría llamar, los lenguajes de los dioses.

- Modelos de aplicaciones: las aplicaciones cada vez son más complejas. Encarar el desarrollo basado prácticamente en lenguajes de tercera generación, sin haber elevado el nivel de abstracción, con tecnologías de base que van cambiando año a año, mes a mes, es un camino lleno de piedras y espinas. Yo apuesto a la aparición de modelos, Domain Specific Models, Domain Specific Languages, herramientas relacionadas (el camino más cercano es la generación de código), para hacer más fácil el domino de la complejidad y el cambio.

- Desarrollo ágil: en los tiempos que corren, el trabajo en equipo es indispensable. La cantidad de tecnologías, detalles, y requerimientos que precisa un software más o menos normal, implican que va desapareciendo el desarrollador de garage, en solitario. Las limitaciones de desarrollo en cascadas, el cambio en los requerimientos, porque hasta el ambiente externo cambia, éxitos cosechados por el programación extrema y disciplinas relacionadas, todo apunta a que tenemos que ir adoptando más y más el modo ágil de construir software.

- Inteligencia Artificial: como decía más arriba, es tiempo de que agentes. Incorporar lógica, razonamiento, modelos del mundo, inferencias, objetivos, ontologías, algoritmos genéticos, redes neuronales, en todo lo que se viene.

(ahora entenderán un poco más, a que van los códigos de código abierto que publico, como una especie de ejercicio personal para entrenarme en varios de los puntos de arriba).

No he dejado enlaces en el texto, pero muchos de estos temas, como verán, me interesan desde hace un tiempo, y estos son enlaces que he coleccionado:

Tendría más para comentar, pero es hora de tomar mi medicación…:-)… Sí, ya sé, es la pastilla roja, no la verde.

Me parece suficiente para este post, ¿no les parece?

Lo que quería trasmitirles, es que aprovechen este tiempo. Hace treinta años, yo no tenía todo esto disponible: comunicación instantánea, acceso a recursos a un costo razonable, contacto con la comunidad, herramientas maduras, ideas bullendo. Y ahora está todo acá, servido para la próxima revolución.

Muchas de estas ideas, las comento en mis cursos, aunque no sé cuán bien pude trasmitirlas, o si se entendió algo del mensaje. Siempre veo que la gente pide cursos de un tema en particular, me gustaría en este post (como en otros anteriores) haber dado una visión más amplia de lo que hay en el mundo del desarrollo de software, hoy, y que sirva de ensayo futurológico, sin mayores pretensiones, de lo que puede venir como importante.

De alguna forma, en estos años, se decidirá el tipo de software que se ejecutará en las próximas dos décadas. Y como en las anteriores, el software seguirá cambiando la historia humana.

Pero el software no se hace solo. Como decía Alan Kay: “la mejor forma de predecir el futuro, es inventándolo”. Sean parte de todo esto.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Alt.NET Hispano: VAN con Martín Salías y lenguajes en .NET

lopez — Thu, 01 Oct 2009 09:32:57 GMT

Este viernes, 2 de Octubre, la comunidad de Alt.NET Hispano preparar una VAN (desconferencia, reunión virtual), a las 5:00pm GMT (2 de la tarde acá en Buenos Aires), sobre lenguajes en .NET, con el bueno de Martín Salías (@MartinSalias). Pueden ver más detalle en:

Por primera vez tendremos VAN entre semana con Martín Salías

Explica ahí Martín:

mi idea es charlar un poco entre todos sobre el florecimiento de los lenguajes en entornos manejados. Me parece que no es coincidencia que en el ambiente Java esté pasando algo similar a lo que tenemos en .NET.

Lenguajes Dinámicos:
JVM: Jython, JRuby, Groovy
.NET: IronPython, IronRuby

Lenguajes funcionales:
JVM: Scala, Clojure
.NET: F#, C# (¡cada vez más!)

Otros:
Ioke (JVM/.NET), Boo (.NET)

…

Me parece interesante repasar juntos los objetivos y desarrollo histórico del CLR, el DLR, y cómo impactó en esta nueva tanda de lenguajes la influencia del ambiente Open Source, que es tan cercano al espíritu Alt.NET.

El bueno de Martín, menciona algunos proyectos míos de lenguajes… snif… me van a hacer llorar de la emoción… snif… :-)

Si no conocen qué es una reunión VAN, pueden consultar VAN meetings. Para ver cómo se desarrolla una VAN de ALT.NET Hispano, y qué software necesitan para asistir, ver Descripcion-de-Reuniones-VAN. Pueden ver el historial de anteriores reuniones VAN (visiten las que dieron, por ejemplo, sobre NHibernate, WPF y demás) (yo ya participé en VAN sobre Scrum y en otra sobre generación de código, que quedará publicada en estos días). Supongo (pero confirmen) que la URL de entrada de la VAN de Martín será http://snipr.com/virtualaltnet. Cualquier cosa, pueden consultar la lista de correo de ALT.NET Hispano. También pueden suscribirse para proponer nuevos temas, y colaborar con la comunidad.

El año pasado con Rodolfo Finochietti (@rodofof) y Martín, dimos un Technight en las oficinas de Microsoft Argentina (Buenos Aires), sobre lenguajes de programación e implementaciones en .NET. (Lean el material de Rodolfo sobre C# 4.0). Me pareció muy interesante esa charla, y me divertí mucho preparándola y compartiéndola con Martín y Rodolfo. Creo que deberíamos invitar a Rodolfo para que siga con una próxima VAN completando el tema que inicia Martín.

Post relacionados:

Javascript, la programación del futuro
Babel de lenguajes en .NET
Papas fritas, cervezas y una babel de esos raros lenguajes nuevos

(Me gustó tanto la pintura de la Torre de Babel, aludiendo a múltiples lenguajes, que usé en otro post, que la vuelvo a usar acá, con mi propio permiso… :-)

Como es hábito, colecciono enlaces sobre estos temas en:

Bueno, como siempre, los enlaces de estos temas, que colecciono, desde:

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Hacia una Historia Clínica Digital de Código Abierto

lopez — Tue, 29 Sep 2009 09:32:34 GMT

Ya desde hace un tiempo, estoy pensando en qué aplicaciones se podrían desarrollar en código abierto. La que estoy encarando personalmente, es en mejorar AjContab, un sistema de “General Ledger” dirían los americanos, sistema contable simple, abandonando mi viejo ejemplo en .NET, escribiéndola primero en PHP, y luego, ir investigando otras formas de implementarla, en Java o en .NET.

Pero también pienso en sistemas más grandes. Uno de los que vuelve y vuelve a mi mente, al leer artículos, repasar libros, y ver lo que hay por ahí, es el de Historia Clínica Digital. Quisiera pasar en limpio acá algunas cosas que estoy investigando y pensando sobre el tema.

Algunos puntos:

Es un sistema no trivial e interesante
Se puede implementar con una interfaz web, e ir pensando en otras interfaces
Podemos aprovechar Java o .NET, como tecnologías maduras
La aparición de tecnologías de apoyo a Rich Internet Application, como Silverlight, Adobe Air, permiten pensar en una interfaz que pueda evolucionar a más requerimientos de presentación, si es que la interfaz web resulta limitada para algunos requerimientos
Las primeras versiones deberían concentrarse en las prácticas directas, del día a día, más que en la legislación de un país. Buscaría un cliente particular, una clínica, para servir como experto del dominio, y primer usuario que brinde retroalimentación
Integraría el papel: muchas de las historias clínicas hoy se llevan en papel, no deberíamos ignorar ese hecho al armar este sistema. Deberíamos poder agregar información simplemente escaneada (con reconocimiento de a texto o no). En un principio, hasta que no se implemente legislaciones en firme, debemos recordar que la historia clínica en papel, o partes de ella, tienen alguna responsabilidad legal. Vería que las primeras implementaciones, sólo se ocupen de facilitar la recuperación, consulta, de la “historia médica real”, la de papel.
Deberíamos buscar el apoyo de empresas, como IBM, Oracle, Sun y/o Microsoft, para tener a este proyecto como “flag ship”, producto bandera para incorporar en el mercado vertical de aplicaciones médicas
El mundo de las aplicaciones médicas está en permanente evolución
Es un sistema lo bastante no trivial para que deba ser el producto del trabajo de varios, más que de una sola empresa de desarrollo
Servicios como firma digital, pueden implementarse en cualquier momento, no necesariamente lo pondría en los primeros requerimientos.
Tanto firma digital, como seguridad de acceso, se puede ir implementando como servicios a enchufar, que pueden variar de implementación concreta a otra
La historia clínica gana en prestaciones, si es compartida (con toda la seguridad) en “la nube”: la persona debería poder permitir el acceso a la historia clínica personal a los distintos profesionales médicos, sin necesidad de ir recolectando información que dejó en tal consultorio, en tal hospital, en tal internación. De ahí, que imagino que el éxito del proyecto, se mediría con un servicio en línea, tipo Software as a Service
Otro camino para “crossing the chasm”, sería brindar el servicio para que la propia persona interesada, el “paciente”, vaya registrando su historia clínica, o lo que quiera ingresar de la misma.
Como dije arriba, los “early adopter” deberían ser clínicas, no gobiernos. Convencer a un gobierno de usar algo, por lo menos, por estos lares, es tarea digna de las de Hércules.
Luego, el próximo nivel a explorar, serían las obras sociales, servicios de medicina prepaga (no sé cuál es la denominación de estas organizaciones en otros países, fuera del mío, Argentina).
Una forma a implementar privacidad, es, en una primera implementación inicial, no dejar ningún dato que identifique al paciente, asegurando privacidad por faltar esa información (ejemplo, tener un código que conozca sólo la persona interesada).
Se debe producir un resultado visible, más que esperar años para que los usuarios puedan ver algo andando. Es un tema de adopción temprana: no preocuparse tanto por temas de legislación, gobierno, leyes, firma digital, sino de que sirva a los usuarios finales. Hoy podemos construir sistemas de forma ágil, de tal forma que, si el sistema fracasa, no habremos invertido demasiado esfuerzo. Si triunfa, podemos ir armándolo de forma flexible, para que sobreviva a cambios en la legislación, imposición de formatos nuevos, etc.
Habrá que ir pensando en HL7 (Health Level 7), ver IHE (Integrating the Healthcare Enterprise) más que para implementarlos, ver qué temas ocupan, y tenerlos en cuenta y estudiar cuánto influyen en los desarrollos de países que no son EE.UU. Y en sistemas de imágenes como DICOM. Este último es un formato de imágenes producido por varios aparatos médicos, con anotaciones agregadas. ¿conocen algún otro estándar de ese tipo?
Tendría que estudiar Open Healthcare Framework (OHF) Project de Eclipse, y el Microsoft Health Common User Interface. Microsoft también tiene Microsoft Health Users Group. Para estudiar: Microsoft for the Health Industry. Por su parte, IBM tiene Healthcare and life science. Y en Oracle Healthcare Applications.
Otro que parece interesante es el Open Source Clinical Image and Object Management.
Encuentro una lista extensa de código abierto para salud: List of Open Source Healthcare Software, en Wikipedia.
Y hay una Open Source Health Care Alliance, aunque parece que el último congreso que tuvieron fue en 2007.
Es interesante la ontología y terminología que plantea OpenGalen.

¿Conocen ejemplos de proyectos de código abierto, que hayan encarado este tema, el de la historia clínica digital? He visto por ahí, al Proyecto Angel (no, a pesar del nombre, no tengo nada que ver con el mismo…:-)… en todo caso, se hubiera llamado AjAngel… :-), creo haber leído que era de código abierto, pero no encontré ninguna información cierta al respecto, y no veo donde bajarlo, ni que licencia tiene.

Pueden ver algunos enlaces sobre el tema historia clínica y sobre historia clínica digital, en:

http://delicious.com/ajlopez/medicalrecord

Sobre temas de medicina a encarar en este proyecto:

http://delicious.com/ajlopez/hl7
http://delicious.com/ajlopez/dicom

Tengo entre manos, terminar AjSharpure (con post explicativos) y seguir con AjContab, publicando algo (con post explicativos). Pero podría armar alguna prueba de concepto, algún prototipo, de lo que esperaría de un sistema como éste. Otra opción, es ir armando un pequeño sistema a adoptar por las clínicas, como “caballo de troya” benigno. El más potable, me parece, sería un sistema de turnos, que puede brindarse también como Software as a Service, o instalarse local en la empresa.

¿Qué les parece? ¿Es factible? ¿O tengo que ir abriendo mi propia historia clínica psiquiátrica? :-) :-)

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

VAN (Reunión Virtual) en ALT.NET Hispano sobre Generación de Código

lopez — Fri, 25 Sep 2009 09:32:16 GMT

Gracias a la comunidad de ALT.NET Hispano, mañana sábado 26 de septiembre, participaré de una VAN (Reunión virtual) sobre generación de código (hora internacional 6PM GMT, son15hs Buenos Aires). La idea es que al principio presente algunas ideas, ejemplos de AjGenesis, panorama de generación de código, comentar otras herramientas y aproximaciones, pros y contras, y luego, se discutan los temas, entre todos.

Quisiera presentar:

Los por qué de la generación del código
Qué pedirle a una herramienta de generación de código
Elevar el nivel de abstracción, partiendo de un modelo
Resolviendo paso a paso, la aplicación más simple
Mostrar que es más que templates/plantillas
Resolver una aplicación con entidades, desde el mismo modelo, en distintas tecnologías y plataformas (Java, .NET, PHP)
Generación de código como servicio en línea

Si no conocen qué es una reunión VAN, pueden consultar VAN meetings

Para ver cómo se desarrolla una VAN de ALT.NET Hispano, y qué software necesitan para asistir, ver Descripcion-de-Reuniones-VAN

Pueden ver el historial de anteriores reuniones VAN (visiten las que dieron, por ejemplo, sobre NHibernate, WPF y demás)(ya había participado de VAN sobre Scrum).

Gracias al bueno de Jorge Gamba (@jorgegamba) que publicó el evento en su blog:

[Evento] Viendo la luz respecto a “Generación de Código”

Copio de ahí:

La comunidad ALT.NET Hispano realizará un evento virtual con el tema Generación de Código, con la exposición principal del reconocido especialista y maestro en desarrollo de software Angel “Java” Lopez. Será el día sábado 26 de septiembre a la hora internacional 18:00 GMT/GTU (Greenwich), con una duración aproximada de 2 horas. Para atender la reunión deben usar el programa Microsoft Office Live Meeting 2007 client, abriendo el enlace http://snipr.com/virtualaltnet.

Adicionalmente, pueden plantear sus comentarios e inquietudes sobre el tema de la reunión en la discusión Invitación a VAN Hispano Sábado 26 de septiembre - "Generación de código" con Angel "Java" Lopez, en nuestra lista de correo.

La comunidad ALT.NET hispano está muy activa, y los invito a participar de ella. Jorge escribe:

les dejo la lista de recursos compartidos de los que disponemos en la comunidad:

Lista de Correo del Grupo de Usuarios

Wiki

Twitter

Facebook

viddler

Mapa de ubicación geográfica

Calendario de eventos

Como comenta Jorge, pueden ir leyendo:

Sobre la generación de código
Diez reglas principales en generación de código
La generación de código y el trabajo de desarrollo de software

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Explorando objetos con Smalltalk

lopez — Thu, 24 Sep 2009 09:33:50 GMT

Estoy siguiendo a @jarober (James A. Robertson) en Twitter. El es el Cincom Smalltalk Product Evangelist. Postea enlaces, recursos y novedades sobre Smalltalk, en particular sobre los productos Cincom. Escribe un blog:

http://www.cincomsmalltalk.com/blog/View.ssp

que corre sobre Smalltalk. Si visitan ese blog, encontrarán varios posts con videas sobre Smalltalk. Hace poco, Robertson publicó:

Smalltalk Daily: Exploring Objects

Este es el video:

(Please visit the site to view this media)

Robertson escribe:

Many times, you want to do something, know that it can be done - but just aren't sure how to construct the code to do it. If you have an object, you can usually solve that problem by drilling into it with the inspector and looking at it. Today we learn how to programmatically change workspace page text by drilling into a workspace.

Es refrescante ver este tipo de interacción con objetos, tan “a la Smalltalk”.

Debo reanudar mi trabajo en mi Smalltalk VM (intérprete) AjTalk, pueden leer

AjTalk, un intérprete tipo Smalltalk

Le tendría que agregar soporte visual. Mi idea, como en otros intérpretes que estoy escribiendo, es interactuar con el framework de base, en este caso, .NET con su CLR. De esta forma, puedo sacar provecho de todo lo que está armado en ese framework. En estos días, todo lenguaje debería tomar ventaja de un framework de clases ya armado: .NET y Java son las opciones obvias a tomar (ver Clojure como un ejemplo “moderno” de esta estrategia) (o AjSharp… :-)

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez