En estos días estuve bastante ocupado preparando y completando mi charla de física cuántica, así que no avisé con tiempo de estas dos reuniones en Buenos Aires. Hoy martes, tenemos la de Amazon Web Services User Group:
Reunión 31 de Julio: Autoscaling y más
http://www.meetup.com/AWS-User-Group-Buenos-Aires/events/68988052/
Costa Rica 5546, oficinas 301 a 303, Buenos Aires (map)
SELECTED BY: MATIAS BAGINI
Reunión 31 de Julio: AutoScaling y más.
En Costa Rica 5546, oficinas 301 a 303.
19hs. Bienvenida.
19:10hs. Presentación Elance para desarrolladores AWS
19:15hs. Introducción a AutoScaling
19:45hs. Caso AWS: "The Fan Machine Infrastructure and Architecture"
20:30hs. Networking y cierre.
Esta vez cambiaron de lugar, pero no encontré de quienes son las oficinas. El tema es entonces Autoscaling, pero también habrá otros temas.
Y ya comienza Agosto. La gente de Ruby Argentina se han comprometido a hacer un meetup el primer miércoles de cada mes. Así que mañana miércoles hay reunión. El bueno de @inkel envío a la lista de Rubysur:
Quería recordarles e invitarlos al próximo meetup de Ruby Argentina, a
celebrarse el miércoles 1 de agosto a las 18.30h en Urban Station (El
Salvador 4588)
Pedimos por favor que se anoten todos aquellos que deseen participar
en el siguiente formulario, como así mismo proponer charlas o dejarnos
comentarios:
http://goo.gl/RlWm3
Hay como tema propuesto, lógica computacional y lenguaje S. Sería bueno también que se pudiera dar la charla de Ruby y TDD que quedó fuera de horario en la meetup pasada.
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
Este mes estuve trabajando como miembro de un equipo ágil, desarrollando una aplicación privada. Una de las características interesates es que el sistema permite la creación y existencia de entidades del dominio del negecio, aún cuando estén en algún estado “inválido”. El product owner quiere armar un sistema flexible que refleje la realidad del negocio, en vez de uno más estrcito que no permita ese reflejo porque no se cumple alguna regla de negocio. Pero quiere ver también cuáles son las entidades que están en estado “inválido” y por qué. Así que se le muestra (la parte de interfaz de usuario está en ASP.NET MVC) una página con lo que hemos llamado Findings: una lista de mensajes alertando sobre los estados a revisar. Por ejemplo: que tal factura tiene un importe demasiado bajo o que no tiene renglones asociados.
Me gustaría explorar el mode TDD de armar esa característica. Para conseguirlo, necesito un dominio de prueba, y en este post voy a describirlo, simplificado, para tener algo en firme sobre el que implementar los Findings.
Sea una Order. Cada Order tiene uno o más Order Item. Cada Order Item tiene un Product, Quantity, Price (Producto, Cantidad y Precio). Cada Order tiene un Customer (Cliente). Hay reglas de negocio que describen cuáles son los estados “inválidos”. Algunos ejemplos:
- Una Order para un Customer de categoría Y no puede tener un monto total que supere X.
- Una Order debe tener uno o más Order Items.
- Los Order Items deben tener una Cantidad/Quantity > 0.
- Los Order Items deben tener Precio/Price > 0.
- El Producto P debe tener Cantidad > Cantidad Mínima en cada Order Item.
- Producto P tiene un Precio, y cada Order Item que lo incluya no puede tener su Precio < Precio de Producto < 0.80.
- y así…
De esta forma, las Ordenes pueden ser creadas y persistidas sin tener que cumplir con todas las reglas. La Order no es RECHAZADA por el sistema. Solamente que hay páginas para pedir (en cualquier momento) cuáles son los Findings, la lista de las reglas que no se cumplen.
Las reglas de negocio pueden cambiar, y se pueden definir nuevas. No está definido en esta esta etapa del proyecto cómo conseguir esto: puede ser que simplemente agregando código, o escribiendo un DSL (Domain-Specific Languages) de reglas. Por ahora es un tema que no importa. En la aplicación real, el cliente final tiene programadores a disposición, así que la modificación del código sigue siendo una opción aceptable. Bien puede descubrir que 30 reglas bastan, y que no hace falta cambiarlas o se cambian cada 6 meses. Este es un tema a investigar: no siempre crear un DSL de reglas se justifica. En esta versión inicial, las reglas de negocio están en el código, compiladas. En una segunda versión, algunas reglas se aplicarán a algunas órdenes (por ejemplo, a las Orders que tienen clientes de Canadá). El Product Owner quiere tener: Findings por Order, Findings por Producto, Findings por Customer.
En esta serie de post, quiero entonces explorar y mostrar una forma de armar lo pedido, USANDO TDD. Para simplificar el ejemplo, no habrá UI ni persistencia, solamente objetos del dominio, y su grafo de relaciones. Veremos cómo, usando TDD, las reglas y su forma de ejecución van emergiendo desde los casos de uso planteados. Usaré mi cuenta en GitHub para ir compartiendo el código. Será escrito, como la aplicación original, en C#.
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
En este siglo he vuelto a estudiar física, y en particular, física cuántica: su formalismo, modelos, historia, conceptos. Es un tema muy interesante, y cuyo estudio me ha traido muchas satisfacciones. Así que gracias a la gente de @altnethispano (http://altnethispano.org) el sábado que viene, 21 de Julio, a las 18:00 GMT (15 hs acá en Argentina), voy a dar una charla virtual sobre el tema:
La comunidad ALT.NET Hispano (http://altnethispano.org) realizará una VAN sobre Física Cuántica para Desarrolladores de Software, con Angel "Java" López.
Fecha: sábado, 21 de julio de 2012 a las 18:00 hrs. Hora Internacional (GMT/UTC), con una duración aproximada de 2 horas.
Pueden plantear sus comentarios e inquietudes sobre el tema de la reunión en: https://groups.google.com/d/topic/altnet-hispano/lk4vbEpWdJI/discussion
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)
When
Sat Jul 21 3pm – 5pm Buenos Aires
El enlace para asistir es http://bit.ly/VANHispano
La idea es dar una charla para desarrolladores o cualquier persona interesada que no “le asuste” ver una fórmula. Hay mucho libros de divulgación y varios son muy buenos, pero veo que se quedan cortos en explicar lo que es la cuántica porque le “huyen” a poner modelos matemáticos. En la charla veremos (vean que es un temario ambicioso):
- Modelos, Realidad y Ciencia
- Ejemplos ideales de 2 estados
- Estado vs Vector de Estado
- Estado y Vectores de Base
- Covectores, bra-kets, notación de Dirac
- Ejemplos de n-estados
- Estados Estacionarios
- Experimentos que llevaron a esos modelos
- Espín (y algo rápido de espín y estadística)
- Evolución en el tiempo
- Pasaje al límite
- Función de onda
- Operadores
- Hamiltoniano
- Valores Medios
- Algo rápido de historia (Heisenberg, Schrodinger, Dirac, de Broglie, Planck, Einstein)
- Bibliografía (no se si llegamos a comentarla, solamente citarla en la presentación, que quedará pública)
- Cuántica y Relatividad
- Pasando de Mecánica Cuántica a Teoría Cuántica de Campos
- Diagramas de Feynman (no creo que llegue a lagrangianos)
- Perspectiva Actual
Si bien gran parte de la charla es la presentación de la llamada “mecánica cuántica”, la llamé “física cuántica” porque va a tratar de ir un poco más allá de la formulación de Heisenberg y Schrodinger, llegando a Dirac, Feynman y otros.
Algunos post que he publicado sobre el tema, desde:
Física Cuántica (Parte 11) Filtrando Estados Base
Nos leemos!
Angel “Java” Lopez
http://ajlopez.wordpress.com
http://ajlopez.zoomblog.com
http://www.ajlopez.com
http://twitter.com/ajlopez
Es tiempo de escribir las resoluciones para este nuevo mes de Julio de 2012. Ya las había escrito en inglés. Primero, un repaso de las anteriores de Junio:
- Escribir primera versión de SimpleStore, una simple “key value store” para Node.js completo ver repo
- Comenzar SimpleParser, PEG en Javascript completo ver repo
- Dar una charla sobre cómo desarrollar una aplicación usando TDD en .NET completo ver repo
- Preparar una charla sobre Smalltalk Pharo parcial
- Mejorar y publicar SimpleRemote v0.0.1 complete see repo
- Mejorar y publicar AjGenesisNode v0.0.1 pending
- Preparar una charla sobre Ruby y Node.js complete
- Implementar el protocolo cliente de SimpleRemote en otro lenguaje pending
- Nuevos ejemplos para AjFabriqNode pending
Para compensar, estuve trabajando en nuevos items:
- Comenzar SimpleStorm con ejemplos completo ver repo
- Publicar SimpleBroadcast con ejemplo completo ver repo
- Comenzar AjTalkJava completo ver repo
- Comenzar PythonSharp basaod en el anterior AjPython completo ver repo
- Comenzar SimpleTree completo ver repo
Nuevas resoluciones para este mes:
- Continuar AjTalkJava
- Continuar AjLang (sintaxis Ruby en C#)
- Preparar y dar una charla sobre Ruby y Generación de Código
- Mejorar y agregar ejemplo en AjGenesisRuby
- Refactor y ejemplos de AjFabriqNode
- Continuar DartSharp
- Preparar una charla sobre metaprogramación en Ruby
- Refactor, y mejorar ejemplos de AjTalkJs
- Escribir post sobre TDD
Como de costumbre, tópicos interesantes para mí.
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
Ya saben que me importa mucho usar Test-Driven Delopment. Yo diría que es lo primero a adoptar en un desarrollo, como “tecnología nueva”. Pero reconozco que no es fácil a veces transmitir la idea y convencer a la gente de adoptar TDD.
Por ejemplo, hay una idea flotando, que leí hace poco en una lista: “no uso TDD porque el sistema lo tengo que entregar en tres semanas”. Como si TDD fuera algo que alentece. Yo quisiera que se tomara el tiempo, entonces, en cuánto se gasta en la prueba manual o el tiempo que se ocupa usando el “debugger”.
Hace dos semanas, tuve el gusto de dar una charla aplicando TDD desde un “File, New Project”, gracias a la gente de @AltNetHispano (http://altnethispano.org/Inicio.aspx). Lo anuncié en VAN en Alt.NET Hispano: Desarrollando una Aplicación con TDD y pueden ver el resultado en https://github.com/ajlopez/TddOnTheRocks/tree/master/TddApp con commits casi por test. Ese desarrollo fue orientado a terminar en 2 horas, y entonces se mostró cómo por refactor aparecen patrones, para mejorar el código en desarrollo, pero NO APARECEN desde el principio. Al comienzo, TDD brega por el “menor código” que pase el test. Todo mejoramiento de código pasa por refactor. Ese énfasis me hizo dejar algo de lado un tema importante, aunque lo aclaré en la charla: prefiero aplicar TDD escribiendo tests SOBRE CASOS DE USO.
Algo de ese “approach” aparece en la serie de post TDD paso a paso donde se ve cómo se va construyendo el software a partir de un problema planteado por el bueno de @hernanwilkinson. Vean cómo se hace poco diseño de implementación por adelantado: se puede hacer, pero en general con TDD se hace poco o de forma liviana. Los tests nos van guiando qué clases, métodos, estado interno NECESITAMOS debido a que vamos planteando los casos de uso.
En la charla de @AltNetHispano se preguntó: ¿pero qué hacemos si en la primera iteración el cliente/”product owner” nos pide un diagrama de entidad-relación como entregable? Pues bien, respuesta corta: va a ser muy difícil aplicar TDD. Cualquier DER que entreguemos no se basará en casos de uso en concreto, sino que trataremos de “compilar” en nuestra cabeza un modelo POR ADELANTADO de lo que necesitamos. ¿Y eso es problema? No, si NO trabajan ágil y NO usan TDD. ¿Por qué es problema si quieren trabajar ágil y también quieren aplicar TDD? Porque cualquier DER que entreguen será un “dibujo”, algo medio inventado, basado en nuestra capacidad de visualizar qué se necesita SIN HABER planteado un solo caso de uso en concreto. Y hay un problema adicional: ese DER es una “bajada de línea”. En dos semanas más, alguien del equipo comenzará a decir: “no podemos hacer X porque rompemos el DER” y temas parecidos.
Otra bajada de línea aparece con: el “product owner” aparece ya desde el principio con un modelo de datos, de un sistema aún no construido (acepto mejor que venga con una base de datos de un sistema que YA se está usando).
De ahí mi énfasis en usar TDD guiado a su vez por CASOS DE USO. Hace que cada cosa que agregamos (clase, método, estado, entidades, etc…. ) HAGA SU APARICION por haber escrito los tests para un caso de uso. Hace un tiempo me encontré con ideas parecidas de parte de “Uncle Bob” Martin. Les recomiendo lectura de:
No DB
Un párrafo importante:
The center of your application is not the database. Nor is it one or more of the frameworks you may be using. The center of your application are the use cases of your application.
Sigo:
It makes me crazy when I hear a software developer describe his system as a “Tomcat system using Spring and Hibernate using Oracle”. The very wording puts the frameworks and the database at the center.
What do you think the architecture of that system would look like? Do you think you’d find the use cases at the center of the design? Or would you find the source code arranged to fit nicely into the pattern of the frameworks? Would you find business objects that looked suspiciously like database rows? Would the schema and the frameworks pollute everything?
Here’s what an application should look like. The use cases should be the highest level and most visible architectural entities. The use cases are at the center. Always! Databases and frameworks are details! You don’t have to decide upon them up front. You can push them off until later, once you’ve got all the use cases and business rules figured out, written, and tested.
Eso: “una vez que los casos de usos y las reglas de negocio se determinaron/descubrieron, escribieron, y PROBARON”.
A ver, repitan conmigo:
The center of your application are the use cases of your application.
De nuevo, por favor, en serio:
The center of your application are the use cases of your application.
The center of your application are the use cases of your application.
Bien, y ahora, a repetir cada día, frente al espejo:
Databases and frameworks are details!
Si, antes de lavarse los dientes a la mañana repetir:
Databases and frameworks are details!
Databases and frameworks are details!
;-)
Les aseguro que si repiten eso cada día, van a mejorar en sus “skills” de programación, van a mejorar en la calidad del software que engreguen, y van a desarrollar sin tener que pelearse con tecnologías adoptadas por que sí, o porque “era más fácil”.
Recuerden también: “fácil” no es “simple”, y bien puede que lo “fácil” conspire con lo “simple”. Para traer un ejemplo concreto: Rails es “fácil”, permite generar una aplicación web con dos o tres comandos. Ahora, vayan y vean si es “simple” el código.
Les recomiendo leer un “review” de alguna charla de “Uncle Bob” Martin, donde se evalúa lo de más arriba:
The delivery mechanism is an annoying detail
Ahí hay un Tweet de @unclebobmartin
A good architecture allows you to defer framework decisions. A good architecture allows frameworks to act as plugins to the app
Bien, yo diría que las disciplinas ágiles y TDD en particular, permiten también diferir las decisiones. Ese un punto importante. Por ejemplo, en el ejemplo de la charla que mencioné al principio, DIFERI el diseño de la base de datos. Eso permite hacer cambios en las primeras iteraciones, SIN TENER la carga, el peso de la inercia de tener un esquema de tablas, datos cargados, etc.. Pueden ver ese approach en los post:
Escribiendo una aplicación con TDD
Y lean un ejemplo de Ron Jeffries:
http://xprogramming.com/articles/but-we-need-a-database-dont-we/
http://xprogramming.com/articles/see-we-dont-need-a-database-yet/
Si en su equipo todavía hay resistencia a TDD, leer el post de Bob Martin:
http://blog.8thlight.com/uncle-bob/2012/01/11/Flipping-the-Bit.html
En mi charla se mencionó bibliografía. Uno de los libros mencionados fue el
http://www.dirigidoportests.com/el-libro
Les recomiendo leer el ejemplo que los autores describen al principio. Dos programadores, uno usando TDD, y otro trabajando rápido, adoptando frameworks, librerías, todo ya hecho, porque PARECE MAS FACIL, y hasta mejor. Lean el desenlace.
Les puedo comentar un caso, sin dar mucho detalle: en un sistema, había que realizar las tareas A, B, C. Con TDD hubiéramos ido avanzando, tal vez escribiendo un método que invoque a A, B, C, y viendo de revisar, en los tests, los resultados de esas tareas. En vez de eso, se adoptó un “Job Engine”, porque “ya estaba hecho”. Como ese “job engine” funciona dentro de un entorno de tecnología que necesita (usando colas en la nube, monitoreo, etc…), probar que las tareas A, B, C se realicen, es todo un problema. Un año y medio despues, todavía se está analizando por qué algunas tareas se traban en el sitio de producción, o por qué un “job” tarda 15 o más minutos en lanzarse, desde que el pedido se puso en la cola.
Bien, fue un post largo, y espero que haya sido de provecho para alguien. Un resumen:
- Usen TDD guiado por los casos de uso, aceptando lo menos posible “bajadas de línea” sin justificación
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez