Angel "Java" Lopez : Desarrollo de Software

Curso de Scrum de Tobias Mayer en Buenos Aires

lopez — Mon, 14 Dec 2009 17:49:46 GMT

El bueno de Juan Gabardini anuncia en la lista Foro Agiles, un nuevo curso de Scrum de Tobias Mayer en Argentina. Copio el mensaje original:

Tobias Mayer facilitará un taller de un día en Buenos Aires, Argentina. Está orientado a Scrum Masters y agile coaches.
Para los que no lo conocen, Tobias dió el primer curso de CSM en Argentina, allá por el 2006. Luego de eso ha venido varias veces (no se cuantos, pero dió al menos 5 CSM en Bs As). ….

Se explorarán los principios y valores de Scrum. Este taller no se focaliza en las prácticas (se asume que los participantes tienen familiaridad con ellas) y explora Scrum en un nivel más profundo y humano. A través de una serie de juegos, ejercicios interactivos y conversaciones facilitadas, se adquirirá una comprensión más profunda del nuevo esquema de pensamiento requerido para hacer Scrum. Esto no es sobre metodologías o procesos, es sobre divertirse

Cuándo: 28 de enero 2010

Dónde: Perú 375, 1^er piso (Southworks)

Costo: usd 220 + IVA

Registración: http://tinyurl.com/tobiasBsAsWorkshop

Este evento es organizado por Agiles Argentina y Agilar Argentina

Este evento será dado en inglés. Aunque por el tipo de evento no es imprescindible el hablar y entender perfectamente, ya que el resto de los que asistimos podremos dar una mano. Va el detalle en inglés.

Process/Mechanics

Scrum is quickly being seen as the de facto way of starting out down an Agile pathway. People see it as a quick and easy way in. The problem is that Scrum is very easily misunderstood. There are a multitude of Scrum Facades in place around the world, companies who claim to be doing Scrum because they have people with the titles of “Scrum Master” and “Product Owner”, have daily meetings, maybe even planning meetings, reviews and retrospectives, keep a backlog of work and show some sort of burn down graph each sprint.

Underneath the facade though, the same old command and control beast lurks, the same old fear and CYA behavior. Nothing has essentially changed. So what is missing? I believe the spirit of Scrum is missing, the essence of change.

Scrum is not just a framework and a set of roles, meetings and artifacts. Scrum is a way of being that is utterly different from any previous way of working that we have encountered in the software industry. To do Scrum — to really do Scrum — requires an absolute shift in the way we think and act.

Scrum relies on some core principles:
— Empiricism
— Self-Organization
— Collaboration
— Prioritization
— Rhythm

and some essential values:
— Courage
— Trustfulness
— Transparency

This session will allow Scrum practitioners to reach the next level of Scrum by exploring some of these underlying foundations in a highly experiential way. The session will consist of a series of interactive exercises and facilitated discussion designed to help participants not just understand, but embody these principles and values at a deep level.

I create and/or adapt new games frequently, the majority require no props, and usually require the participants to be on their feet. Most have simple formats and can be easily remembered. None of them have pre-determined outcomes: they are all about self-discovery. For more detailed information on the kinds of games and interactive exercises I’ll use for this session please follow one or more of these links to descriptions of sessions I have run previously.

Agile Thinking — Agile2005 session

Great Game of Power — Scrum Exchange 2006 session

Scale Back: Small is Beautiful — Agile2008 session

Operating on the Creative Edge — Agile2008 session

This session is intended as a taster and it is hoped participants will be encouraged to explore more deeply the human interaction foundations of Scrum once they leave the conference.

Learning outcomes

Tobias Mayer has built a reputation in the Scrum world of offering highly challenging training sessions, pushing people to the edge of their comfort zone and ultimately breaking through to a new way of behaving. This session has that same outcome in mind.

Ya comenté sobre el bueno de Tobias en:

Tales from the Scrum: La esencia de Scrum
Tales from the Scrum: Un día en el equipo
Tales from the Scrum: El corazón de Scrum

Nos leemos!

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

ALT.NET Hispano VAN (reunión virtual): Aplicaciones modulares con Prism

lopez — Thu, 10 Dec 2009 10:49:14 GMT

Este sábado 12 de diciembre, 19 GMT (4 de la tarde aquí en Buenos Aires) de nuevo tenemos VAN (Reunión virtual, des-conferencia) organizada por la comunidad de ALT.NET Hispano.

(Más información sobre cómo asistir a la reunión virtual, software necesario, enlaces:

http://altnet-hispano.pbworks.com/Descripcion-de-Reuniones

)

Esta vez el tema será Prism (Composite Application Guidance para Windows Presentation Foundation y Silverlight). La introducción estará a cargo del bueno de @juliandominguez, que nos comenta en la lista de ALT.NET Hispano:

La idea de este próximo sábado es presentar sobre Prism (o Composite Application Guidance for WPF and Silverlight para los que prefieren el nombre real pero aburrido).

¿Qué es Prism de patterns & practices y qué desafíos resuelve?

¿Qué beneficios les brinda a arquitectos, desarrolladores y a la interacción con diseñadores?

En esta sesión mostraré cómo Prism nos ayuda a trabajar en equipos distribuidos, no distribuidos, grandes o pequeños, con requerimientos cambiantes, aplicando conceptos como TDD y patrones de UI como Model View ViewModel (MVVM). También voy a mostrar cómo nos ayuda a reusar código que funcione en WPF y en Silverlight.

Vamos a estar viendo los beneficios que nos trae Prism a la hora de construir una aplicación compuesta, como así también en qué (lio?) nos metemos cuando queremos usar Prism en una aplicación que no lo amerita.

Espero que les resulte muy interesante a quienes no conocen Prism y tienen pensado empezar un proyecto en WPF o Silverlight.

Sé que normalmente las VAN suelen ser a las 18:00 GMT, pero debido a mi horario (actualmente estoy en Redmond), preferiría que sea las 19:00 GMT. Esto sería el sábado 12/12.

Así que la reunión será este sábado a las 19GMT (no a las 18GMT como otras veces).

Mi colección de enlaces sobre Prism:

http://delicious.com/ajlopez/prism

Otros interesantes:

http://delicious.com/ajlopez/mef
http://delicious.com/ajlopez/mvvm
http://delicious.com/ajlopez/silverlight
http://delicious.com/ajlopez/wpf

(especialmente si agregan examples o tutorial, como http://delicious.com/ajlopez/mef+example)

Si es la primera vez que topan con el término VAN, les recuerdo:

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 participé en VAN sobre Scrum y en otra sobre generación de código). También pueden suscribirse para proponer nuevos temas, y colaborar con la comunidad. Si no pueden asistir a ésta VAN, seguramente quedará publicada más adelante, con video incluido.

