jueves, 31 de marzo de 2011

miércoles, 30 de marzo de 2011

User Stories

Metodología de desarrollo y UPV

La UPV tiene un grupo de trabajo en el desarrollo de una metodología de desarrollo:


http://www.tuneupprocess.com/

¿Por qué no escribir documentación?

Porque no lo van a leer.

TAGRI They Aren't Gonna Read It

http://www.dosideas.com/noticias/metodologias/361-igual-no-lo-van-a-leer.html

Un hilo interesante sobre CU.

http://groups.google.com/group/agile-spain/browse_thread/thread/e6253d01542c2e29

Blog sobre agilismo.

Debería hacer un listado con los blogs que suelo leer... otro más para la tonga.

http://blog.agilmedia.com/

Requerimientos y automatización

No sólo de Xtext viven los DSL


Summary
Bernhard Merkle discusses the various types of DSLs, and compares different language workbenches by using them with the same custom DSL in order to outline the differences between them

http://www.infoq.com/presentations/Textual-Modeling-Tools

domingo, 27 de marzo de 2011

User Stories

Articulos interesentas sobre user stories:
http://scalingsoftwareagility.files.wordpress.com/2009/11/user-story-primer_1.pdf

  • INVEST
  • ¿Cómo definir user stories? Granularidad








http://scalingsoftwareagility.files.wordpress.com/2009/03/agile-porfolio-management-denver-apln-mar-2009.pdf

Libro sobre agilismo y requirimientos.


sábado, 26 de marzo de 2011

The Downfall of Agile Hitler

The Downfall of Agile Hitler



Hitler and Unit Testing

Ruby y Rails

Los tutoriales cada vez son más frikis:

http://tryruby.org
http://www.codeschool.com/courses/rails-for-zombies

Retomando las lecturas de ATDD

Concordion is an open source tool for writing
automated acceptance tests in Java
http://www.concordion.org/Example.html

Robot Framework is a generic test automation framework for acceptance testing and acceptance test-driven development (ATDD).
http://code.google.com/p/robotframework/


Otras herramientas de ATTD
http://www.dosideas.com/wiki/Herramientas_Para_Pruebas_De_Aceptacion

martes, 22 de marzo de 2011

Libros sobre alta disponibilidad y gestión de almacenamiento









Gestión de virtualización con OpenNebula

El otro día me comentaron este software para gestionar entornos virtualizados. Habrá que probarlo.


http://opennebula.org/start

Fully open source (not open core), thoroughly tested, customizable, extensible and with unique features, excellent performance and massive scalability to manage hundreds of thousands of VMs in your cloud or data center infrastructure:

* Private cloud with Xen, KVM and VMware,
* Hybrid cloud (cloudbursting) with Amazon EC2, and other providers through Deltacloud (ecosystem),
* Public cloud exposing Amazon EC2, OGF OCCI and vCloud (ecosystem) APIs… and much more.

Playframework

Un framwork de desarrollo web en Java con sabor a RoR

A web app in 10 minutes using Play framework from zenexity on Vimeo.

Deuda tecnológica

Supongo que a todos nos ha pasado, ¿en qué momento debemos pagar la deuda tecnológica de nuestros proyectos?


http://www.techrepublic.com/blog/programming-and-development/avoid-getting-buried-in-technical-debt/3849
http://en.wikipedia.org/wiki/Technical_debt
http://www.codinghorror.com/blog/2009/02/paying-down-your-technical-debt.html

lunes, 21 de marzo de 2011

InfoQ: Textual DSLs Made Simple


InfoQ: Textual DSLs Made Simple

Virtualización de clientes

La solución de virtualización de clientes de VMWare tiene muy buena pinta.
Lo que más que gusta es que permite el modo offline del servidor.

http://www.vmware.com/products/view/

¿cómo lo harán? ¿Usarán entonces toda la potencia de cliente?


La solución de RedHat basada en KVM está muy bien pero parece que no ofrece esta posibilidad.

http://www.redhat.com/virtualization/rhev/desktop/

domingo, 20 de marzo de 2011

Herramientas DSL

Una herramienta para desarrollo de DSL textuales (no todo va a ser Xtext)


http://www.jetbrains.com/mps/


También está metaedit, pero esta no es textual.
http://www.metacase.com/cases/dsm_examples.html



Próximo libro de Markus Volter

Ya está en el fuego el próximo libro de Markus Volter,

Aquí está disponible la introducción
http://dsl-engineering.org/wiki/bookintro

Toca muchos palos, y hace una buena clasificación de DSL. En particular algo que estaba buscando sobre DSL y requirimientos.

"

DSLs in Requirements Engineering.

A related topic to application domain DSLs is the use of DSLs in the context of requirements engineering. Here, the focus of the languages is not so much on automatic code generation, but rather on precise and checkably complete description of requirements. Traceability into other artifacts is important. Often, the DSLs need to be embedded or otherwise connected to prose text, to integrate them with "classical" requirements approaches.
Examples include a DSL for helping with the trade analysis for satellite construction or pseudo-structured natural language DSLs that imply some formal meaning into domain entities and terms such as should or must."



