Virtualización con KVM

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

Amazon S3

http://c2.com/cgi/wiki?GuiPrototypingTools

Herramientas para el prototipado de IU

Listado de herramientas para el prototipado.


* Balsamiq una buena opción para el prototipado low-fi.
* y Mockflow




http://c2.com/cgi/wiki?GuiPrototypingTools

Recursos Ruby

Best Partices Ruby
http://majesticseacreature.com/rbp-book/pdfs/rbp_1-0.pdf

Quick Reference Ruby
http://www.digilife.be/quickreferences/qrc/ruby%20language%20quickref.pdf

Tutrial Ruby
http://akitaonrails.com/files/RubyFacil_071105.pdf

Articulo interesante sobre DSL y ruby

http://talhah.com/Thesis/

Martin Fowler - Introducción a DSL (video y slides)

http://www.infoq.com/presentations/domain-specific-languages

Dos libros sobre dsl

Este está en Safari Books online:

DSL y ruby

Advanced DSLs in Ruby

Martin Fowler.- Language Workbenches: The Killer-App for Domain Specific Languages?

Most new ideas in software developments are really new variations on old ideas. This article describes one of these, the growing idea of a class of tools that I call Language Workbenches - examples of which include Intentional Software, JetBrains's Meta Programming System, and Microsoft's Software Factories.
...
http://www.martinfowler.com/articles/languageWorkbench.html

Katas

Página web en el que se propone un kata por mes y la comunidad sube a github sus soluciones.

http://www.12meses12katas.com/

Uncle Bob

http://www.artima.com/weblogs/index.jsp?blogger=unclebob
http://www.artima.com/weblogs/viewpost.jsp?thread=7588

Summary
As software craftsmen, we have rules. Sometimes we feel bad when the rules mut be broken. They're just rules though. What's important is that we have a moral center, a professional core, that refuses to compromise the quality of our work.

---

As software craftsmen we have rules, disciplines, and practices that we follow 
to help us maintain a high degree of quality and professionalism.  However, 
there are always trade-offs, always considerations, always possibilities. 
Sometimes we abandon a complex test case because we need to finish the task,
and visual inspection or manual testing is sufficient.  Sometimes we fail to
write an acceptance test because it's complicated, and the bang-for-buck is
low.  Sometimes we don't program in pairs, because -- well -- we don't have
a partner nearby, or we're sick of programming with someone else, or the
current task is mechanical.  Sometimes we keep a module checked out for more
than a couple of hours.  Sometimes (damned rarely!) we check in code that
fails to pass all the acceptance tests, or all the unit tests.  

They're just rules, and rules are made to be broken.

Blindly following rules is a fools errand.  We have enough grey matter to
discern when the rules are helpful and when they are not.  We have the
responsibility to continuously measure whether the rules are helpful, or
whether they are not.  

But then -- there's something else.  

Something that is cold and hard, and yet simultaneously hot and blazing.
Something, amidst all the compromise and ambiguity, that is neither
compromised nor ambiguous.  Something that spawns and respawns the rules we
follow, and yet challenges those rules at every turn.  

The still small voice; the angel's trumpet, the grim determination, the
joyous declaration: 

  "I WILL NOT SHIP SHIT."  

 - "I am a professional -- a craftsman!"
  -- "No matter what pressures are on me."
  -- "No matter how I've had to bend the rules."
  -- "No matter what shortcuts I've had to take."
  -- "No matter what the gods, or managers, have done or may do."

  --  --  "I WILL DO THE BEST WORK I CAN POSSIBLY DO."
  --  --  "Anything short of my best is shit."
  --  --  "I _ WILL _  NOT _ SHIP _ SHIT."

For me, at least, this is what it all comes down to.  I find that the rules
of XP help me to achieve this most of the time  -- more of the time than any
other set of rules I have followed.  But rules are rules, and when they get
in the way of this goal, they get set aside.

I do not set the rules aside lightly.  Indeed, when in doubt, I follow them.
When the pressure is on, I follow them.  When the deadline looms, I follow
them.  I try hard not to let fear drive me.

Fear is the mind killer.  It breeds idiocies like:

   "We don't have time to write tests."
   "We don't have time to program in pairs."
   "We don't have time to integrate continuously."
   "We don't have time to automate our acceptance tests."

These idiocies are a siren's song.  Their lure is strong.  Look in their
direction and The Despair begins.  All the rules will fall away.
  