Nos leemos!

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

Tales from the Scrum: Los Rolling Stones y cómo va su proyecto

lopez — Mon, 07 Dec 2009 09:22:09 GMT

Bueno, en realidad, no los Rolling Stones. Solamente Keith Richards, y no el de los Rolling, sino Keith Richards presidente de Keith Richards Consulting. Encuentro en un post de Gojko Adzic un post que comenta una charla de KRC:

Eight interesting techniques to test how a project is going

Es un muy interesante post, déjenme escribir esas técnicas, para saber si el proyecto y el equipo están en buena forma, sea que estén siguiendo Scrum o no. Esta es mi propia traducción de ese texto:

- 1. ¿Puede cualquier miembro del equipo escribir el objetivo del proyecto en una nota post-it con marcador grueso? Si no pueden, el final del juego no está claramente definido ni entendido por todos

- 2. Acérquese a un colega en su trabajo, y pídale ayuda para algo cualquiera. Vea cómo reacciona. Si encuentra una respuesta fría, la persona no está muy contento con su trabajo. Richards aconseja armar equipos con “aquellos que respondan ‘puedo’”. Esa gente mejorará la comunicación y el espíritu de equipo en su proyecto.

- 3. Cuando una fase del proyecto está oficialmente “hecha” (done), pregúntese a sí mismo: “¿Es seguro seguir adelante?”. Si esta pregunta le provoca una mala sensación en las tripas, es que no están listos todavía para avanzar a la siguiente etapa.

- 4. ¿Cuántos de sus proyectos terminan con una seria revisión del proyecto? Esto es, según Richards, crucial para la mejora de su organización. Permite prevenir errores repetidos y compartir conocimiento entre los equipos (yo agrego que, si trabaja en una organización con varios proyectos y equipos, tendría que haber comunicación entre equipos DURANTE los proyectos, comentando bloqueos, avances, hallazgos, problemas y soluciones; unas buenas reuniones periódicas con presentaciones timeboxed pueden ser un camino a seguir).

- 5. ¿Cómo reacciona la gente de su equipo cuando el cliente dice “cambié de idea”? Si reaccionan negativamente, el sistema que están construyendo no es tan flexible como debiera.

- 6. Pregúntele a alguien que le comente el estado actual de una tarea, y luego cállese 10 segundos; no hagan nada para provocar una respuesta. Si la persona se muestra insegura o nerviosa sobre algo, seguramente comenzará a comentarlo. Si se mantiene en silencio, las cosas van bien (este punto lo discutiría: debería haber comunicación y visibilidad sin necesidad de llegar a este tipo de “trick”).

- 7. ¿Conoce cuánto tiempo se empleó en la última iteración en pruebas? Si no puede estimarlo, no está tomando buenas métricas del proyecto. Tomar métricas de este tipo, dice Richards, es crucial para hacer estimaciones realistas (nota mía: ojalá tuviera un peso por cada vez que alguien en un equipo estimó una tarea SIN tener en cuenta pruebas, verificación, etc.; pongan atención a esto).

- 8. Tome un documento de su proyecto, usado durante una presentación. Si atrás hay diagramas dibujados a mano, señal que el documento no está claro, y necesitó de esa ayuda para ser explicado.

Me quedo principalmente con los puntos 1, 2, 3, 5 en primer lugar. Luego 7, 4.

Nos leemos!

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

ALT.NET Hispano VAN: Get Things Done con Jeroen Sangers

lopez — Fri, 04 Dec 2009 10:13:20 GMT

Este sábado 5 de Diciembre, 18 GMT/UTC (3 de la tarde por aquí en Buenos Aires), habrá otra des-conferencia virtual de la comunidad ALT.NET Hispano. El tema será productividad, más específicamente Get Things Done (GTD) (ver también Consigue hacer el trabajo). La presentación inicial estará a cargo de Jeroen Sangers:

http://jeroensangers.com/

@jeroensangers

Este es el temario de Jeroen:

Mi presentación va más que nada sobre Getting Things Done y consiste
de tres partes:
1. Control: un flujo de trabajo para controlar tus acciones
2. Perspectiva: dar dirección a todo lo que haces
3. Consejos prácticas para implementar un sistema de productividad

GTD se populariza con un libro de David Allen. Pueden leer la descripción de GTD en el sitio de Allen:

What is GTD?

Ahí leo:

Sophisticated without being confining, the subtle effectiveness of GTD lies in its radically common sense notion that with a complete and current inventory of all your commitments, organized and reviewed in a systematic way, you can focus clearly, view your world from optimal angles and make trusted choices about what to do (and not do) at any moment. GTD embodies an easy, step-by-step and highly efficient method for achieving this relaxed, productive state. It includes:

Capturing anything and everything that has your attention

Defining actionable things discretely into outcomes and concrete next steps

Organizing reminders and information in the most streamlined way, in appropriate categories, based on how and when you need to access them

Keeping current and "on your game" with appropriately frequent reviews of the six horizons of your commitments (purpose, vision, goals, areas of focus, projects, and actions)

Pueden encontrar una buena descripción (con diagrama incluido, como el que aparece en el libro original) de GTD y una relación con los “cuadrantes de Covey” (me gusta recordar al creador de ese concepto, que es la matriz de Eisenhower).

Mis enlaces sobre GTD, y productividad:

http://delicious.com/ajlopez/gtd
http://delicious.com/ajlopez/productivity

Bueno, ya envíe varios posts sobre las VAN de ALT.NET Hispano, pero les recuerdo:

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 participé en VAN sobre Scrum y en otra sobre generación de código). También pueden suscribirse para proponer nuevos temas, y colaborar con la comunidad. Si no pueden asistir a ésta VAN, seguramente quedará publicada más adelante, con video incluido.

Nos leemos!

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

Recursos de Scrum, del curso de Buenos Aires

lopez — Thu, 03 Dec 2009 11:50:40 GMT

Gracias a la gente del Microsoft User Group de Argentina, ayer miércoles 2 de diciembre estuve dando una jornada de Scrum teoría y práctica, de todo un día. Con unos treinta asistentes, estuvimos viendo temas como el manifiesto ágil, y las ideas que sustentan Scrum en particular. Así como también los roles, artefactos, reuniones, que se manejan en este marco de trabajo. Discutimos tópicos como contratos ágiles, relación con el cliente, la importancia del product owner, la auto-organización del equipo, el “ownership” que tienen que ganar, la idea de trabajar a un ritmo razonable, el “entrar en flujo”, Product backlog vs Sprint Backlog, y el clásico Chanchos y Gallinas.

