Seminario de "Prototype Oriented Programming"

Hace varios días que no posteo nada... estuve un poco entretenido con la compra de la casa, participando en seminarios/cursos y obviamente disfrutando de mi hijo.
El Martes 17 de Octubre, la gente de APIT me invitó a un seminario de "Programación Orientada a Prototipos", todos los martes nos juntamos para discutir temas de la materia, pero como justo ese martes caia el seminario del grupo athenas.
Quien dió el seminario, fue el Lic. Hernan Wilkinson, muchas veces habia escuchado hablar de el en IBM, si hablas con la gente es casi un dios, todos los que están hace mas de 8 años lo conocen como un excelente arquitecto y evangelizador del eXtreme Programming y Smalltalk. Lamentablemente no tuve la oportunidad de conocerlo. y apenas estoy hace 3 años.

Con respecto a la charla, sinceramente, estuvo muy buena, casualmente el mismo día, sin saber que a la noche iba a ir al seminario, lo estuve charlando con Gona sobre el tema, el me estuvo explicando de que se trataba.
Lo que realmente me interesó fue la comparación que hizo entre la Filosofía y la Programación Orientada a Objetos, verdaderamente yo no estaba al tanto el mapeo que habia entre lo que Platon y luego Aristoteles que encaja perfectamente con la POO, con clases. No es una rebundancia decir "POO con Clases"?? NO, para nada, la POO no expecifica que tienen que existir clasificaciones de objetos, ahi viene la mayor diferenciación entre lo que todos conocemos por POO (Smalltalk/Java/C# etc) y la POO Orientada a Prototipos. En pocas palabras se puede decir que la Programación Orientada a Prototipos es un sub-grupo de la POO, que utiliza las mismas herramientas pero sin clasificar a los objetos, cada objeto tiene su propio comportamiento, que puede variar a lo largo de la ejecución. Si entiende más o menos el concepto (cualquier cosa UTFW)??
Si bien, no es la manera en la que nos enseñaron a programar, tiene cierto sentido pensar de esta manera. Si lo vemos desde el punto de vista del modelado y el aprendizaje de cierto dominio de una aplicación, tiene más sentido empezar a utilizar objetos especificos y concretos para ir prototipando e ir entendiendo el dominio de la aplicación que estamos desarrollando, que clasificar o abstraer antes de aprender o entender el dominio???
Actualmente trabajamos de esa manera, primero abstraemos para aprender un dominio, no digo que esté mal, pero tambien creo que deberiamos incorporar algunos conceptos de Prototype Oriented Programming. En el seminario se mostraron ejemplos de este paradigma, con Self y con JavaScript.

Basicamente eso es lo que me quedó del seminario... hubo una pregunta interesante sobre las desventajas que tiene esto, y obviamente la respuesta de alguna manera dió algunas pistas de por que no es usado y ampliamente extendido. Ya que una vez que entendemos y aprendemos del dominio ya estamos capacitados para clasificar/abstraer/jerarquizar los objetos por lo tanto los prototipos no son tan necesitamos como al principio del aprendizaje/modelado, es aqui donde falla, no hay herramientas para poder pasar de un modelo en prototipos a clases...

Algo interesante que podemos destacar de Ruby es que permite ambos paradigmas de objeto, tanto con clases como prototipos... es probable que con el crecimiento de este lenguaje dinámico se pueda solucionar la falencia de los lenguajes orientados a prototipos.

El disertante (Hernan) comentó que si bien Ruby permite ambas cosas tiene un problema de que este es críptico....

Realmente piensan que Ruby puede ser el lenguaje para utilizar este paradigma?? Que es criptico ;) ?

Libros que toda organización de desarrollo de software debería tener

Estos son los libros "técnicos"que toda organización que desarrolle o mantenga software no puede dejar de tener, básicamente son biblias, todavía no he leido todos pero los que no leí les di una mirada y muchos profesionales me los recomendaron.

Software Architecture in Practice, Second Edition
By Len Bass, Paul Clements, Rick Kazman. Addison Wesley, 2003, ISBN 0-321-15495-9.
Price: $50.99 + Envio a Argentina (en USA es Free)

Evaluating Software Architectures: Methods and Case Studies
By Paul Clements, Rick Kazman, Mark Klein. Addison Wesley Professional. ISBN: 020170482X Price: $50.99 + Envio a Argentina (en USA es Free)

Enterprise Integration Patterns: Designing, Building and Deploying Messaging Solutions
By Gregor Hoppe and Bobby Woolf. Addison Wesley, 2003, ISBN 0-321-20068-3
Price: $39.59 + Envio a Argentina (en USA es Free)