Our core of professional pride is the cure.  That something that is both
cold and hard, yet hot and blazing.  It won't set aside a rule out of fear.
It sets aside a rule when *the rule* will cause you to ship shit.   

Go now, the lesson has ended.

Manfiesto agile vs. artesanía del software

Manifiesto artesanos del software

Como aspirantes a artesanos de software que están elevando los estándares dedesarrollo de software profesional mediante la práctica de ella y ayudar a otros aaprender el oficio. A través de este trabajo hemos llegado a valorar:

Para aquellos que desarrollamos software a medida.
Not only working software,but also well-crafted software 

1. (No hacer simplemente software, sino también hacerlo bien diseñado)
   
2. Not only responding to change,but also steadily adding value
   (No solo dar respuesta al cambio, sino también dar valor añadido continuamente)
   
3. Not only individuals and interactions,but also a community of professionals
   (No solo individuos e iteraciones, sino también una comunidad de profesionales)
   
4. Not only customer collaboration,but also productive partnerships
   (No solo colaboración con los clientes, sino también asociaciones productivas.)

Fuente : Manifesto for software craftsmanship

Manifesto for Agile Software Development

We are uncovering better ways of developing
software by doing it and helping others do it.

Through this work we have come to value:
Individuals and interactions over processes and tools

Working software over comprehensive documentation
Customer collaboration over contract negotiation

Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.

High Availability

SPL

Podcast Software Engineer

www.se-radio.ne


Recursos multimedia:

http://research.google.com/video.html

Agile DSL Development in Ruby

Check out this SlideShare Presentation:

Agile DSL Development in Ruby

View more presentations from elliando dias.

DSL Construction rith Ruby

Una presentación sobre la construcción de DSL con ruby.

DSL Construction rith Ruby

View more presentations from ThoughtWorks.

InfoQ: The State of the DSL Art in Ruby

InfoQ: The State of the DSL Art in Ruby

Introducción a DSL con Ruby

http://www.infoq.com/presentations/vanderburg-state-of-dsl-ruby

Cockburn. The 7 Habits of Highly Successful Samurai, and How That Helps Rubyists

The 7 Habits of Highly Successful Samurai, and How That Helps Rubyists

Después de leer Writing Effective Use Cases tengo un espcial aprecio a Cockburn, aquí lo tenemos hablando de agilismo.

http://confreaks.net/videos/343-rubyweb2010-the-7-habits-of-highly-successful-samurai-and-how-that-helps-rubyists

Ebooks

Dirección web donde bajarse libros:

http://www.feedbooks.com/publicdomain

Descarga de Libros

• Feedbooks (Español e Ingles, gratuitos) [Recomendada]
• ManyBooks.net (Ingles, gratuitos)
• Project Gutenberg(Español e Inglés, gratuitos)
• Libros Dominio Público de Amazon (Inglés, Gratuitos)
• Drinkmalk (Ìnglés, sitio web con muchos libros best-seller gratuitos. Aunque preparada para el iphone, puedes acceder al feed RSS y descargar los libros desde el ordenador)[Recomendada]
• Greylib (enorme repositorio de libros en múltiples idiomas) [Recomendada]
• Casa del libro (Español, pagando)

Buscadores de Libros

• Scribd
• 4Shared(gran repositorio de archivos gratuitos. Posee muchos ebooks si los buscas)
• Just Free Books(buscador de libros que utiliza Google. Muy configurable)

Descarga de libros desde el navegador web del Kindle directamente

A parte de la Kindle Store, podemos descargar libros online desde las siguientes páginas. ¡Ponerlas en los bookmarks de vuestro Kindle!

• Feedbooks

Short introduction to Domain Driven Design & Model Driven Development

Check out this SlideShare Presentation:

Short introduction to Domain Driven Design & Model Driven Development

View more presentations from Jeppe Cramon.

CG2010 Tailored Code Generators

Check out this SlideShare Presentation:

CG2010 Tailored Code Generators

View more presentations from Pedro J. Molina.

CG2010 Introducing MDSD

Presentación de Pedro J. Molina en CG2010

CG2010 Introducing MDSD

View more presentations from Pedro J. Molina.

Code Generation in Agile Projects

5 motivos para hacer fracasar la generación de código y otros para llevarla al éxito.

Code Generation in Agile Projects

View more presentations from Sven Efftinge.

What is Product Line Engineering? How IBM is helping you build smarter p...

Why there is no future for Model Driven Development

He descubierto a Johan den Haan, explica muy bien temas relacionados a MDD.


El blog es http://www.theenterprisearchitect.eu


Una presentación muy buena sobre beneficios y desventajas de MDD y su vinculación con Agile


http://www.theenterprisearchitect.eu/archive/2011/01/25/why-there-is-no-future-for-model-driven-development


Johan den Haan - Why there is no future for Model Driven Development from Johan den Haan on Vimeo.

SPL

Pasos fundamentales para crear un SPL
http://www.softwareproductlines.com/gettingstarted/gettingstarted.html


SPL en el SEI
http://www.sei.cmu.edu/productlines/

Hacia la Cuarta Generacion del Software: Software Product Lines en CM Crossroads

Hacia la Cuarta Generacion del Software: Software Product Lines en CM Crossroads: "Durante algún tiempo se desarrolló una conversación en CM Crossroads sobre Líneas de Producto en Software (SPL, Software Product Lines). Est..."

Code Generation Conference Cambridge UK

The Code Generation conference is recognised as the leading event on the practical applications of Model-Driven Software Development.

This year's conference - Code Generation 2011 - will take place in Cambridge, UK from May 25th-27th

Generación de código

Un libro a leer sobre generación de código "Code Generation in Action".

Las 10 reglas principales sobre generación incluidas en el libro: http://ajlopez.wordpress.com/2008/08/18/top-ten-code-generation-rules/

Dar el debido respeto a la codificación manual

Odie el  código escrito a  mano porque el tiempo de ingeniería es muy valioso, desperdiciar tiempo en  las tareas repetitivas es un delito.El generador debe  optimizar la organización de los activos más valiosos, la creatividad y el entusiasmo del equipo.

Primero escriba el código a mano

Debe entender completamente su framework antes de generar código. Idealmente, debe escribir a mano una gran parte del código de forma significativa y luego usar ese código como base de las plantillas para el generador.

Use un control de versiones
No puedo hacer suficiente hincapié en la importancia de contar con un sistema sólidode control de código fuente.

Realice una decisión meditada sobre el lenguaje de implementación

Las herramientas que utilizamos para construir el generador no tienen por qué ser las mismas herramientas que utiliza para escribir la aplicación. El problema que resuelve el generador es  es completamente diferente del problema a resolver por la aplicación. Por esa razón, usted debe tratar el generador como un proyecto independiente y escoger sus herramientas en consecuencia.

Integre el generador al proceso de desarrollo

El generador es una herramienta para ser utilizada por los ingenieros, por lo que debe encajar en su proceso de desarrollo. 

Incluya avisos 

Su generador siempre debe colocar advertencias en torno a código que genera para que la gente no modifique el código a mano

Hágalo amigable

El hecho de que un generador es una herramienta para programadores no significa que sea 'duro'. El generador debe informar el ingeniero de lo que está haciendo, y qué archivos se ha modificado o creado, y manejar sus errores con una cantidad razonable de decoro. 

Una herramienta que es difícil de usar o que es escamosa será ignorada y sus esfuerzos serán inútiles.

Incluya documentación

Una buena documentación es un punto importante para la venta del generador. La documentación debe ser completa, pero no abrumadora, y debe poner de relieve los puntos clave: lo que el generador es, cómo se instala, cómo se ejecuta y que archivos genera.

La generación es un tema cultural

Educar a sus colegas a través de documentación, seminarios, y reuniones es fundamental para implementar con éxito el generador. La gente es escéptica de las cosas nuevas, y un buen programador es dos veces más escépticos que una persona promedio. Es necesario romper con las preocupaciones y las dudas y hacer hincapié en que ha diseñado el generador para su beneficio.

Mantener el generador

A menos que el generador sea sólo una medida temporal, tendrá que ser mantenido a largo plazo. Su presupuesto debe incluir el tiempo y dinero para el mantenimiento y mejora de ese recurso.

AGILE 2010: Haciendo Realidad la Agilidad por Henrik Kniberg

Keynote impartida por Henrik Kniberg. Henrik es autor de "Scrum y XP desde las trincheras" y de "Kanban vs. Scrum -- Obteniendo lo mejor de ambos", además de ser Certified Scrum Trainer, miembro de la junta directiva de la Agile Alliance, y uno de los máximos divulgadores de la aplicación práctica de las metodologías ágiles internacionalmente.

Video Realizado por el Gabinete de Tele-educación de la Universidad Politécnica de Madrid.

Flow

Un gran libro, que volveré a leer

AGILE 2010: Presente y futuro del agilismo en España