Para mí, fue una grata experiencia: es uno de los cursos donde veo que más puedo aportar, y donde podemos practicar algo que considero muy importante conocer como es Scrum. Veo que la necesidad de tener equipos ágiles es creciente, no sólo en el desarrollo de software, sino en actividades en general. La labor en equipo permite llegar a objetivos que son más difícil de lograr individualmente o en simple grupo (vean que distingo entre equipo y grupo). Hay que estudiar más en detalle cuáles son los factores que hacen que Scrum funcione (me basé mucho en la idea de No somos vulcanos): hay un bias hacia mostrar los casos de éxito en la comunidad ágil, y no comentar los fracasos. Hay que pasar de la evidencia anecdótica a un fundamento más firme, no porque el marco de trabajo en sí lo necesite, sino para poder aplicarlo mejor, entender mejor en qué circunstancias funciona, y en cuáles se complica.

La parte teórica ocupó la mañana, pero ya después los asistentes se separaron en cuatro grupos, y comenzaron a trabajar en desarrollar un entregable, en dos sprints de 3 días de 10 minutos cada día. Fue una experiencia interesante: fuimos viendo cómo mejorar las reuniones, la precisión del backlog, los acuerdos con el product owner para los entregables de Sprint Review, el reparto de trabajo, la mejor partición de las tareas en el Product Backlog, y más.

Prometí publicar un post con los recursos que mencioné en el curso. Acá van los enlaces y bibliografía, que son similares a los que ya publiqué hace unos días para otros cursos dictados, pero para más comodidad, los concentro de nuevo en este post:

Reunión virtual de Scrum, con video (gran parte de la teoría vista en el curso está en este video) (ahí están los enlaces que presento acá).

Presentación usada en el curso ScrumSpanish.pptx

Pueden usar esta presentación compartida (en varios idiomas):

A Reusable Scrum Presentation. Introduce Scrum to your team, ScrumMaster and Product Owner.

Para leer en inglés y en español Scrum Primer

http://agilethinking.net/ El sitio de Tobias Meyer, que me inició en el ScrumMastering en el 2006.

http://www.implementingscrum.com/ Sitio donde encontraran la clásica historia: The classic story of the pig and chicken

El Manifiesto Agil mencionado en la charla

Artículo corto en inglés (pdf) What is Scrum?

Reviews of Agile Product Backlog and User Story Management Tools: http://www.userstories.com/

Presentación en español sobre Contratos Ágiles

Slides: http://www.slideshare.net/proyectalis/090603-contratos-giles
Video Parte 1: http://www.viddler.com/explore/jmbeas/videos/3/
Video Parte 2: http://www.viddler.com/explore/jmbeas/videos/4/

Foro Agiles (Grupo Yahoo en español)

Blog de Juan Gabardini Software Agil

Enlaces y recursos adicionales en Scrum Práctico

Scrum Cheat Sheet

Scrum: Ficha Sinóptica

Un libro que para preparar las primeras versiones del curso

Agile Project Management with Scrum

En ese libro, están enumerados estos recursos:

Agile Software Development with Scrum, Ken Schwaber and Mike Beedle (Prentice Hall, 2001)

Teoría y práctica de Scrum.

www.controlchaos.com/

El sitio de Ken Schwaber sobre Scrum.

http://www.jeffsutherland.com/

Jeff Sutherland tiene contenido relacionado con desarrollo de software, programación, tecnología, objetos, componentes y Scrum.

www.mountaingoatsoftware.com/scrum/

El sitio de Mike Cohn sobre Scrum.

www.scrumalliance.org

El hogar de los ScrumMaster certificados.

www.agilealliance.org

El sitio de la AgileAlliance, con recursos sobre Agile y Scrum.

http://groups.yahoo.com/group/scrumdevelopment/

El grupo de discusión de Scrum, con años de existencia.

www.xprogramming.com

El sitio de Ron Jeffries acerca de Extreme Programming (XP). XP provee varias de las prácticas que Scrum implementa para asegurar el incremento de funcionalidad potencialmente entregable.

Otras lecturas recomendadas

Agile and Iterative Development: A Manager’s Guide by Craig Larman
Agile Estimating and Planning by Mike Cohn
Agile Retrospectives by Esther Derby and Diana Larsen
Agile Software Development Ecosystems by Jim Highsmith
Scrum and The Enterprise by Ken Schwaber
User Stories Applied for Agile Software Development by Mike Cohn
Artículos semanales en www.scrumalliance.org

Mis posts sobre Scrum (estoy ahí escribiendo una serie “Tales from the Scrum” donde trato más en detalle algunos puntos que tratamos en el curso).

Los enlaces que me interesaron los colecciono en:

http://delicious.com/ajlopez/scrum
http://delicious.com/ajlopez/agile

Nos leemos!

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

Generando un modelo desde la base de datos usando AjGenesis

lopez — Wed, 02 Dec 2009 11:46:06 GMT

AjGenesis, mi proyecto open source de generación de código, usa tareas, templates (plantillas) y un modelo de libre definición, para generar artefactos de texto, en general código fuente, pero también archivos cualesquiera, como configuraciones, definición de proyectos, etc. Muchos de los ejemplos que están en el proyecto y otros que publiqué aparte, usan modelos serializados como archivos XML o de texto. Pero el modelo inicial puede ser cualquier entrada: no sólo esos archivos, sino cualquier fuente de información que nos dé alguna base de modelo. Hasta podemos armar archivos de modelo (recuerden, el modelo lo deciden uds, dónde va, qué tiene, es todo libre) desde otro modelo. Hace unos dos años, escribí sobre generar el modelo desde la base de datos. En mi opinión, la base de datos no es el modelo más expresivo, pero es uno muy ubicuo: puede servir como punto de partida, y desde la base de datos, generar un modelo que podemos refinar posteriormente.

(sobre el tema de modelos pueden leer Modelos y metamodelos en AjGenesis: los metamodelos no son necesarios ni obligatorios, pero es un tema que estoy agregando en el proyecto, como opcional).

(un tipo de modelo a explorar Otro modelo para AjGenesis)

Hoy quiero entonces volver sobre el tema de generar un modelo desde otro modelo, esta vez usando el esquema de la base de datos que tengamos entre manos. Es sólo un ejemplo “prueba de concepto”. Pero en el proyecto ágil en que estoy participando, el equipo tomó la base que ya tenían y generó un modelo usando técnicas como las de este ejemplo, usando AjGenesis, y ahora, ya abandonaron la base inicial, y usan directamente el modelo generado alguna vez y refinado desde entonces.

Pueden bajar el ejemplo actual de mi Skydrive DatabaseExample01.zip. (el código está en el repositorio de código en Codeplex, bajo el directorio examples\DatabaseExamples). El .zip de Skydrive tiene todo lo necesario, incluso la versión en desarrollo de AjGenesis ya compilada.