Software Estimation: Demystifying the Black Art. Redmond
By Steve McConnels. Microsoft Press, ISBN: 0-735-60535-1.
Price: $25.19 + Envio a Argentina (en USA es Free)

Domain Driven Design, Tackling Complexity in the Heart of Software
By Eric Evans. Addison Wesley, 2003, ISBN 0-321-12521-5
Price: $43.44 + Envio a Argentina (en USA es Free)

Object Design: Roles, Responsibilities, and Collaborations
By Rebecca Wirfs-Brock, Alan McKean. Addison Wesley. ISBN: 0-201-37943-0
Price: $42.42 + Envio a Argentina (en USA es Free)

Design Patterns: Elements of Reusable Object-Oriented Software
By GoF. Addison Wesley, 1995, ISBN: 0201633612
Price: $39.59 + Envio a Argentina (en USA es Free)

Working Effectively with Legacy Code
By Michael C. Feathers.
Price: $41.49 + Envio a Argentina (en USA es Free)

Refactoring: Improving the Design of Existing Code
by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts
Price: $47.79 + Envio a Argentina (en USA es Free)

The Pragmatic Programmer
By Andrew Hunt, David Thomas
Price: $33.96 + Envio a Argentina (en USA es Free)

Code Complete, 2nd Ed
By Steve McConnels. Microsoft Press.
Price: $32.99 + Envio a Argentina (en USA es Free)

Como se habran dado cuenta no he agregado ninguno de de Java/C#/Ruby ni ninguno de PM o Metodologías, eso lo dejo para otro momento.

Que otro libro agregarían a esta lista??

El Bliki Martin Fowler me pone frenético

Suelo hablar muy bien de Martin Fowler, aprendí/aprendo mucho leyendo de el. Tiene excelentes libros y formidables articulos, pero si hay algo que me pone frenetico es que cada vez que leo el blog/wiki de Martin Fowler es que tengo que terminar leyendo otros 50 post debido a que en vez de llamar a las cosas por su nombre le pone nombre a todo.
No es mala la idea de linkear (al estilo Wiki) para determinadas palabras, pero si a eso le agregas terminos inventados (y ya existentes con otra nomenclartura) por el y que el solo usa, realmente me pone frenetico: vean este ejemplo:

El problema es que todos esos post linkeados a su vez tienen 10 más links...
En fin, de a poquito me voy enojando un poco más de este "guru" del diseño y metodologías. Otra cosa que me pasa con MF es que veo que le cambia los nombres a las cosas, ahora se me viene a la cabeza, IoC por DI, o DSL por Wrokbench Language, que se yo, eso me rompe un poco...
No puedo dejar de decir que es uno de los mejores escritores del software que he leido, y obviamente tiene una visión increible del software y por supuesto, lo voy a seguir leyendo, articulos como "Is design dead", "The new methodology" y "Continuos integration" son una reliquia.

Opinan lo mismo que yo o estoy equivocado?

Era de suponer...le costó un poco a Rational pero ya vino

Hace un año y un poquito más que vengo diciendo que IBM/Rational necesitaba alguna herramienta de Build and Release Management, en los ultimos tiempos muchas organizaciones fueron creciendo en madurez incorporando herramientas como Crouise Control, Maven, Custimizaciones de ANT , etc... pero IBM estaba muy atrasado en el tema, varios proyecto internos de IBM usaban herramientas customizadas para realizar esta tarea tan importante. Pero bueno, finalmente el area de software se dió cuenta que estaba perdiendo una gran parte importante del desarrolo y compró una empresa que tenía una herramienta de Build que parece muy interesante, ahora llamada Rational Build Forge, que tiene features muy interesantes y diferenciadores:

• como la integración con varias herramientas de testeo automático (Test Manager, Robot, Performance, Unit, etc)
• soporta diferentes "Source Control" y "Feature/Change/Defects Items" mas que cualquier otra herramienta de build, lo cual permite la tan importante trazabilidad
  
• Lo que ellos llaman, "Build Acceleration" implementando paralelización de tareas y threads
• Alta granuralidad para manejo de roles, diferencia de lo que es un tester, un build manager, desarrollador, lider, pm, etc.
  

Obviamente estoy obviando todos los features que una herramienta de build y release tiene que tener (automatización, countinous integration, IDE integration, etc). Una de las cosas "interesantes" de todo es que el grafiquito de Rational se sigue incrementando, ahora ya agregaron al Build Manager :)