sábado, 19 de marzo de 2011

Software Factories

Un serie de entradas sobre SF.

http://0x7c00.wordpress.com/2007/08/24/software-factories-introduccion-parte-1/
http://geeks.ms/blogs/lontivero/archive/2007/09/30/software-factories-introducci-243-n-parte-3.aspx
http://geeks.ms/blogs/lontivero/archive/2007/10/02/software-factories-introducci-243-n-parte-4.aspx

Dos libros sobre dsl

Dos libros de DSL de Mannig, con sus capítulos gratis:


Este libro se centra en DSL internos con Ruby, Scala, ...



El otro libro


http://www.manning.com/ghosh/
Explica que es un DSL http://www.manning.com/rahien/Sample1.pdf

Cómo gestionar la evolución de un DSL

Si estás desarrollando DSL, en algún momento tendrás que plantearte cómo será su evolución a lo largo del tiempo.



Escribir buenos DSL

Debemos aprender a escribir buenos DSL. En este articulo nos enseñan a agrupar condiciones (como nos enseñó Cockburn al escribir en CUs)


One of the common mistakes in a DSL is to create one that solve a demo problem and leave it at that.
As a simple example, let us say that we build a DSL to handle order management. Here is a typical scenario that was talked about during development:
when is_preferred_user and order_amount > 500:
 apply_discount 5.precent
Sounds reasonable, right?
Except, that this isn't really a good way to express a business rule. A common business rule usually have a lot more complexity to it. Here is a good example:
when user.payment_method is credit_card and ((order_amount > 500 and order_amount < 1200) or number_of_payments < 4) and 
    user.is_member_of("weekend buy club") and Now.DayOfWeek in (DayOfWeek.Sunday, DayOfWeek.Sutarday) 
    and applied_discounts < 10:
 apply_discount 5.precent
At a glance, what the !@$!# does this rule do?
This is a good example of stagnant DSL. It is no longer being actively developed (easily seen by the use of framework terms such as DayOfWeek), and the complexity is growing unchecked.
This is usually the case when the DSL design has not taken into account new functionality, or when it relies on developers to be able to extend the language when needed. Because it requires developer involvement, it is often easier to patch it by complex conditional rather than express the actual business logic in a readable way.
A good way to avoid that is to incorporate known best practices from the development side into our DSL. In other words, we need to allow encapsulation and extensibility in our DSLs. As a simple example, we can allow the following:
condition weekend_club_member:
 user.is_member_of("weekend club memeber")
condition sale_on_weekend:
 Now.DayOfWeek in (DayOfWeek.Sunday, DayOfWeek.Sutrday)
condition good_payment_option: # yes, I know, bad name, deal with it
 ((order_amount > 500 and order_amount < 1200) or number_of_payments < 4)
And now the condition becomes:
when user.payment_method is credict_card and good_payment_option and sale_on_weekend 
     and weekend_club_member and applied_discounts < 10:
 apply_discount 5.precent
This is important, because it avoid a language rot and provide the facilities to the end user to add abstraction levels.

viernes, 18 de marzo de 2011

Markus Voelter un nuevo faro.

Después de admirar mucho tiempo a Alistair Cockburn por la lectura de su libro "Writting Effective Use Cases", hoy tengo un nuevo faro en lo que se refiere a la ingeniería del software  en el tema de  modelado, DSL y generación de código: Markus Voelter.

Y descubro que es el mismo que el libro "Model Driven Software Development" y tambien lo había escuchado en se-radio.net.




DSL y variabilidad



"Los DSL tienen a establecer la variabilidad dentro de las aplicaciones de un dominio pero no expresan los conceptos éste. Están pensados para generar código no para entender el dominio - Pedro González"




"DSLs aren't for simple use cases. DSLs are for use cases where repetition exists within the problem or solution domains. It's why we create classes with methods (a very simple language expressed as an API), it's why we create XML configuration files, it's why we create content management systems (and metadata management systems), it's why we write little languages and parsers, and why we create languages using visual language toolkits like Microsoft DSL tools, openArchitectureWare and MetaEdit+ . . .
Software product line engineering is about creating a combination of frameworks, re-usable code snippets, DSLs for unbounded variability spaces and configuration managers and feature modelers for bounded variability spaces - often in a structure where ad-hoc custom code can be added for functions that are not worth developing a DSL and an interpreter (framework) or compiler (code generator) for. The trigger point for the effort of developing a DSL providing a ROI depends on the tooling, experience and inclinations of a given developer.
There is no application you can write that I can't generate. There are parts that it may not be worth me generating, but there are patterns of best practices in everything from object modeling to UI design and I think that much more of our skills and best practices can be turned into reusable heuristics than we might like to admit"



Revistas de Pragmatic Programers.

http://www.pragprog.com/magazines

why modeling and code generation are not agile?

http://www.modeldrivensoftware.net/forum/topics/why-modeling-and-code?commentId=2573822%3AComment%3A7911