Despues de bajarlo y expandirlo, tenemos estas carpetas:

Hay un solo proyecto de ejemplo. EL contenido de Projects\Northwind\Metadata.xml:

<Metadata>
  <Project>
    <Name>Northwind</Name>
  </Project>
  <Database>
    <Name>Northwind</Name>
    <ConnectionString>server=.\SQLEXPRESS;database=Northwind;Integrated Security=true</ConnectionString>
  </Database>
</Metadata>

Describe el string de conexión a usar para llegar a la base de ejemplo. Estoy usando la Northwind, en SQL Server (pueden usar el full o el express). Si no tienen esa base de datos, los scripts de creación están en el directorio Sql.

Para generar el proyecto, el modelos con sus entidades, ejecutar:

MakeModelFromDatabase.cmd

AjGenesis (compilado en el directorio Bin) comienza su trabajo:

El comando que ejecutamos contiene:

Bin\AjGenesis.Console Projects\Northwind\Metadata.xml Tasks\DatabaseProcess.ajg

Este comando carga el contenido de Metadata.xml como modelo en memoria, y ejecuta la tarea DatabaseProcess.ajg escrita en el lenguaje dinámico que uso AjBasic. Esta tarea usa las vista de Information Schema para obtener información acerca de la estructura de la base de datos (usando estas vistas, que están definidas en el estándar SQL, y presentes en varias bases de datos, nos abre la puerta para conseguir trabajar con otras marcas que no sean MS SQL Server; debería probar, por ejemplo, con Oracle).

La tarea crea el archivo Projects\Northwind\Project.xml:

<?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?>
<Project>
  <Name>Northwind</Name>
  <Model>
    <Entities>    
      <Entity Source="Entities/Customer.xml"/>    
      <Entity Source="Entities/Shipper.xml"/>    
      <Entity Source="Entities/Supplier.xml"/>    
      <Entity Source="Entities/Order.xml"/>    
      <Entity Source="Entities/Product.xml"/>    
      <Entity Source="Entities/OrderDetail.xml"/>    
      <Entity Source="Entities/CustomerCustomerDemo.xml"/>    
      <Entity Source="Entities/CustomerDemographic.xml"/>    
      <Entity Source="Entities/Region.xml"/>    
      <Entity Source="Entities/Territory.xml"/>    
      <Entity Source="Entities/EmployeeTerritory.xml"/>    
      <Entity Source="Entities/Employee.xml"/>    
      <Entity Source="Entities/Category.xml"/>
    </Entities>
  </Model>
</Project>

El proyecto y las entidades son parecidas a las que usé en Generando aplicaciones con AjGenesis (pero no es igual, estoy experimentando con mejoras). Parte del contenido del archivo generado Projects\Northwind\Entities\Customer.xml nos da una idea de lo que se captura de una “Entity”:

<?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?>
<Entity>
  <Name>Customer</Name>
  <Description>Customer</Description>
  <SetName>Customers</Name>
  <Descriptor>Customer</Descriptor>
  <SetDescriptor>Customers</SetDescriptor>
  <SqlCatalog>Northwind</SqlCatalog>
  <SqlSchema>dbo</SqlSchema>
  <SqlName>Customers</SqlName>
  <Properties>
    <Property>
      <Name>CustomerID</Name>
      <Description>CustomerID</Description>
      <SqlName>CustomerID</SqlName>
      <SqlLength>5</SqlLength>
      <IsKey>True</IsKey>
      <SqlType>nchar</SqlType>
      <SystemType>String</SystemType>
      <IsNullable>False</IsNullable>
    </Property>
....
  </Properties>
</Entity>

La lógica principal de todo este proceso de generación, reside en la tarea Tasks\DatabaseProcess.ajg, de nuevo escrita en AjBasic (I love this language! :-) un fragmento:

cmd = new System.Data.SqlClient.SqlCommand()
cmd.Connection = conn
cmd.CommandText = "select * from Information_Schema.Tables where Table_Type = 'BASE TABLE'"
conn.Open()
PrintLine "Reader"
dr = cmd.ExecuteReader()
Tables = CreateList()
while dr.Read()
  PrintLine "Table " & dr.Item("Table_Name") & ": " & dr.Item("Table_Type")
  Table = CreateObject()
  Table.SqlCatalog = dr.Item("Table_Catalog")
  Table.SqlSchema = dr.Item("Table_Schema")
  Table.SqlName = dr.Item("Table_Name")
  Table.Name = Table.SqlName.Replace(" ","")
  
  if IsPlural(Table.Name) then
    Table.SetName = Table.Name
    Table.Name = ToSingular(Table.Name)
  else
    Table.SetName = ToPlural(Table.Name)
  end if
  
  Table.Descriptor = Table.Name
  Table.SetDescriptor = Table.SetName
  
  Table.Description = Table.Name
  
  Tables.Add(Table)
end while
dr.Close()

Posibles mejoras

Como escribí más arriba, este ejemplo es una “prueba de concepto”; una versión anterior la usamos en un proyecto real. Pero hay varios puntos a mejorar:

- Usar el modelo generado para generar una aplicación que funcione, con scaffolding o no.

- Soportar más metadata que obtengamos via Information Schema

- Probar con otras marcas de bases de datos, y con bases de datos reales

- Tratamiento de relaciones: detectar borrados en cascadas, soportar claves primarias compuestas, otras acciones.

Otros posts relacionados (aparte de los ya mencionados):

Generando Código: Hello World con AjGenesis

AjGenesis: Modelo generado desde los assemblies

Modelo textual para generación de código con AjGenesis

Si es la primera vez que se topan con generación de código con AjGenesis, tengo varios posts escritos. Recomiendo un video, producido gracias a la comunidad ALT.NET Hispano: Resultado de la VAN ALT.NET Hispano sobre Generación de Código

Nos leemos!

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

ALT.NET Hispano VAN: Mocking, Rhino Mocks, Moq con Hadi Hariri

lopez — Fri, 27 Nov 2009 11:29:34 GMT

Este sábado 28 de noviembre, la comunidad ALT.NET Hispano organiza una nueva VAN (Reunión virtual). Esta vez el horario (tomen nota) será 19:00 GMT/UTC (4 de la tarde por aquí en Buenos Aires, Argentina). El tema será el uso de Mocks, en nuestras pruebas automatizadas. La presentación del tema estará a cargo del bueno de Hadi Hariri (que pueden seguir en Twitter en @hhariri). Hadi vive en España, se presenta en su sitio:

http://hadihariri.com

de esta manera:

I'm a software developer and work as Tech Lead for iMeta Technologies. I also give talks and presentations. I love to travel and luckily get to do so when speaking at conferences. My main passions are Software Architecture, Web and TCP/IP development. I live in Málaga, with my wife Katya and my two wonderful sons, Maxim and Sasha. I run the local .NET User group for Málaga and the province. If you live in Málaga or are visiting, drop me a line.

Pueden leer sobre sus conferencias e intereses en:
http://hadihariri.com/blogengine/page/Conferences.aspx
http://hadihariri.com/blogengine/archive.aspx

El enlace a usar es http://snipr.com/virtualaltnet. La información sobre las VAN que vienen, están en la página del Calendario de ALT.NET Hispano. Ahí leo más detalles sobre esta reunión de mañana sábado:

La comunidad ALT.NET Hispano (http://altnethispano.org) realizará un evento virtual con el tema "Mocking" (e "Inyección de Dependencias"), a cargo de Hadi Hariri. Fecha: Sábado 28 de Noviembre a las 19:00 hrs. Hora Internacional (GMT/UTC), con una duración aproximada de 2 horas.

Lugar: Para atender la reunión deben usar el enlace: http://snipr.com/virtualaltnet el cual les demandará el uso del programa Microsoft Office Live Meeting 2007 Client. En esta ocasión la desconferencia estará a cargo de Hadi Hariri, Visual C# MVP, quien es consultor y desarrollador ante todo, así como apasionado de la arquitectura de software y el desarrollo de aplicaciones web. Es ponente habitual en conferencias sobre .NET y Win32, y ha escrito numerosas publicaciones.

Descripción: En esta charla primero repasaremos la inyección de dependencias e Inversión de Control y profundizaremos en los frameworks de Mocks. Veremos cómo funcionan, éstos últimos, así como también cómo sacarle el máximo de partida a ellos para hacer tests sostenibles. Examinaremos las diferencias entre Mocks y Stubs así como diferencias entre pruebas de estado e interacción.

Algunas páginas a revisar:

Inversion of Control Containers and the Dependency Injection pattern

Mocks can be your friend, or your worst nightmare

Pueden plantear sus comentarios e inquietudes sobre el tema de la reunión en: http://groups.google.com/group/altnet-hispano/t/57766b68494fe859 Para mayor información sobre cómo atender la reunión consulten: http://tinyurl.com/van-hispano Pueden vincular el Google Calendar al suyo (http://screenr.com/nr7), o bien descargar el iCal de este evento en particular: http://altnet-hispano.pbworks.com/f/VAN20091128.ics

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 participé en VAN sobre Scrum y en otra sobre generación de código). También pueden suscribirse para proponer nuevos temas, y colaborar con la comunidad. Si no pueden asistir a ésta VAN, seguramente quedará publicada más adelante, con video incluido.

Con respecto a Mocks, y librerías de mocking, he dejado enlaces en:

http://delicious.com/ajlopez/mocks
http://delicious.com/ajlopez/rhino
http://delicious.com/ajlopez/moq

Nos leemos!

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

Lo bello de Twitter: Ejemplo 1

lopez — Sun, 22 Nov 2009 09:31:11 GMT

Soy un gran usuario de Twitter. Generalmente, uso TweetDeck como cliente, aunque a veces voy por la interfaz web. Twitter es la implementación de un idea simple (mensajes cortos, podemos seguir a quien querramos que tenga perfil público, nos pueden seguir y dejar de seguir en cualquier momento (noten los cambios de Facebook a tener perfiles públicos, veo que motivados por la facilidad que se da en Twitter)) Todo eso ha cambiado la forma en que interactuamos. En especial, en el ambiente del desarrollo del software, Twitter es un gran complemente (podría ser un reemplazo) a los lectores de feeds. Veamos un ejemplo de lo efectivo que puede ser.

Todo comenzó ayer sábado, con un mensaje de @jfroma, desarrollador de software argentino, como yo, que escribía:

Yo no había leído todos sus mensajes del viernes, así, que curioso sobre ese comentario, fuí y los leí. El mensaje original aludía al patró Model View View Model. Sé que José (@jfroma) ha estado trabajando en ejemplos de data binding en WPF usando modelos recuperados con NHibernate, así que seguí el link que apuntaba al usuario @michaellperry, para leer sus mensajes. Era mi primer contacto con Michael:

Encontré, entre sus mensajes del viernes, esta presentació:

Session Detail: Data binding without INotifyPropertyChanged

preguntando para confirmar a @jfroma:

Ahora, tenía más contexto (una frase que repito muchas veces: con contexto, uno se puede manejar más entre la información que recibe). Con todo esto, descubro los intereses de Michael en su blog (noten cómo Michael usa su estado Twitter a la izquierda):

http://adventuresinsoftware.com/blog

Descubrí la librería de código abierto de la presentación de Michael:

http://updatecontrols.net

Como siempre que encuentro algo interesante, ya sea para mí, o que pienso que puede ser interesante para alguien, comencé a tweetear sobre el tema. Al rato, veo que @jyinglee desde China, también tomó nota, haciendo RT de mi mensaje:

Todo comenzó con un simple mensaje. Este es el poder de Twitter, es“serendipity with help” (descubrimiento accidental con ayuda), con la ayuda de gente interesante que nos sigue y a la que seguimos.

Nos leemos!

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

Alt.Net Hispano VAN, ASP.NET MVC 2 con estilo, de Oxite a CodeCamp

lopez — Thu, 19 Nov 2009 12:08:52 GMT

Este sábado 21 de Noviembre, tendremos VAN (reunión virtual) organizada por la comunidad ALT.NET Hispano. El tema será ASP.NET MVC, en particular, la versión 2. Como siempre, la reunión no será sólo una exposición, sino también discusión, preguntas, ejemplos, recursos, opiniones. Hasta donde sé, el horario es el de siempre 5:00pm GMT (2 de la tarde acá en Buenos Aires). Y en enlace a usar es http://snipr.com/virtualaltnet (más detalle sobre software y qué es una VAN al final de este post).

La presentación inicial estará a cargo de Cristian Prieto, Microsoft ASP.NET MVP, MCPD ASP.NET Web Development Applications 3.5, MCTS Workflow Foundation 3.5:

http://www.cprieto.com/ (me gusta el título “IDisposable Thoughts” :-)

Hi, My name is Cristian Prieto, I'm a Senior Software Developer living in Guatemala, Central America. I mainly "speak" in .Net languages (like C#, F# and _even_ VB.NET) but I really love programming in Python/Ruby/Erlang. When I'm not programming (or speaking at a .net user group) I enjoy reading and spend my life with my beautiful wife (Emy) and my three cats: Cocco, Motto and Chester

Pueden seguirlo en Twitter como @cprieto:

y en LinkedIn como http://www.linkedin.com/in/cprieto. Ahí leemos su experiencia:

- Experienced Web Developer with more than 9 years in technologies like ASP.NET, PHP, Python, JavaScript and distributed programming.
- Agile software developer proficient with patterns and best practices like Test Driven Development, Behavior Driven Development and Continuous Integration.
- Lover of agile process based development like Lean Development, Kanban and Scrum.
- Technical Community Leader, mentor of new development trends and best practices. Awarded Microsoft ASP.NET MVP 2009
- Accustomed to work with many languages and tools.
- Self-thought and early adopter

Cristian Prieto’s Specialties:

ASP.NET, SQL Server, Web Development in general
Python, Best practices, Multi tier application development, Agile development (lean, kanban, scrum)

Escribe el bueno de Cristian en la lista de ALT.NET Hispano, cuál va a ser el tema de la charla:

Como ustedes recordaran, este sábado 21 de noviembre tendremos la VAN acerca de ASP.NET MVC 2, quería comentar un poco de que esperar para esta VAN (bueno, quizás también por parte del nerviosismo de ser mi primera VAN :P)
ASP.NET MVC fue "cocinado" durante 1 año y mientras tanto nos mantubieron pegados a la silla con 5 CTP's y un par de betas... después de varios meses hemos visto aplicaciones en producción con la plataforma, 5 libros acerca del tema, muchos y muchos webcasts (hay 2 en alt.net hispano :D) y conferencias de "cómo explotarla", multiples proyectos de ejemplo.... y, obviamente, muchas preguntas luego de hacer el "hola mundo".
¿Qué pasa cuando necesitamos algo más que el típico proyecto de NerdDinner? ¿Qué pasa cuando mi aplicación realmente no es un típico ejemplo? ¿Dónde pongo la lógica? ¿Cómo divido y saco provecho de la framework? ¿Qué otras cosas podemos tener bajo la manga para hacernos la vida más sencilla?
Para aclarar estas dudas, examinaremos desde el punto de vista histórico y práctico con qué solemos comenzar y hasta dónde lo podemos llevar, mencionando cosas como MvcContrib y MvcTurbine y dónde encajan cosas como SharpArchitecture en todo esto...
¿Porqué menciono todo esto si la charla es de ASP.NET MVC 2?, simple, porque gran parte de los "problemas" que solemos encontrarnos con ASP.NET MVC vienen o prometen venir solucionados en la "cajita" de la versión 2...
Espero verlos en la VAN, y espero que les guste lo que he preparado :)

Todo indica que va a ser una VAN muy interesante: el título del mensaje (y de este post) alude a un proyecto “fracaso” Oxite, con código disponibl, que fue critica por la comunidad por los “bad smell” que presentaba en la implementación, y a CodeCamp, un nuevo proyecto de código abierto, que sirve de muestra de mejores prácticas con ASP.NET MVC (Model View Controller). Cristian menciona también a proyectos como SharpArchitecture, MvcContrib y MvcTurbine.

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 participé en VAN sobre Scrum y en otra sobre generación de código). Supongo (pero confirmen) que la URL de entrada de esta VAN 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. Si no pueden asistir a ésta VAN, seguramente quedará publicada más adelante, con video incluido.

Nos leemos!

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

Curso de Scrum práctico en Buenos Aires

lopez — Tue, 17 Nov 2009 13:39:00 GMT

En general no anuncio los cursos que estoy por dar (la difusión queda a cargo de cada institución), pero este es un curso que quiero destacar, porque trata de un tema que pienso que todo grupo de desarrolladores por lo menos tendría que conocer y practicar en algún momento. Es un curso que hace unos meses que no estoy dando por Buenos Aires, y siempre he tenido buenas experiencias dándolo.

Gracias a la gente del Microsoft User Group de Argentina, daré un curso de Scrum con una explicación inicial, y luego todo práctica, el miércoles 2 de diciembre de 2009. Pueden ver más datos, costos, y forma de inscribirse en:

Jornada de Scrum, teoría y práctica

El contenido (lo copio de ahí):

- El Equipo de trabajo. Los Roles: ScrumMaster. Product Owner. Daily Scrum. Chickens y Pigs. ScrumMaster vs Project Manager.
- Objetivos: Control empírico del proceso de desarrollo. Dar visibilidad de lo que se está haciendo. Generar una relación de confianza y comunicación constante entre el cliente y el equipo.
- Los Conceptos: Iteraciones. Autoorganización. Descripción del método.
- La Documentación: Qué es, cómo se arman y cómo se utilizan el Product Backlog, el Sprint Backlog y Burndown Chart.
- La Práctica: Se formarán equipos de trabajo, que resolverán un caso práctico. Se asignarán los roles y se discutirá cada caso en particular, buscando arribar a la solución al final de la jornada.

Lo importante es el trabajo práctico. Iremos descubriendo juntos algunas características, prácticas, y el por qué de cada cosa, en el marco de trabajo Scrum.

Para los que no puedan asistir, recuerden que siempre escribo por acá sobre el tema en posts sobre Scrum. Ahí encontraran un varios posts, con enlaces, referencias, presentaciones, sobre el tema Scrum y ágil en general. Los posts primeros a revisar, con material relacionado, incluso un video de una charla y discusión sobre el tema, en:

Resultado de la VAN en ALT.NET Hispano sobre Scrum
Scrum Práctico
Scrum Práctico en Santa Fe
Explicando Scrum

Nos leemos!

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

Tales from the Scrum: La esencia de Scrum

lopez — Mon, 16 Nov 2009 09:14:45 GMT

En esta serie de post, aún falta que escriba describiendo de principio a fin lo que es Scrum. Para llegar a ese punto, primero quiero compartir con Uds. esta traducción de un post de Tobias Mayer, quien fue mi instructor de Scrum Mastering en 2006. El post original, en inglés, lo encuentran en:

Essence of Scrum

Acá va mi traducción:

Scrum comenzó su vida como uno de las nuevas formas Agiles para construir software. En estos días, se lo considera una forma que puede ser usada para mejorar el mundo del trabajo, en un sentido más general, y así, cambiar la forma en que los individuos piensan e interactúan con otros en situaciones de trabajo. El potencial completo de Scrum está por explorar.

En resumen, Scrum es una manera simple de manejar problemas complejos, proveyendo un marco de trabajo para soportar la innovación y permitir que equipos auto-organizados entreguen resultados de alta calidad en tiempos cortos. Scrum es un estado de la mente; en una manera de pensar que libera el espíritu creativo mientras se mantiene firmemente apoyado en principio sólidos y largamente respetados, incluyendo el empirismo, la emergencia y la auto-organización.

