August 2008 - Posts
La gente de la Asociación de Desarrolladores de Videojuegos Argentina, siempre está trabajando difundiendo la actividad de desarrollo de juegos, desde hace años. Ahora, lanzan un "call for papers" para la exposición que organizan para este año:
http://adva.com.ar/eva/
Pueden ver ahí las presentaciones del año pasado (EVA 07), y de otros años:
http://www.adva.com.ar/eva/biblioteca/
Este es parte del texto de la convocatoria para este año, que me llegó por email:
ADVA (Asociación de Desarrolladores de Videojuegos Argentina - www.adva.com.ar) abre el llamado a presentación de propuestas para disertantes en la 6ta edición de EVA (Exposición de Videojuegos Argentina) a realizarse los días 15 y 16 de Noviembre de 2008 en el Centro Cultural General San Martín, Buenos Aires.
Se recibirán abstracts para charlas y debates hasta el domingo 7 de Septiembre de 2008.
Diferentes áreas aplicables al desarrollo de videojuegos son bienvenidas, pero no limitadas a:
Programación de juegos (gráfica, inteligencia artificial, etc.)
Audio en videojuegos
Diseño de videojuegos
Estética y narrativa de juegos
Arte
Investigaciones académicas sobre juegos
Medios de distribución alternativa
Business (marketing, legales, exportación, etc.)
La profesionalización de la industria de videojuegos en Argentina
Calidad de vida de desarrolladores en Argentina
Internacionalización de Argentina en la industria de videojuegos
Se dará prioridad a aquellas propuestas que apuntan a un público medio-avanzado. Se aceptaran propuestas de charlas para principiantes, pero en menor medida.
Las propuestas deben ser enviadas on-line en la siguiente dirección: http://www.adva.com.ar/eva/openconf/openconf.php
Hay más información en
EVA 08: Llamado a presentación de propuestas
Creo que con la experiencia que tienen, la exposición va a ser un éxito. Pueden visitar el sitio de ADVA para ver la actividad que tiene el desarrollo de juegos en nuestro país, donde hay programadores y diseñadores trabajando para el mundo.
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com/
En algunas empresas, IT es el departamento odiado, o por lo menos, olvidado, despreciado, como una tía loca que uno no quiere mostrar en público. La aparición de series como IT Crowd nos muestra un poco relegados en el ambiente de una empresa. No debería ser así, pero es lo que pasa en varios lugares que he visitado. Tendríamos que conseguir revertir esa impresión. Creo que las metodologías ágiles son un camino. Pero el tema da para más discusión. Por ahora, veamos un video de broma, la guerra IT vs Ventas en una empresa:
Gracias a Jonathan Cisneros, creador del AjGenesis Studio, por el enlace a este video.
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com/
Este texto ha sido "robado" sin vergüenza, del post
A Java Syntax Quirk
de Dan Dyer que a su vez lo robó de otro post de Daniel Futtorovic. Este es un programa compilable Java:
public class Oddity
{
public static void main(String[] args)
{
http://blog.uncommons.org
System.out.println("Why is the URL allowed above?");
}
}
¿Pueden ver por qué compila?
¿Es posible algo así en C#?
Encontré el enlace gracias al twitter de @ekabanov.
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com
Cualquiera puede reconocer en mí a un entusiasta de la generación automática de código, con un agregado: usar un modelo como el punto de partida del proceso. He adoptado esa idea cada semana, practicando "dog fooding", usando mi propio proyecto de generación de código AjGenesis. Esta semana, estoy leyendo el libro ya clásico "Code Generation in Action" , de Jack Herrington, editado por Manning. Este libro es un "debe ser leído" por cualquiera ineresado en generación de código. Es una muy interesante lectura para desarrolladores: el autor expone un caso a favor del uso de la generación de código, apelando al incremento en calidad y productividad en proyectos de software, incluyendo equipos ágiles.
En el primer capítulo, Herrington lista las reglas "top ten" que quiero comentar en este post. Los párrafos indentados que siguen son extraídos del libro (sección 1.7), seguidos por mis propios comentarios:
De el debido respeto a código generado a mano
Ud debe respetar y rechazar el´código manal. Ud. debe respectarlo porque hay casos especiales en el código que son pasados por alto en una inspección somera. Cuando reemplaza código manual por código generado, necesita estar seguro de haber contemplado esos casos especiales. Ud. debe sentirse disgustado con el código manual porque el tiempo de desarrollo es extremadamente valioso, y gastarlo en tareas repetitiva es casi criminal. El objetivo de su generador de código debe ser siempre optimizar el activo más valioso de su organización: la creatividad y el entusiasmo del equipo de desarrollo.
Cierto, la base de la generación de código es hacer fácil el delegar las tareas repetivivas a la máquina. Nosotros tenemos que usar herramientas que hagan más fácil nuestro trabajo: ésa es la razón por la que usamos compiladores hoy en día, en lugar de estar "seteando" los bits en la memoria (o "seteando" los relés en la vieja Eniac a mano). La razón que sustenta la generación de código no es destruir el código manual: su misión es soportarlo.
Primero escriba a mano
Ud. debe entender completamente su framework antes de generar código. Idealmente, debería escribir a mano una amplia y significativa cantidad de código con el framework, primero, y luego entonces, usarlo como base para los "templates" de su generador.
Absolutamente de acuerdo. A veces, los nuevos usarios de AjGenesis comienzan a usarlo directamente de los ejemplos. Eso es bueno, pero seria mejor generar un ejemplo usando el framework y la tecnología que tengan que encarar. Si Ud. conoce cómo programar usado Struts/Hibernate, entonces puede separar las variaciones técnicas de lo esencial. Llegado a ese punto, podrá comenzar a escribir los artefactos de generación de código que necesite (templates, tareas).
Controle el código fuente
No puedo dejar de enfatizar la importancia de tener un sistema de control de código robusto. Es crítico para el éxito de un proyecto de generación de código. Si su generador trabaja directamente sobre los archivos de implementación que contiene código generado a mano, asegúrese que tiene el sistema de versionado funcionando para que pueda proteger su trabajo.
Otro camino: si Ud. genera código desde el modelo, incluya en el repositorio de código sólo al modelo. El resto de los artifactos vendrán producidos por el proceso de generación. Con la actual tecnología, no se puede generar TODO la aplicación, pero Ud. puede separar, con cuidad, la parte manual de la generada.
Tome con cuidado una decisión sobre el lenguaje de implementación
Las herramientas que use para armar el generador no tienen que ser las mismas que usa para escribir las aplicaciones finales. El problema que el generador está tratando de resolver es completamente diferente del las aplicaciones. Por esa razón, Ud. debe ver al generador como un proyecto independiente y diferente, y elegir sus herramientas de acuerdo a lo que necesita.
Esta es una de las razones por que adopté un nuevo lenguaje (llamado afectuosamente AjBasic) para mi proyecto AjGenesis. Yo quería un lenguaje dinámico que estuviera bajo mi control, para extenderlo en cualquier dirección que el proceso de generación requiera. En uno de mis pruebas iniciales, intenté usar PHP, pero he preferido usar un lenguaje dedicado y pensado para este trabajo, como AjBasic.
Integre el generador en el proceso de desarrollo
El generador es una herramienta para ser usada por ingenieros; entonces, debería encajar claramente en algún punto del proceso de desarrollo. Si es apropiado, puede integrarse en la IDE que use, o en el proceso de build o de check-in en el repositorio de código.
Al haber hecho que el núcleo del AjGenesis sea una librería de clases .NET, pude integrarlo con otras herramientas. Ahora, puedo usarlo desde el NAnt. Una herramienta que se integre a la IDE del Visual Studio o del Eclipse, es una tarea pendiente.
Incluya advertencias
Su generador debe siempre dejar advertencias en el código para qu ela gente no vaya y toque ese código. Si se agrega código agregado a mano y se ejecuta de nuevo el proceso de generación, perderemos las modificaciones. No debe culpar a la gente: el que estén usando su herramienta es un gran paso adelante. En cambio, ponga mayores advertencias, y mejore la documentación del generador. Ud. es el emisario de su herramienta.
En AjGenesis, este problema es atacado por los templates que el usuario escriba. Ud. puede agregar cualquier texto que Ud. quiera, con las advertencias correspondientes: éste es el poder de poder escribir sus propios templates, Ud. tiene la propiedad del código generador, no depende de la herramienta.
Hágalo amigable
Sólo porque el generador es una herramienta para programadores no significa que tenga que ser críptico su uso. El generador debe decir al desarrollador lo que está haciendo, y qué archivos ha alterador o creado, y debe manejar los errores con una razonable cuota de decoro. Puede parecer tonto, pero una herramienta que es difícil de usar o que no es amigable será ignorada y sus esfuerzos por promoverla serán en vano.
El núcleo de AjGenesis es una dll, que puede ser invocada desde una aplicación. Hace años, escribí tareas para invocarlo y ser usado desde el NAnt. Gracias a Jonathan Cisneros, tenemos el AjGenesis Studio, desde el año pasado. He mejorado el código original, y a principios de 2008, agregué el AjGenesis Web Studio, para generar desde una interfaz web. El manejo de errores debe ser mejorado, especialmente para los nuevos usuarios de AjBasic.
Incluya documentación
La buena documentación es un punto a favor de la venta del generador. Su documentación debe ser abarcativa, sin ser intimidante, y cubrir los puntos principales: qué hace el generador, cómo se instala, cómo se ejecuta, y qué archivos afecta.
Actualmente, éste es un punto no bien cubierto por AjGenesis. Pero a cambio, hay varios posts explicando el proceso y los ejemplos (AjGenesis posts) (AjGenesis posts en Español). Usuarios de la herramienta están comenzando a escribir también (ver los posts de Carlos Marcelo Santos). Hay una lista de correo en español donde los usuarios pueden discutir sob ela herramienta y su uso (Code Generation group). Y en la la página del proyecto en Codeplex, hay ejemplo para generar Java, .NET, y PHP, varios usando el mismo modelo (una prueba ácida para un generador).
Recuerde que la generación es un tema cultural
Uducar a sus colegas con documentación, seminarios, y encuentros uno a uno es crítico para instalar y usar su generador. La gente es escéptica a las nuevas cosas, y un buen programador es el doble de escéptico que una persona promedio. Ud. necesita romper con esa resistencia y dudas, y emfatizar que el generador que ha diseñado los beneficiará.
Yo doy de tres a cuatro charlas por año, sólo dedicadas a explicar la herramienta y su potencial. Adicionalmente, la explico en casi cada curso que doy (de Java, .NET, PHP o de software en general). Pero para ser adoptada por una compañía o en un proyecto, un usuario debe tomar el cargo de campeón del producto. No es fácil elevar el nivel de abstracción, escribir el modelo y sus transformaciones, en el medio del trabajo del día a día.
Mantenga el generador
A menos que el generador sea una medida temporaria, necesitará ser mantenido en el largo palzo. Si el generador maneja una cantidad grande de código, trátelo como Ud. trataría a un ingeniero manteniendo ese mismo código. Su presupuesto debe incluir tiempo y dinero dedicado a mantener y actualizar este recurso.
AjGenesis no es parte de las "cosas" a mantener. Estas son los templates y tareas que usará en su trabajo. Si Ud. adopta la herramienta para generar aplicaciones, digamos, .NET, Ud. tiene que cambiar e ir mejorando los templates cuando nuevas tecnologías aparezcan (LINQ, ASP.NET MVC....). Y cuando Ud. gana experiencia, Ud. tiene que mejorar el mismo modelo, si descubre nuevas maneras de representar las líneas de producto en las que su compañía se interesa.
Yo podría agregar algunos puntos más:
- El código generado debe ser de la clase de código que Ud. mismo hubiera producido, y del que se sienta orgulloso. La herramienta no debe dictar la forma y la apariencia de su código. Ud. debe estar a cargo.
- El uso de un modelo eleva el nivel de abstracción que manejamos. Esta estrategia separa la paja del trigo, pone los detalles técnicos en el lugar que merecen: lo importante es el modelo.
Bueno, bastante por ahora. Como pueden darse cuenta, la generación de código es un tema que me apasiona. No es la bala de plata. Pero es un arma que quisiera tener, por si la necesito.
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com
En estos días, ha sido lanzado un nuevo sitio dedicado a Smalltalk:
http://www.clubsmalltalk.org/
Según el sitio:
ClubSmalltalk.org is a non-profit organization which congregates Smalltalk programmers and enthusiastics. In 2008, we are going a step forward with this new website.
The big idea behind this website is to provide a source of information about Smalltalk in general.
The Smalltalk community has not good sources of information, or they're all over the net, and sometimes it's difficult to find them.
If you want to contribute, you're welcome!
Es un desprendimiento de la actividad de la lista de correo en español:
http://groups.google.com/group/clubSmalltalk
Algunos de los artículos más populares que contiene:
Interview with Luca Bruno, the creator of Smalltalk YX
Argentinian Smalltalk Congress- Smalltalks 2008
Seaside and Ruby on rails
Tiene secciones como:
FAQs:
Smalltalk Frequently Asked Questions
GemStone Frequently Asked Questions
Environments:
Commercial Smalltalk Environments
Free Smalltalk Environments
Abbandon Smalltalk Environments
Frameworks, Platforms & Tools
y más: herramientas, recursos, comunidad. Tiene enlaces a libros sobre Smalltalk como:
Free Books
Thanks to the work of Stéphane Ducasse, we have a huge collection of Free Smalltalk books online.
Download from http://www.iam.unibe.ch/~ducasse/FreeBooks.html
Creative Common Books
Our friend Diego Gomez Deck has written an excellent book in Spanish to start in Smalltalk. You can buy a hardcopy or you can download it under the creative common licence from http://smalltalk.consultar.com/.
If you like it, we recommend to buy it, we are proud of this kind of projects.
El sitio recién comienza, pero espero que con la ayuda de la comunidad Smalltalk, vaya creciendo y se convierta en una referencia para todo interesado en ST.
Está armado con PHP. En mi opinión, es un buen signo: por años, la comunidad Smalltalk estuvo signada por un cierre hacia otras tecnologías o herramientas. En estos días, con la plétora de lenguajes, frameworks y plataformas, debemos abandonar esa tendencia a la aislación, e integrarnos con el resto de la tecnología.
Angel "Java" Lopez
http://www.ajlopez.com/
En mi anterior post sobre F#:
Primeros pasos en F#
había mencionado que no hay variables en el lenguaje, que hay identificadores. ¿cómo es eso? Exploremos el concepto de closure (podría traducirlo cierre, cerramiento, clausura), y cómo se usa en F# (closure es una característica de varios lenguajes).
De acuerdo al artículo de la Wikipedia sobre closures en ciencias de la computación:
a closure is a function that is evaluated in an environment containing one or more bound variables
(una closure es una función que es evaluada en un ambiente que contiene uno o más variables ligadas)
Bueno, ¿qué significa esto? Para entenderlo, asignemos un valor a un identificador, usando el fsi.exe, el intérprete interactivo de F# (podríamos usar Visual Studio también):
MSR F# Interactive, (c) Microsoft Corporation, All Rights Reserved
F# Version 1.9.3.4, compiling for .NET Framework Version v2.0.50727
NOTE:
NOTE: See 'fsi --help' for flags
NOTE:
NOTE: Commands: #r <string>; reference (dynamically load) the given DLL.
NOTE: #I <string>; add the given search path for referenced DLLs.
NOTE: #use <string>; accept input from the given file.
NOTE: #load <string> ...<string>;
NOTE: load the given file(s) as a compilation unit.
NOTE: #time;; toggle timing on/off.
NOTE: #types;; toggle display of types on/off.
NOTE: #quit;; exit.
NOTE:
NOTE: Visit the F# website at http://research.microsoft.com/fsharp.
NOTE: Bug reports to fsbugs@microsoft.com. Enjoy!
> let x = 2;;
val x : int
Ahora, tenemos un identificador x. Podemos mostrar su valor con:
> x;;
val it : int = 2
Un simple y conocido entero. Ahora, no podemos cambiar su valor: este identificador fue escrito en piedra como que es el entero 2. Nada en la historia humana y de F# podría cambiar sy valor. ¿Será así? Definamos una función:
> let dup n = n * x;;
val dup : int -> int
Esta función dup toma un argumento n y lo multiplica por el valor del identificador x. Este identificador es una "variable" libre en la función: no es un identificador local, viene de afuera de ella. Durante la evaluación de la función, x toma su valor del "environment", del ambiente en el que estaba durante la definición de dup. Probemos ahora:
> dup 3;;
val it : int = 6
El resultado fue seis, como esperábamos. Pero ahora, veamos de "cambiar" el valor de x:
> let x = 3;;
val x : int
> x;;
val it : int = 3
En este punto, tenemos que comenzar a hablar de closures: este "x" es OTRO identificador, que oculta el anterior. PERO, para la función dup, el identificador x es TODAVIA el anterior. Veamos de comprobar esto, invocando de nuevo la función:
> dup 3;;
val it : int = 6
¡¡El dup todavía usa el x original!! Aquí está la closure en acción. Si intentamos:
> dup;;
val it : (int -> int) = <fun:clo@0>
Notemos el clo @ 0 : es la firma de la closure que esta función está usando. Apunta al ambiente original donde la función había sido definida.
Esta característica implica que la conducta de una función no cambia luego de su definición. Aún las aparentemente "variables libres" están ligadas en tiempo de definición. Toto esto es parte de los fundamentos sólidos de la programación funcional, en general, y de F#, en particular.
Sobre closures en general y conceptos relacionados, como los lambdas, tenemos para leer a:
The Original 'Lambda Papers' by Guy Steele and Gerald Sussman
Podemos aprender mucho de Lisp, lambdas y closures, viendo:
Implementé algunas lambdas y closures, en mi intérprete Lisp:
AjLisp: a Lisp interpreter in .NET
Más sobre closures y C# en:
What's In A Closure?
Fibonacci Numbers, Caching and Closures
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com
El año pasado se realizó la primera conferencia de este tipo en Argentina. Ahora, un grupo de smalltalkers está preparando la versión 2008. En este sitio (basado en Seaside) está el anuncio:
Smalltalks 2008 - 2da Conferencia Argentina de Smalltalk
Este año la conferencia se realizará los días 13, 14 y 15 de Noviembre, en la sede de la Universidad Abierta Interamericana, Av. Montes de Oca 745, Buenos Aires, Argentina. Al igual que el año pasado la inscripción a la conferencia será gratuita.
En esta edición buscamos enriquecer la oferta de actividades. Por ello abrimos los llamados a: Charlas La conferencia va a contar con dos secciones, una de Investigación Científica y otra de Industria del Software. Concurso Este año presentaremos un concurso de programación, en el que se podrá utilizar cualquier dialecto de Smalltalk. Keynotes Conferencias invitadas a cargo de personalidades de renombre. Hands on Sección de tutoriales, a realizarse en laboratorios con máquinas.
Hay una llamada a presentar papers (versión PDF), sobre los temas:
- Aspects, Aspect Languages and Applications.
- Ambient Intelligence, Ubiquitous / Pervasive Computing and Embedded Systems.
- Compilation Technology, Optimization, Virtual Machines.
- Educational Material.
- Language Engineering, Extensions.
- Model Driven Engineering / Development.
- Meta-Modeling.
- Programming in the Large, Design, Architectures and Components.
- Programming Environments, Browsers, User Interfaces, UI Frameworks.
- Reasoning About Code (Analyses, Refactoring, Type Inference, Metrics).
- Reflection and Meta-programming.
- Team management.
- Testing, Extreme Programming / Practices.
- Web Services, Internet Applications, Event-driven Programming.
- Experience Reports.
Es interesante que este año hayan extendido el alcance de los temas para incluir otros lenguajes dinámicos, no solamente Smalltalk. Este es el comité de programa:
- Federico Balaguer (LIFIA, Universidad Nacional de La Plata, Argentina)
- Tulio Ballari (UTN, Buenos Aires, Argentina)
- Alexandre Bergel (INRIA, Lille, France)
- Gilad Bracha (Cadence Design Systems, USA)
- Johan Brichau (Université Catholique de Louvain, Belgium)
- Cecilia Challiol (LIFIA, Universidad Nacional de La Plata, Argentina)
- Marcus Denker (SCG, University of Bern, Switzerland)
- Fernando Dodino (UTN, Buenos Aires, Argentina)
- Stéphane Ducasse (INRIA, Lille, France)
- Alejandra Garrido (LIFIA, Universidad Nacional de La Plata, Argentina)
- Tudor Girba (SCG, University of Bern, Switzerland)
- Orla Greevy (SCG, University of Bern, Switzerland)
- Julián Grigera (LIFIA, Universidad Nacional de La Plata, Argentina)
- Andy Kellens (PROG, Vrije Universiteit Brussels, Belgium)
- Kim Mens (Université Catholique de Louvain, Belgium)
- Guillermo Adrián Molina (ESSI Projects, Spain)
- Damien Pollet (INRIA, Lille, France)
- David Röthlisberger (SCG, University of Bern, Switzerland)
- Daniel Solmirano (UTN, Buenos Aires, Argentina)
- Tom Van Cutsem (PROG, Vrije Universeit Brussels, Belgium)
- Roel Wuyts (IMEC, Belgium)
Smalltalk es una tecnología que, en mi opinion, falló en "cruzar el abismo". A finales de los 80s, y comienzos de los 90s, la comunidad estaba dividida en varios dialectos e implementacion comerciales divergentes. Pero el ímpetu de leales miembros de la comunidad se ha probado el año pasado, aquí, en Argentina, con el éxito de la pasada conferencia del 2007. Espero que Smalltalk pueda integrarse con otras tecnologías, como .NET y Java, para ganar más momento y aceptación. Vean, como ejemplo, la adopción de F# en la comunidad científica: el acceso a un framework popular de clases es una característica clave en el "mainstream" de desarrollo de hoy. Insistir en la actitud de un mundo, un solo lenguaje, no la veo como opción en estos días. Celebro, entonces, la apertura de la llamada de papers a otros lenguajes dinámicos.
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com
Hoy, en el Microsoft Users Group de Argentina, Patricia Scalzone y Leticia Medela, de Vemn Sistemas, dictan una sesión sobre por qué fallan los proyectos:
Jornada de Soluciones
El temario es:
Escenario: ¿Por qué fallan los proyectos de software?
Solución: Entre las diferentes causas que llevan al fracaso de un proyecto de software, la tecnología no es la determinante. Esta sesión se focalizará en presentar técnicas y herramientas adecuadas para prevenir esa situación, tomando ALM (Application Lifecycle Management) como referencia.
Hay otros temas, como migrando a SOA, mejorar la calidad del software, y la implementación de un portal CMS, usando DotNetNuke.
Pero me gustaría hoy enumerar rápidamente algunas de las causas por las que fallan los proyectos de software. No será una lista original en contenido, y seguramente Uds. podrán aportar otras causas o explicar mejor alguna de las que presente. Sin poner una prioridad, veamos algunas causas:
No se tiene en claro qué hacer: los requerimientos son difusos, se toman mal, y terminamos haciendo algo que el cliente no necesitaba ni quería. No se entiende cuál es el problema a solucionar, el problema de negocio, el valor que nuestro entregable debe aportar al cliente. Se piensa más en detalles técnicos que en lo que realmente importa.
El cliente participa una vez cada seis meses: no se habla con el cliente, se trata de evitarlo. Se lo considera más un "enemigo" que parte del proyecto. Cada vez que entregamos un avance de la solución, nos damos cuenta que lo que entregamos no era lo que el cliente esperaba.
Gente no dedicada al proyecto: se lanza el proyecto, pero la gente que lo lleva adelante se dedica mientras tanto, a otros proyectos sin terminar, soporte de cliente, mesa de ayuda, a mover máquinas de un lado a otro por cualquier causa.
La gente de ventas prometió el oro y el moro: pasa en muchas consultoras. Por un tema de comisiones, o de posicionamiento en el mercado, se ofrece una solución "inflada" que no corresponde con lo que podemos hacer.
No conocer y entender la tecnología: hay que conocerla y ENTENDERLA. No sólo es saberse de memoria los namespaces de .NET, o la configuración de Spring: hay que entender para qué está cada cosa que usamos.
Usar mal la tecnología: hay quienes creen que usando J2EE y patrones todo queda solucionado: seguridad, escalibilidad, etc, sin detenerse a pensar en qué afecta la tecnología y las decisiones de diseño en lo que quieren lograr.
Cualquier problema lo arreglamos con más gente: en vez de encarar el problema de raiz. Agregar más gente a un proyecto con problemas, es como hechar querosene al fuego.
Equipo malfuncional: en el equipo hay gente que no sabe trabajar en grupo, tenemos "prima donna" que hacen lo que quieren, en vez de hacer lo que el proyecto necesita.
Cambios para mañana: viene alguien, de ventas o de gerencia, pidiendo cambios para el viernes, y estamos en la tarde del jueves.
Falta de recursos: se nos pide desarrollar el próximo Youtube + Facebook, con una máquina IBM XT de una diskettera.
Complicar la solución: para comunicar unos datos a otra aplicación, adoptamos un ESB, dos sistemas de cola de mensajería, una base de objetos, dos relacionales de última generación, y cuatro especificaciones de web services, aplicando transformaciones XSLT ante cada paso. Tal vez una simple programa hubiera dado el mismo resultado.
Falta de coordinación y cooperación: en un proyecto grande, hay varios equipos, posiblemente de distintas consultoras, resolviendo distintas partes del proyecto. Lo que un equipo hace, lo necesita otro, pero coordinan mal la entrega y prueba de las partes. Los equipos no se ven como colaboradores: cada uno hace lo suyo, y si otro equipo tiene problemas, consideran que no es problema de ellos. También pasa esto entre personas de un mismo equipo.
Uds. tendrán otros ejemplos a aportar.
Las metodologías ágiles ayudan a mitigar varios de estos problemas, o por lo menos, a ponerlos de manifiesto antes de que sea tarde. Hay problemas que van más allá de la metodología, que se tienen que resolver a nivel de la dirección de la empresa.
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com/
Mi proyecto de generación de código AjGenesis usa un lenguaje interpretado para ejecutar tareas y expandir plantillas. El lenguaje fue bautizado AjBasic. Lo puede ver usado en todos los ejemplos que escribí para AjGenesis (más información en los posts de AjGenesis). Hace unos años, había separado el códgio del intérprete del proyecto madre, pero nunca lo había publicado. Este fin de semana, estuve refactorizando el código, y ahora, el resultado de ese trabajo está publicado en:
http://code.google.com/p/ajbasic/
En mi opinión, Google Code es fácil de manejar. Al contrario de SourceForge y CodePlex, usa Subversion como repositorio de código. Uso el cliente Tortoise SVN para enviar los cambios. La gente de Google es gentil: pude crear varios proyectos, por ahora esta es la lista:
http://code.google.com/p/ajlisp (en buena forma, se pude comenzar a investigar)
http://code.google.com/p/ajtalk (todavía en su infancia)
Más información en:
AjLisp- un intérprete Lisp en .NET
AjTalk- un intérprete tipo Smalltalk
La Solución
La solución AjBasicWithTests se compone de los proyectos:
AjBasic: implementa el compilador y el tokenizador. El tokenizer separa el texto entrante en tokens. El compilador arma árboles abstractos a evaluar, desde esa entrada.
AjInterpreter: Un nuevo proyecto, no presente en el AjGenesis original. Contiene toto el soporte del árbol abstracto, sus nodos, el ambiente (environment) donde se almaceman los valores, y un evaluador de los programas. El manejo de objetos .NET, y de objetos dinámicos, están en este proyecto. Mi intención es continuar usando este proyecto para soportar otros lenguajes interpretados.
AjBasic.Console: Una simple consola para probar el intérprete.
AjBasic.GUI: Un simple (y feo) WinForm para probar el intérprete.
AjBasic.Test: Algunos tests, usando NUnit (hay otra solución AjBasic que no incluye el proyecto de tests)
Todos los proyectos están escritos usando Visual Basic .NET. La solución fue compilada usando Visual Studio 2005. La consola y el proyecto GUI podrían ser usados como base, explican cómo usar el intérprete desde nuestra propia aplicación.
Hay varios puntos para discutir sobre la implemetación: merecerian otros posts. Por ahora, exploremos algunas de las principales características del proyecto, en su estado actual. Luego, escribiré una lista de ideas a explorar en futuras versiones.
Como mencioné, el lenguaje nació para soportar la generación de código desde AjGenesis. Yo lo diseñé para manejar objetos .NET nativos, así como objetos dinámicos. Pero ¿qué es un objeto dinámico? Es un objeto que no tiene clase asociada, pero que puede ser expandido con nuevas propiedades (el ejemplo más cercano que podría mencionar ahora, son los objetos Javascript).
Así, podemos escribir código como:
a.FirstName = "Adam"
a.LastName = "Doe"
a.Age = 800
No tenemos que declarar la variable. Podemos crear el objeto y agregar la propiedad FirstName en un comando (esta creación automática de objeto no está soportada en AjGenesis, aún, pero se puede crear un objeto del tipo DynamicObject con new).
Podemos probar la existencia de una propiedad:
if a.LastName then
' it has a LastName not nothing
else
...
end if
Si la variable a no tiene valor asignado, o si no tiene la propiedad LastName, la condición de arriba es evaluada a falso. Podemos preguntar por algo como foo.bar.anything y no se levanta una exception. El valor del resultado sería Nothing, que es evaluado y tomado por falso en una condición.
Los Tests
La solución no fue desarrollado usando TDD (Test-driven development). Escribí los tests despues del código, solo para estar seguro que la funcionalidad principal estuviera bien implementado, cumpliendo con lo que esperaba de cada método. No usé nombres descriptivos para los tests, pero me fueron muy útiles cuando encaré la refactorización de la solución completa:
Podemos probar el lenguaje desde la consola AjBasic.Console:
y desde el WinForm AjBasic.GUI
Ninguno de los dos es la "qué aplicación, que bruta...", pero funcionan.... ;-)
Próximos Pasos
Hay varias ideas volando cerca de la neurona que me queda, y tengo que poner orden en mi cabeza. Algunos puntos, para que queden escritos:
- Ahora que el núcleo del intérprete está separado del compilador basic, me gustaría escribir AjSharp, un intérprete con sintaxis C#. Entonces, podría ser agregado a AjGenesis, para escribir plantillas y tareas en ese lenguaje, que puede resultar más agradable para los programadores C#.
- Agregar soporte de clases dinámicas y prototipos.
- Refactorizar los tests
- Escribir un manual mínimo, explicando el lenguaje y sus características
- Extender el lenguaje para soportar valores "delayed" y "delayed evaluation" (quizás paralelismo).
- La forma internal del intérprete podrías ser reescrita en Java
- La opción de escribir un AST (Abstract Syntax Tree) que se acople al soporte de DLR (Dynamic Language Runtime) no me atrae, podría llevar mucho trabajo. Pero podría ser interesante para aprender sobre el soporte de DLR en .NET.
- Usar el lenguaje como base para la programación de agentees distribuidos (un punto ambicioso, que merece mayor evaluación).
Como es costumbre, me divertí mucho escribiendo este software.
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com/en
Se va acercando la primera conferencia latinoamericana de metodologías ágiles:
Primeras jornadas latinoamericanas sobre metodologías ágiles
Entre los referentes internacionales que ya han confirmado su participación en Ágiles 2008 se encuentran Mary y Tom Poppendieck, Matt Gelbwaks y Tobias Mayer.
Ágiles 2008 es un evento sin fines de lucro, el cual es organizado por entusiastas del tema y abierto a cualquiera que tenga ganas de participar.
Si tiene interés en colaborar con la organización de Ágiles 2008, lo invitamos a dejarnos sus datos de contacto aquí
Tobias Mayer es un entrenador de metodologías ágilas, que nos enseñó a muchos de nosotros, acá en Argentina. Una persona de múltiples intereses (como la actividad teatral), muy amable y con grandes habilidades de comunicación, para inspirar a la gente en el método ágil. Podemos considerarlo "el padrino" del movimiento ágil en mi país...:-)
Los organizadores están convocando a enviar "papers", ideas, y propuestas para actividades:
¡Ir a una conferencia a escuchar es demasiado aburrido! Recibimos su idea para participar activamente de Ágiles 2008. En principio tenemos pensadas tres tipos de actividades: Presentaciones (tradicionales, con transparencias, gente sentada escuchando y preguntas al final), Sesiones Interactivas (gente parada haciendo ejercicios tipo teatrales) y Mesas de Discusión (similar a un debate). Pero a no amedrentarse: escuchamos cualquier idea y tratamos de darle un lugar y un momento.
Los bloques serán de 45 minutos, pero es posible tomar más de uno para una misma actividad.
Hay tiempo hasta el 1 de septiembre para presentar una propuesta.
http://www.agiles2008.org/es/call4papers.php
Por años, las metodologías ágiles fueron ganando aceptación en mi país, Argentina, y en Latino América. Y ahora es el tiempo para mostrarlas al resto de la industria, para que vean qué es el movimiento ágil.
A hacerlo! (eso sí, antes escriban un "backlog" ... ;-)
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com