Empirismo se refiere al proceso continuo de inspeccionar/adaptar que permite que tanto trabajadores como gerentes tomen decisiones en tiempo real, basado en datos actuales, y como resultado, puedan responder rápidamente a condiciones siempre cambiantes que se presentan en el ambiente, como por ejemplo, el mercado donde el software a construir es vendido o distribuido.

La Emergencia surge de una aproximación empírica. Implica que todas las soluciones a todos los problemas se volverán claros a medida que trabajamos. No se volverán claros si simplemente hablamos de ellos. El “Big Up Front Design” (gran diseño de antemano) sólo producirá un “Big Wrong Design” (gran diseño erróneo) o a lo sumo un “Big Working But Totally Inflexible Design” (gran diseño que funciona pero totalmente inflexible). Cuando permitimos que las soluciones emerjan es siempre la solución más simple y apropiada, para el contexto actual, la que sube a la superficie. La emergencia junto con el empirismos nos guiaran a la solución más apropiada y flexible (es decir, que podemos cambiar).

Auto-organización se refiere a la estructura de los equipos que crean el producto. Se les da poder a pequeños equipos multidisciplinarios para que puedan tomar decisiones importantes, necesarias para 1) crear un producto de alta calidad, y 2) manejar su propio proceso. Acá la idea es que aquellos que hacen el trabajo conocen mejor que nadie cómo hacer el trabajo. Estos equipos trabajan de una manera altamente interactiva y generativa, donde el producto emerge del diálogo continuo, de la exploración e iteración. La auto-organización funciona cuando hay objetivos y límites claros.

Además de estos principios, Scrum se apoya en dos mecanismos principales: priorización y “timeboxing” (poner límites de tiempo a una tarea).

Priorización simplemente significa que hay cosas que son más importantes que otras. Esto es tan obvio que se olvida muchas veces cuando pensamos “necesitamos esto AHORA”. Scrum nos ayuda a poner el foco de vuelta en seleccionar cuáles son las cosas más importantes a hacer primero, y entonces, a hacerlas! Tomándose el tiempo para priorizar, y siendo rigurosos sobre eso, es esencial para el éxito de Scrum.

Timeboxing es un mecanismo simple para manejar la complejidad. No podemos imaginar el slistema completo de una vez, todo junto, entonces, tomamos un pequeño problema y en un corto espacio de tiempo, digamos una semana o un mes, trabajamos en solucionar ese problema. Los resultados de esa acción nos guiaran entonces a una solución para el próximo problema, más grande, y nos dará más conocimiento sobre las necesidades del sistema en conjunto.

Cambio organizacional

Con Scrum, las jerarquías de gerencia de las organizaciones tienden a ser niveladas y los equipos de desarrollo tienen más contacto directo e inmediato con los clientes. El ambiente de trabajo se vuelve menos “comandar-y-controlar” hacia un estilo más colaborativo. Se promueve el diálogo regular y abierto sobre la documentación extensiva, y el acuerdo negociado es preferido a los contratos de trabajo formales e impersonales.

Las cualidades de apertura, honestidad y coraje son fomentadas en todos los niveles, y la ganancia individual se vuelve secundaria ante el avance colectivo. Un ambiente Scrum es uno que soporta a la gente, donde las personas de todos los niveles muestran respeto y confianza entre ellos. Las decisiones se toman por consenso, más que por imposición de alguien de más arriba, y todo el conocimiento es compartido, de una manera transparente y sin recelos.

Scrum va en contra de lo que hacen muchas compañías de la industria del software, donde una forma en fases acoplada con un alto grado de micro-gerenciamiento, y una insistencia en procesos definidos y documentación extensiva, se han hecho la norma por treinta años. Muchas compañías se basan en el miedo y el dinero como motivaciones claves para sus trabajadores. Esta forma de trabajo ha mostrado éxitos a corto plazo, pero más y más compañías están comenzando a entender que no es una buena estrategia para el largo palzo. Sin embargo, el concepto de cambiar a algo tan radical como Scrum aterroriza a muchos corazones de ejecutivos y gerentes de nivel medio.

Scrum está aún en la etapa de los “early-adopter” (los que abrazan tempranamente las nuevas ideas). Tomará muchos años para que la mayoría de las compañías reconozcan los beneficios de crear más lugares de trabajo, llenos de confianza. Sin ese cambio, muchas compañías de software se irán hundiendo bajo el peso de sus procesos pesados, y fuerzas de trabajo sobrecargadas. Otros, aquellos que abracen el método liviano, ágil, de Scrum, tendrán la gran oportunidad de sobrevivir y prosperar. Para aquellos que pasen a Scrum, y lo abracen completamente, la vuelta atrás a a los viejos días de trabajo será impensable. Un cambio de paradigma está ocurriendo en el lugar de trabajo, y Scrum es una parte importante de ese cambio.

Nota: el término Scrum proviene de un “paper” titulado The New New Product Development game de Hirotaka Takeuchi y Ikujiro Nonaka. En rugby, un scrum es una forma de recomenzar el juego, luego de una infracción accidental o después que la pelota salió de juego. La práctica de Scrum en el mundo del software incluye reuniones regulares diarias y cortas donde los miembros del equipo se juntan para comunicar su progreso. Debido a la similitud entre la pausa del juego (trabajo), y habiendo los jugadores (miembros del equipo) armado la reunión, ésta se conoce comúnmente como el Daily Scrum. Jeff Sutherland, John Scumniotales y Jeff McKenna son los responsables de haber introducido el término Scrum en el mundo del desarrollo del software en 1993, mientras trabajaban en la Easel Corporation, una compañía de herrmientas de software de Massachusetts. Ken Schwaber escribió el “paper” original sobre Scrum, SCRUM Development Process, que fue presentado en la conferencia OOPSLA en 1995.

Otras referencias:
Scrum: its place in the world
Scrum for Software Development

Gracias a Tobias por tan buena descripción de Scrum.

Nos leemos!

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

Smalltalks 2009 en Buenos Aires: Una conferencia pensada para vos

lopez — Thu, 12 Nov 2009 11:02:43 GMT

Ya había publicado el anuncio de este evento en:

Smalltalks 2009 en Buenos Aires

Puede ver más detalle en el sitio del evento:

Smalltalks 2009

Y en mi post, encontrarán enlaces y detalles de algunos de los participantes de esta tercera edición de estas conferencias y reuniones, armadas por la comunidad smalltalkera de Argentina.

Me pareció interesante publicar este email que recibí en una lista, donde la gente organizadora explica más en detalle los eventos, y el interés que tienen para los desarrolladores de software, sean o no del ambiente Smalltalk:

¿Querés conocer cómo se gestó la programación orientada a Objetos? ¿Te gustaría conocer en persona a uno de aquellos locos que revolucionaron la computación en la década del 70 en Xerox Parc junto al Turing Award Alan Kay?, entonces tenés que venir a Smalltalks 2009 a ver la charla de Dan Ingalls sobre "40 Years of Fun with Computers" y la sesión de preguntas y respuestas denominada "A fireside chat with Dan Ingalls"

¿Querés conocer qué es lo último que se está haciendo de investigación en objetos, realmente distinto y novedoso?, entonces tenés que venir a Smalltalks 2009 y ver la presentación de Stephane Ducasse "I have a dream... let's make it came true" y la presentación de Alex Warth "Implementing programming languages for fun and profit with OMeta"

¿Estas interesado en entender un poco más que es la meta-programación y para que sirve? ¿Querés entender qué significa que un ambiente sea Meta-Circular? ¿No te cierra la herencia múltiple, te parece que las interfaces de Java o .Net se quedan cortas, tenés dudas sobre los mix-ins y sentís que debe haber una mejor manera para compartir código?, entonces tenés que venir a Smalltalks 2009 y ver las charlas de "Glamour" y "Helvetia" de Jorge Ressia, "Mejorando las herramientas de desarrollo de Smalltalk" de Diego Geffner y "Traits at Work" de Stephane Ducasse.

¿Alguna vez te preguntaste cómo funciona una base de objetos, qué diferencias tienen con una base de datos relacional, son más rápidas, son más lentas?... no quiero sonar repetitivo pero no puedo evitarlo, ¡¡¡tenés que venir a Smalltalks 2009!!! hay una charla dada por James Foster denominada "Introduction to GemStone" y un tutorial de un día enteramente dedicado a este tópico, ¡no te lo podés perder!

¿Alguna vez te preguntaste si es posible manejar hardware en tiempo real con objetos y con un lenguaje dinámico? ... hmmm... entonces no te queda otra que venir a Smalltalks 2009 y ver la charla de Gonzalo Zabala sobre "Physical EToys" y la de Andrés Otaduy sobre "Sistema Rul@"

¿Tenés dudas sobre si es posible diseñar y escribir con objetos buenos algoritmos genéticos o modelos matemáticos?, si lo tuyo va por ese lado, entonces tenés que venir a Smalltalks 2009 y ver la chala de Maximiliano Tabacman sobre "Genetic Algorithm Framework" y la de Leandro Caniglia sobre "Homological Algebra in Smalltalks"

¿Estás interesado en conocer los detalles de implementación de una Virtual Machine de objetos o saber qué tan seguras o inseguras son? jeje, ¡¡también tenemos dos charlas para vos!!. "Virtual Machine, Invisible Machine" de Andrés Valloud (programador de la VM más rápida de Smalltalk) y "Security on JIT VMs" de Gerardo Richarte (un experto en seguridad... ¿o inseguridad?)

¿Lo tuyo va por asegurar la calidad de los sistemas? ¿Te pega todo lo ágil, TDD, etc?... no quiero sonar repetitivo pero me es imposible... ¡tenés que venir a Smalltalks 2009! y ver las charlas de Tim Mackinnon sobre "Agile Planning" y "Expressive Testing" y la de Nicolas Chillo y Gabriel Burnstein sobre "Mutation Testing".

¿Estás cansado de tener que subir y bajar el server cada vez que modificas tu aplicación web, pensás que deben haber maneras más sencillas de hacerlo? ¿Estás cansado de recompilar tu aplicación Java u ObjectiveC para poder ver un pequeño cambio que hiciste en tu aplicación de iPhone?, no queda otra que vengas a Smalltalks 2009 y veas las charlas de Germán Arduino sobre "SWT", la de Santiago Robles y Lautaro Fernandez sobre "Meteorid: Un MVC real para la Web" y la de Esteban Lorenzano sobre "Smalltalk in the pocket: Building applications for the iPhone"

O por el contrario, ¿no te gustan la charlas, te aburre esto de escuchar hablar gente todo el día, lo tuyo va por la acción, por construir cosas en serio que aporten a la comunidad, por codear, y no me refiero a pegar codazos :-)? o por ahí siempre escuchaste de Smalltalk pero nunca tuviste el tiempo o la ayuda para meter las manos en la masa? hmm, que se yo, podés darte una vuelta el sábado por Smalltalks 2009 y participar del Pharo Sprint!, una sesión de programación de todo un día que sirve para mejorar y ampliar Pharo, un Smalltalk open-source.

¿Siempre escuchaste o creíste que los lenguajes dinámicos no sirven para desarrollar aplicaciones grandes, o que Smalltalk sólo se usa en la universidad para enseñar? Entonces te conviene venir a Smalltalks 2009 y ver "XTrade - Risk and Yield Analisis" de Maximiliano Tabacman, "Expecco" de Felix Madrir e "iBizLog" de Jose Bretti.

¿Tu especialidad es el User Interface, gráficos 3D, etc.?... también tenemos algo para vos como "Un ambiente visual para desarrollar software" de Adian Soma, "Cuis and Morphic 3" de Juan Vuletich, "Desarrollo de un engine 3D: Experiencias de un neófito" de Andrés Fortier y "#{Open.Source.Graphics} bindTo: {Cincom.Smalltalk}" de Travis Griggs

¿Te hace falta un iPod? ¿Querés regalarle una cámara digital a tu novia/o, o a tu vieja?... es fácil, anotate en el concurso de programación de Smalltalks, te vas a divertir haciéndolo... y si no lograste ganar nada, no llegaste a hacerlo, podés escuchar a Carlos Ferro, creador del concurso explicando cómo fue desarrollado el mismo en la charla de "Smalltalks 2009 Coding Contest"

Y si sos profesor de programación orientada a objetos y querés obtener información, material de enseñanza y compartir tu dudas y experiencias con otros profesores, tenés que venir a Smalltalks 2009 y ver la charla "Enseñanza de programación orientada a objetos con Smalltalk y prácticas ágiles" de Nicolás Paez o pasar unos minutos con Stephane Ducasse quién compartirá con nosotros todo el material que usan en Suiza y Francia para enseñar objetos.

¿Te cansaste de leer este mail tan largo? ¿te divertiste leyéndolo? ¿querés formar parte de un congreso hecho por programadores para programadores que ya lleva más de 300 inscriptos, divirtiéndote y aprendiendo en el camino? jeje, ¡¡tenés que venir a Smalltalks 2009!!

No dejes de anotarte gratis en www.fast.org.ar

Es del jueves 19 al sábado 21 de Noviembre de este año. Podes ver el detalle de las charlas en la sección "Charlas" o "Talks" de la página web, seguro la vas a pasar bien.

Comite Organizador de Smalltalks 2009

Cualquier duda manda un mail a info@fast.org.ar

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

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

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

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