https://dosideas.com/wiki/api.php?action=feedcontributions&user=200.115.213.201&feedformat=atomDos Ideas. - Contribuciones del usuario [es]2024-03-28T20:07:03ZContribuciones del usuarioMediaWiki 1.28.2https://dosideas.com/wiki/index.php?title=Scrum&diff=2852Scrum2009-07-31T20:01:32Z<p>200.115.213.201: /* Scrum para el desarrollo de software */</p>
<hr />
<div>[[Category:Scrum]]<br />
Scrum es una metodología para la gestión de proyectos. Es considerada una metodología ágil para el [[Desarrollo Agil De Software]], aún cuando Scrum puede ser aplicado para la administración de proyectos de prácticamente cualquier índole.<br />
<br />
Scrum es un proceso que incluye un conjunto de practicas y roles predefinidos. Los principales [[Roles De Scrum]] son el [[Scrum Master]] el cual se encarga de mantener los procesos y tareas de manera similar a un Project Manager; El [[Dueño Del Producto]] o Product Owner (tambien llamado "Hombre de Negocios") quien representa a los interesados (stakeholders) y es parte de la compañía que solicita el producto; y los [[Miembros Del Equipo De Scrum]] que incluye a los desarrolladores. Es importante destacar que en la práctica se usan los nombres de origen ingles (Ejemplo: Project Manager, en vez de gerente de proyecto).<br />
<br />
Durante cada [[Sprint]] o iteración, un periodo de 2 a 4 semanas decidido por el equipo, el equipo crea un [[Incremento Del Producto]] de un prototipo del software utilizable. Es importante que el prototipo sea funcional, esto quiere decir que compile en primer medida.<br />
<br />
El conjunto de características que se suman en cada iteración provienen del [[Backlog Del Producto]] (o simplemente backlog), el cuales un conjunto de requerimientos de alto nivel que tienen que ser realizados ordenados por prioridad. Qué requerimientos se incluyen en el backlog se determina en la reunión de planificación de cada iteración. Durante esta reunión el Dueño del Producto le informa al equipo de los ítems en el backlog que quiere que sean completados.<br />
<br />
Durante la iteración, nadie esta habilitado a cambiar el backlog, lo que significa que los requerimientos están congelados para esa iteración. Hay muchas buenas implementaciones de sistemas para asistir a un desarrollo de Scrum. Otros prefieren simplemente una pizarra y anotaciones en un "memo". Una de las principales ventajas del método Scrum es que es muy fácil de aprender y requiere un mínimo esfuerzo para empezar a utilizarlo.<br />
<br />
{{curso|url=http://www.dosideas.com/cursos/course/view.php?id=6|nombre=Día a día con Scrum}}<br />
<br />
==Valores==<br />
Scrum es una metodología muy simple en su composición, sin embargo sus fundamentos teóricos y los valores en los que se fundamentan tienen implicaciones que van más allá de la simplicidad de sus componentes. Scrum se basa en la ''sinceridad'', ''transparencia'' y ''compromiso'' de las personas para llevar adelante el proyecto. <br />
<br />
Los valores de Scrum y del manifiesto ágil son el "pegamento" que une a las personas en las reuniones y a través de los documentos y les permite cumplir con sus compromisos día a día, sprint a sprint hasta el éxito del proyecto.<br />
*'''Compromiso''': Estar dispuesto para comprometerse a una meta. La metodología la da a las personas la autoridad que necesitan para cumplir con sus compromisos.<br />
*'''Enfoque''': Haz tu trabajo. Enfoca todos tus esfuerzos y habilidades para trabajar en lo que te comprometiste a hacer. No te preocupes por nada más. Alguien lo hara por ti.<br />
*'''Transparencia / Honestidad''': Scrum mantiene todo acerca del proyecto visible a todos.<br />
*'''Respeto''': Los individuos estamos formados por nuestros orígenes y nuestras experiencias. Es importante respetar las diferentes a las personas del equipo y sus formas de pensar.<br />
*'''Coraje''': Tener el coraje para comprometerse, actuar, ser honesto y esperar respeto.<br />
<br />
==Scrum para el desarrollo de software==<br />
Scrum nada dice sobre cómo llevar adelante una iteración. Es por esto que Scrum se complementa perfectamente con [[Extreme Programming]] y [[Test Driven Development]], prácticas que suelen usarse en conjunto a Scrum para llevar adelante un [[Desarrollo Agil De Software]].<br />
<br />
==Ver también==<br />
* [[Proceso De Desarrollo Con Scrum]]<br />
* [[Herramientas Para Planificacion Colaborativa]]<br />
* [[Metodologia Agil En Una Organizacion En Cascada]]<br />
* [[Interrupciones En Scrum]]<br />
* [http://es.wikipedia.org/wiki/Scrum Scrum en la Wikipedia]<br />
* [http://www.navegapolis.net/content/view/694/61/ Flexibilidad con Scrum (libro gratuito)]<br />
* [http://www.navegapolis.net/content/view/816/61/ Gestión de Proyectos (libro gratuito)]<br />
* [http://www.infoq.com/minibooks/scrum-xp-from-the-trenches Scrum and XP from the trenches (libro gratuito en inglés)]<br />
* [http://geeks.ms/blogs/jorge/archive/2007/05/09/explicando-scrum-a-mi-abuela.aspx Explicando Scrum a mi abuela]<br />
* [http://www.chuidiang.com/ood/metodologia/scrum.php Breve explicación de Scrum]<br />
* [http://www.offshoreagile.com/resources/presentations/rootsofscrum/ Video conferencia The Roots of Scrum]</div>200.115.213.201https://dosideas.com/wiki/index.php?title=Integracion_Continua&diff=2724Integracion Continua2009-06-11T22:51:47Z<p>200.115.213.201: /* Contexto */</p>
<hr />
<div>La integración contínua es un concepto que surge a partir de la idea de realización de builds diarios. El modelo ideal de integración contínua permite que la construcción y ejecución de pruebas sea realizada cada vez que el código cambia o es enviado al software de [[Control De Versiones]]. <br />
<br />
Existe una gran cantidad de [[Herramientas Para Integracion Continua]] en el mercado.<br />
<br />
==Contexto==<br />
<br />
Un proyecto de desarrollo de software con [[Control De Versiones]] y [[Automatizacion De Build]] posee a necesidad de integrar el código con frecuencia para reducir los riesgos de problemas en la integración final del proyecto.<br />
<br />
==Problema==<br />
<br />
Integración de código en el trabajo de todo el equipo despúes de ciclos largos (semanas o meses) se torna una sesión de carga a defectos de integración.<br />
Integraciones poco frecuentes pueden generar atrasos en el cronograma y problemas de calidad en el producto.<br />
Sin integraciones frecuentes no es posible certificar diariamente la estabilidad del producto.<br />
<br />
==Fuerzas==<br />
<br />
* Los problemas de integración se deben detectar idealmente cuando son insertados en el código que puede generarlos.<br />
* Los desarrolladores no poseen el hábito de hacer check-in de código con frecuencia.<br />
* La compilación de código se puede demorar y tornarse un impidimento para la construcción e integración continua del código.<br />
<br />
==Solución==<br />
<br />
Utilice una herramienta que permita realizar la integración contínua del código (al menos una vez por día).<br />
Adopte un proceso que torne los resultados de la herramienta cruciales para avalar el estado del proyecto.<br />
<br />
==Raciocinio==<br />
<br />
La integración contínua es un concepto que surge a partir de la idea de realización de builds diarios con pruebas de humo.<br />
El modelo ideal de integración contínua permite que la construcción y ejecución de pruebas de humo sea realizada cada vez que el código cambia o es enviado al software de control de versiones.<br />
<br />
El proceso de build diario minimiza los riesgos de integración porque los problemas son identificados continuamente.<br />
También reduce el riesgo de baja calidad de código, pues un conjunto de pruebas básico permite que las funcionalidades principales del software sean continuamente avaladas.<br />
<br />
Grandes empresas desarrolladores de software como Microsoft, Netscape, IBM, Oracle utilizan este proceso de integración continua diaria en sus principales proyectos.<br />
<br />
El proceso de integración continua se hace efectivo cuando el build es generado con éxito.<br />
En el caso que el build no sea generado debido a problemas, la prioridad del equipo pasa a la corrección de los defectos.<br />
Normalmente el error en un build ocurre cuando este no compila o no pasa las pruebas básicas automatizadas.<br />
<br />
El proceso de integración continua funciona de la siguiente manera:<br />
<br />
* Los desarrolladores del equipo hacen modificaciones en el código fuente, compilan y ejecutan las pruebas unitarias automatizadas y hacen el check-in (o commit) del código en la línea activa del desarrollo en la herramienta de control de versiones.<br />
* La herramienta de integración continua de acuerdo a ciertos períodos de tiempo (se recomienda colocar períodos cortos menores a cuatro horas) verifica si nuevo código se ha colocado en la línea activa del software de control de versiones.<br />
* Si es así, la herramienta de integración continua extrae todo el código fuente y compila en el servidor isolado que tiene por objetivo generar builds limpios.<br />
* Si compila, la herramienta de integración continua ejecuta otras tareas que pueden ser definidas por la herramienta de build como: compilar y ejecutar pruebas unitarias, pruebas de aceptación, generar información de las pruebas, de la cobertura y de análisis estático de código.<br />
* La herramienta de Integración Continua actualiza los datos de la página Web del proyecto con todos los resultados de la ejecución del build y con todos los fuentes alterados y con los datos de que se hizo en cada iteración.<br />
* La herramienta envía mensajes (por email, page, MSN, etc) para el equipo informando el resultado del proceso de build durante la integración continua.<br />
<br />
==Contexto Resultante==<br />
<br />
El proyecto posee una herramienta de integración continua que ejecuta automáticamente los builds al mismo tiempo que ocurren las modificaciones en el código.<br />
<br />
El [[Control De Versiones]], la [[Automatizacion De Build]] y la [[Integracion Continua]] se tornan fundamentales para la ejecución continua y automatizada de [[Automatizacion De Pruebas Unitarias]], [[Automatizacion De Pruebas De Aceptacion]], [[Automatizacion De Metricas De Producto]] y la generacion de [[Radiadores De Informacion]].<br />
<br />
<br />
<br />
==Patrones Relacionados==<br />
<br />
* [[Control De Versiones]]<br />
* [[Automatizacion De Build]]<br />
* [[Automatizacion De Pruebas Unitarias]]<br />
* [[Automatizacion De Pruebas De Aceptacion]]<br />
* [[Automatizacion De Metricas De Producto]]<br />
* [[Radiadores De Informacion]]<br />
<br />
==Ver también==<br />
* [[Herramientas Para Integracion Continua]]<br />
* [http://ivanator.wordpress.com/2009/01/12/montando-un-entorno-integracion-continua-hudson-ant-svn-netbeans/ Tutorial para integrar Hudson, NetBeans, Ant y SVN]<br />
<br />
==Reconocimientos==<br />
<br />
* (BERCZUK e APPLETON, 2002)<br />
* (CLARK, 2004)<br />
* (COCKBURN, 2004a)<br />
* (CUSUMANO e YOFFIE, 1998)<br />
* (CUSUMANO e SELBY, 1996)<br />
* (DUVALL, 2007)<br />
* (FOGEL, 2005)<br />
* (FOWLER e FOEMMEL, 2006)<br />
* (MCCONNELL, 1996b)<br />
* (RICHARDSON e GWALTNEY, 2005)<br />
* (SCHUH, 2005)</div>200.115.213.201https://dosideas.com/wiki/index.php?title=Luke_Lucene_Index_Toolbox&diff=2722Luke Lucene Index Toolbox2009-06-05T22:57:49Z<p>200.115.213.201: </p>
<hr />
<div>Luke es una práctica herramienta de desarrollo y diagnóstico para índices [[Apache Lucene]]. Luke accede a los índices de [[Apache Lucene]] ya creados y permite mostrar y modificar los datos de diversas maneras:<br />
* navegar los documentos por número o por término<br />
* ver documentos / copiar documentos al portapapeles<br />
* ver la lista de los términos más frecuentes<br />
* realizar búsquedas y navegar los resultados<br />
* analizar los resultados de una búsqueda<br />
* eliminar documentos del índice<br />
* editar los campos de un documento<br />
* optimizar índices<br />
* comprobar los tokens generados en un texto cualquiera usando distintos analizadores<br />
<br />
==Ver también==<br />
* [[Apache Lucene]]<br />
* [http://www.getopt.org/luke/ Web oficial de Luke]</div>200.115.213.201https://dosideas.com/wiki/index.php?title=OVal&diff=2688OVal2009-05-08T22:40:50Z<p>200.115.213.201: </p>
<hr />
<div>OVal es un framework pragmático y extensible para validar cualquier tipo de objetos [[Java]] (y no sólo JavaBeans).<br />
<br />
Se pueden declarar restricciones usando anotaciones (@NotNull, @MaxLength, etc), POJOs y XML. También se pueden crear restricciones personalizadas, usando clases Java o expresiones en lenguajes de scripting, como JavaScript, Goovy, BeanShell, OGNL o MVEL.<br />
<br />
Además de validaciones a nivel de atributos, OVal permite implementar el [[Diseño Por Contrato]], aplicando restricciones a métodos usando la técnica de AOP a través de AspectJ. De esta manera se pueden validar argumentos de un método en tiempo de ejecución.<br />
<br />
==Características==<br />
OVal permite: <br />
<br />
* validar objetos de forma simple a demanda<br />
* especificar restricciones para atributos de una clase, y para métodos getter<br />
* validar objetos basándose en ciertas anotaciones de EJB3 JPA (como ser todos los campos que necesitan un valor no-nulo)<br />
* configurar las restricciones a través de anotaciones, POJOs y/o archivos <br />
* expresar restricciones usando lenguajes de scripting como Groovy, BeanShell y JavaScript<br />
* crear restricciones personalizadas de forma simple<br />
* desarrollar nuevos mecanismos para configurar restricciones<br />
<br />
===OVal y el Diseño por Contratos===<br />
<br />
OVal nos permite implementar un [[Diseño Por Contrato]] de manera simple, ya que nos brinda mucha funcionalidad que caracteriza al DbC: <br />
<br />
* especificar restricciones para los parámetros de un constructor que se verifican automáticamente cuando se invoca al constructor (precondición)<br />
* especificar restricciones para los parámetros de un método que se verifican automáticamente cuando se invoca al método (precondición)<br />
* requerir cierto estado en un objeto antes de invocar al método (precondición)<br />
* forzar la validación del objeto luego de haber creado al objeto (invariante)<br />
* forzar la validación del objeto antes/después de invocar un método del objeto (invariante)<br />
* especificar restricciones para el valor de retorno de un método que se comprueba automáticamente luego de que se ejecuta el método (postcondición)<br />
* requerir un estado determinado en el objeto luego de la invocación a un método (postcondición)<br />
<br />
==Ver también==<br />
* [[Diseño Por Contrato]]<br />
* [http://oval.sourceforge.net/ Página principa de OVal]<br />
* [http://www.dosideas.com/java/562-diseno-por-contrato-con-oval-y-spring.html Introducción a OVal y Spring]</div>200.115.213.201https://dosideas.com/wiki/index.php?title=OVal&diff=2687OVal2009-05-08T22:40:19Z<p>200.115.213.201: </p>
<hr />
<div>OVal es un framework pragmático y extensible para validar cualquier tipo de objetos Java (y no sólo JavaBeans).<br />
<br />
Se pueden declarar restricciones usando anotaciones (@NotNull, @MaxLength, etc), POJOs y XML. También se pueden crear restricciones personalizadas, usando clases Java o expresiones en lenguajes de scripting, como JavaScript, Goovy, BeanShell, OGNL o MVEL.<br />
<br />
Además de validaciones a nivel de atributos, OVal permite implementar el [[Diseño Por Contrato]], aplicando restricciones a métodos usando la técnica de AOP a través de AspectJ. De esta manera se pueden validar argumentos de un método en tiempo de ejecución.<br />
<br />
==Características==<br />
OVal permite: <br />
<br />
* validar objetos de forma simple a demanda<br />
* especificar restricciones para atributos de una clase, y para métodos getter<br />
* validar objetos basándose en ciertas anotaciones de EJB3 JPA (como ser todos los campos que necesitan un valor no-nulo)<br />
* configurar las restricciones a través de anotaciones, POJOs y/o archivos <br />
* expresar restricciones usando lenguajes de scripting como Groovy, BeanShell y JavaScript<br />
* crear restricciones personalizadas de forma simple<br />
* desarrollar nuevos mecanismos para configurar restricciones<br />
<br />
===OVal y el Diseño por Contratos===<br />
<br />
OVal nos permite implementar un [[Diseño Por Contrato]] de manera simple, ya que nos brinda mucha funcionalidad que caracteriza al DbC: <br />
<br />
* especificar restricciones para los parámetros de un constructor que se verifican automáticamente cuando se invoca al constructor (precondición)<br />
* especificar restricciones para los parámetros de un método que se verifican automáticamente cuando se invoca al método (precondición)<br />
* requerir cierto estado en un objeto antes de invocar al método (precondición)<br />
* forzar la validación del objeto luego de haber creado al objeto (invariante)<br />
* forzar la validación del objeto antes/después de invocar un método del objeto (invariante)<br />
* especificar restricciones para el valor de retorno de un método que se comprueba automáticamente luego de que se ejecuta el método (postcondición)<br />
* requerir un estado determinado en el objeto luego de la invocación a un método (postcondición)<br />
<br />
==Ver también==<br />
* [[Diseño Por Contrato]]<br />
* [http://oval.sourceforge.net/ Página principa de OVal]<br />
* [http://www.dosideas.com/java/562-diseno-por-contrato-con-oval-y-spring.html Introducción a OVal y Spring]</div>200.115.213.201https://dosideas.com/wiki/index.php?title=OVal&diff=2686OVal2009-05-08T22:39:57Z<p>200.115.213.201: /* OVal y el Diseño por Contratos */</p>
<hr />
<div>OVal es un framework pragmático y extensible para validar cualquier tipo de objetos Java (y no sólo JavaBeans).<br />
<br />
Se pueden declarar restricciones usando anotaciones (@NotNull, @MaxLength, etc), POJOs y XML. También se pueden crear restricciones personalizadas, usando clases Java o expresiones en lenguajes de scripting, como JavaScript, Goovy, BeanShell, OGNL o MVEL.<br />
<br />
Además de validaciones a nivel de atributos, OVal permite implementar el Diseño por Contratos, aplicando restricciones a métodos usando la técnica de AOP a través de AspectJ. De esta manera se pueden validar argumentos de un método en tiempo de ejecución.<br />
<br />
==Características==<br />
OVal permite: <br />
<br />
* validar objetos de forma simple a demanda<br />
* especificar restricciones para atributos de una clase, y para métodos getter<br />
* validar objetos basándose en ciertas anotaciones de EJB3 JPA (como ser todos los campos que necesitan un valor no-nulo)<br />
* configurar las restricciones a través de anotaciones, POJOs y/o archivos <br />
* expresar restricciones usando lenguajes de scripting como Groovy, BeanShell y JavaScript<br />
* crear restricciones personalizadas de forma simple<br />
* desarrollar nuevos mecanismos para configurar restricciones<br />
<br />
===OVal y el Diseño por Contratos===<br />
<br />
OVal nos permite implementar un [[Diseño Por Contrato]] de manera simple, ya que nos brinda mucha funcionalidad que caracteriza al DbC: <br />
<br />
* especificar restricciones para los parámetros de un constructor que se verifican automáticamente cuando se invoca al constructor (precondición)<br />
* especificar restricciones para los parámetros de un método que se verifican automáticamente cuando se invoca al método (precondición)<br />
* requerir cierto estado en un objeto antes de invocar al método (precondición)<br />
* forzar la validación del objeto luego de haber creado al objeto (invariante)<br />
* forzar la validación del objeto antes/después de invocar un método del objeto (invariante)<br />
* especificar restricciones para el valor de retorno de un método que se comprueba automáticamente luego de que se ejecuta el método (postcondición)<br />
* requerir un estado determinado en el objeto luego de la invocación a un método (postcondición)<br />
<br />
==Ver también==<br />
* [[Diseño Por Contrato]]<br />
* [http://oval.sourceforge.net/ Página principa de OVal]<br />
* [http://www.dosideas.com/java/562-diseno-por-contrato-con-oval-y-spring.html Introducción a OVal y Spring]</div>200.115.213.201https://dosideas.com/wiki/index.php?title=OVal&diff=2685OVal2009-05-08T22:39:40Z<p>200.115.213.201: /* Ver también */</p>
<hr />
<div>OVal es un framework pragmático y extensible para validar cualquier tipo de objetos Java (y no sólo JavaBeans).<br />
<br />
Se pueden declarar restricciones usando anotaciones (@NotNull, @MaxLength, etc), POJOs y XML. También se pueden crear restricciones personalizadas, usando clases Java o expresiones en lenguajes de scripting, como JavaScript, Goovy, BeanShell, OGNL o MVEL.<br />
<br />
Además de validaciones a nivel de atributos, OVal permite implementar el Diseño por Contratos, aplicando restricciones a métodos usando la técnica de AOP a través de AspectJ. De esta manera se pueden validar argumentos de un método en tiempo de ejecución.<br />
<br />
==Características==<br />
OVal permite: <br />
<br />
* validar objetos de forma simple a demanda<br />
* especificar restricciones para atributos de una clase, y para métodos getter<br />
* validar objetos basándose en ciertas anotaciones de EJB3 JPA (como ser todos los campos que necesitan un valor no-nulo)<br />
* configurar las restricciones a través de anotaciones, POJOs y/o archivos <br />
* expresar restricciones usando lenguajes de scripting como Groovy, BeanShell y JavaScript<br />
* crear restricciones personalizadas de forma simple<br />
* desarrollar nuevos mecanismos para configurar restricciones<br />
<br />
===OVal y el Diseño por Contratos===<br />
<br />
OVal nos permite implementar un Diseño por Contratos de manera simple, ya que nos brinda mucha funcionalidad que caracteriza al DbC: <br />
<br />
* especificar restricciones para los parámetros de un constructor que se verifican automáticamente cuando se invoca al constructor (precondición)<br />
* especificar restricciones para los parámetros de un método que se verifican automáticamente cuando se invoca al método (precondición)<br />
* requerir cierto estado en un objeto antes de invocar al método (precondición)<br />
* forzar la validación del objeto luego de haber creado al objeto (invariante)<br />
* forzar la validación del objeto antes/después de invocar un método del objeto (invariante)<br />
* especificar restricciones para el valor de retorno de un método que se comprueba automáticamente luego de que se ejecuta el método (postcondición)<br />
* requerir un estado determinado en el objeto luego de la invocación a un método (postcondición)<br />
<br />
==Ver también==<br />
* [[Diseño Por Contrato]]<br />
* [http://oval.sourceforge.net/ Página principa de OVal]<br />
* [http://www.dosideas.com/java/562-diseno-por-contrato-con-oval-y-spring.html Introducción a OVal y Spring]</div>200.115.213.201https://dosideas.com/wiki/index.php?title=Java&diff=2316Java2009-03-29T20:53:50Z<p>200.115.213.201: /* Ejecuciones batch y programadas */</p>
<hr />
<div>Java es un lenguaje de programación, aunque también se suele hacer referencia con este nombre a toda una plataforma para el desarrollo de aplicaciones. Hay un buen [http://es.wikipedia.org/wiki/Java_%28Sun%29 resumen de Java en la wikipedia].<br />
<br />
Al desarrollar un sistema se suele basar en una [[Arquitectura De Software]] para crear los componentes.<br />
<br />
Java se caracteriza por una enorme cantidad de proyectos libres.<br />
<br />
== Algunas tecnologías Java ==<br />
=== Frameworks de base===<br />
* [[Spring Framework]]<br />
* [[Terracotta]]<br />
* [[EJB]]<br />
* [[JAAS]]<br />
<br />
===Acceso a datos===<br />
* [[Hibernate]]<br />
* [[Apache Lucene]]<br />
<br />
===Frameworks de presentación===<br />
* [[Struts]]<br />
* [[JSF]]<br />
* [[JSTL]]<br />
* [[GWT]]<br />
<br />
===Mensajeria===<br />
* [[JMS]]<br />
<br />
===Web Services===<br />
* [[Web Service]]<br />
* [[Web Service Con Spring]]<br />
<br />
===Ejecuciones batch y programadas===<br />
* [[Quartz]]<br />
* [[Spring Batch]]<br />
<br />
===Cuestiones generales de Java===<br />
* [[Fechas En Java]]<br />
* [[Numeros En Java]]<br />
* [[Serializacion De Objetos En Java]]<br />
* [[Log4J]]<br />
* [[Cache De Objetos Java]]<br />
* [[Exportacion Hacia Archivos]]</div>200.115.213.201https://dosideas.com/wiki/index.php?title=Java&diff=2315Java2009-03-29T20:53:34Z<p>200.115.213.201: /* Tecnologías Java */</p>
<hr />
<div>Java es un lenguaje de programación, aunque también se suele hacer referencia con este nombre a toda una plataforma para el desarrollo de aplicaciones. Hay un buen [http://es.wikipedia.org/wiki/Java_%28Sun%29 resumen de Java en la wikipedia].<br />
<br />
Al desarrollar un sistema se suele basar en una [[Arquitectura De Software]] para crear los componentes.<br />
<br />
Java se caracteriza por una enorme cantidad de proyectos libres.<br />
<br />
== Algunas tecnologías Java ==<br />
=== Frameworks de base===<br />
* [[Spring Framework]]<br />
* [[Terracotta]]<br />
* [[EJB]]<br />
* [[JAAS]]<br />
<br />
===Acceso a datos===<br />
* [[Hibernate]]<br />
* [[Apache Lucene]]<br />
<br />
===Frameworks de presentación===<br />
* [[Struts]]<br />
* [[JSF]]<br />
* [[JSTL]]<br />
* [[GWT]]<br />
<br />
===Mensajeria===<br />
* [[JMS]]<br />
<br />
===Web Services===<br />
* [[Web Service]]<br />
* [[Web Service Con Spring]]<br />
<br />
===Ejecuciones batch y programadas===<br />
* [[Quartz]]<br />
<br />
===Cuestiones generales de Java===<br />
* [[Fechas En Java]]<br />
* [[Numeros En Java]]<br />
* [[Serializacion De Objetos En Java]]<br />
* [[Log4J]]<br />
* [[Cache De Objetos Java]]<br />
* [[Exportacion Hacia Archivos]]</div>200.115.213.201https://dosideas.com/wiki/index.php?title=Java_Community_Process&diff=2314Java Community Process2009-03-29T20:52:39Z<p>200.115.213.201: Página creada con 'El Proceso de la Comunidad Java, o Java Community Process, establecido en 1998, es un proceso formalizado el cual permite a las partes interesadas a involucrarse en la definici...'</p>
<hr />
<div>El Proceso de la Comunidad Java, o Java Community Process, establecido en 1998, es un proceso formalizado el cual permite a las partes interesadas a involucrarse en la definición de futuras versiones y características de la plataforma [[Java]].<br />
<br />
El proceso JCP conlleva el uso de Java Specification Request (JSR), las cuales son documentos formales que describen las especificaciones y tecnologías propuestas para que sean añadidas a la plataforma Java. Las revisiones publicas formales de JSRs son controladas antes de que los JSR se conviertan en final y sean votados por el Comité Ejecutivo JCP. Un JSR final suministra una implementación de referencia la cual da una implementación libre de la tecnología en código fuente y un Kit de Compatibilidad de Tecnología para verificar la especificación de la API.<br />
<br />
El JCP mismo está descrito por un JSR. Desde 2006, la versión actual de JCP en uso es 2.6 como se describe por JSR 215.<br />
<br />
A finales del 2008, el JCP está compuesto por más de 1200 miembros, todos ellos empresas punteras en el sector tecnológico y del desarrollo de software.<br />
<br />
== Ver también ==<br />
* [http://www.jcp.org/ Página del Java Community Process]<br />
* [http://es.wikipedia.org/wiki/Java_Community_Process Java Community Process en la Wikipedia]</div>200.115.213.201https://dosideas.com/wiki/index.php?title=Inter_Portlet_Communication&diff=2313Inter Portlet Communication2009-03-29T20:50:22Z<p>200.115.213.201: </p>
<hr />
<div>Inter Portlet Communication (IPC) o Comunicación Entre Portlets es la capacidad de los portlets que comparten una misma página de comunicarse entre sí independientemente de que estén en el mismo módulo o incluso desarrollados con las mismas herramientas.<br />
<br />
== Formas de comunicación ==<br />
<br />
La comunicación entre los portles puede ocurrir de tres maneras diferentes:<br />
* Server Side (del lado del servidor)<br />
* Asynchronous Server Side (del lado del servidor en forma asincrónica)<br />
* Client Side (del lado del cliente navegador)<br />
<br />
=== Server Side ===<br />
<br />
En este caso la comunicación se produce enteramente del lado del servidor entre las fases de "Process Action" y "Render". Luego de iniciada la fase de Process Action los portlets pueden dejar información en un lugar común a todos los portlets administrado por el portal. Al entrar en la etapa de "Render" los portlets pueden utilizar esta información para mostrar diferente información.<br />
<br />
Otra forma de comunicarlos del lado del servidor es que el portal invoque métodos de los portlets de destino de los mensajes antes de la fase de render. Esto posibilita que los portlets de destino de los mensajes puedan emitir nuevos mensajes para otros portlets.<br />
<br />
Todos los mensajes deben quedar resueltos antes de iniciarse la fase de Render.<br />
<br />
=== Asynchronous Server Side ===<br />
<br />
Los portlets se comunican entre sí a través del servidor pero fuera del ciclo de Request-Response. Envían un pedido asincrónico (ej: Ajax)y producen un cambio. El portal debe comunicar ese cambio a los otros portles que deben estar haciendo una consulta periódica en forma asincrónica o utilizando alguna tecnología tipo COMET.<br />
<br />
=== Client Side ===<br />
<br />
Esta es una comunicación "liviana" que no involucra comunicación con el servidor por lo que no cambia el estado del portlet ni cambia la información en el servidor.<br />
Un ejemplo podría ser un portlet que sirve como "control remoto" de lo que se visualiza en otro. Al hacer click en un botón del control remoto puede esconderse o mostrarse una sección del otro portlet.<br />
<br />
Puede combinarse con Asynchronous Server Side para refrescar la información del portlet de destino del mensaje.<br />
<br />
Una implementación típica es a través de llamadas de Javascript que se comunican a través del navegador como si fuese una única página en html.<br />
<br />
== IPC en JSR 286 ==<br />
<br />
En la especificación 2.0 de Portlets se agregan dos formas de realizar IPC. Ambas son del lado del servidor y son las únicas formas estandarizadas de realizar IPC al momento de la release de la JSR 286.<br />
<br />
=== Shared Render Parameters ===<br />
<br />
Esta forma de implementarlo es a través de poner disponible para los portles la posibilidad de hacer visibles para otros portles ciertos parámetros render..<br />
<br />
=== Events ===<br />
<br />
Para la versión 2.0 de la especificación de Portlets se agregó una nueva fase entre la de "Process Action" y "Render" llamada "Process Events" y se establece un mecanismo para que los portlets puedan publicar eventos y suscribirse a los mismos.<br />
<br />
El encargado de recolectar los eventos publicados y redistribuirlos es el portal.<br />
<br />
Los eventos pueden publicarse durante la fase de "Process Action" y "Process Events" permitiendo que durante el procesamiento de un evento se puedan publicar nuevos eventos.<br />
<br />
Todos los eventos se procesarán antes de comenzar con la fase de "Render".<br />
<br />
Los eventos se publican a través del método setEvent de la clase ActionResponse y pueden ser procesados tanto en el método processEvents de la interfaz Portlet o anotando métodos con la anotación @ProcessEvent y especificando a que evento responderá el método. Este último es preferible ya que evita tener que identificar que evento se produjo dentro del cuerpo del método.<br />
<br />
== Ver también ==<br />
* [[Eventos De JSR 286]]<br />
* [[JSR 286]] - Java Portlet Specification V2.0<br />
* [[Portlet Con JSF]]<br />
* [[JSF Portlet Bridge]]</div>200.115.213.201https://dosideas.com/wiki/index.php?title=Joomla&diff=2312Joomla2009-03-28T23:57:04Z<p>200.115.213.201: </p>
<hr />
<div>Joomla es un [[Administrador De Contenidos]] web, de [[Software Libre]]<br />
<br />
Joomla permite la gestión artículos, noticias, encuestas, usuarios y más. Es sumamente extensible, y cuanta con una enorme comunidad que crea diversos componentes para agregarle funcionalidad.<br />
<br />
Joomla está está escrito en PHP, y funciona con MySQL, PostgreSQL y otras [[Base De Datos]].<br />
<br />
Dos Ideas está armado sobre un Joomla 1.5.x, MySQL como base de datos, y Apache como web server.<br />
<br />
== Ver también ==<br />
* [[Administrador De Contenidos]]<br />
* [http://www.joomla.org Web oficial de Joomla]</div>200.115.213.201https://dosideas.com/wiki/index.php?title=Ant&diff=1577Ant2009-02-11T00:46:00Z<p>200.115.213.201: </p>
<hr />
<div>[[Ant]] es una herramienta de build de [[Software Libre]] especializada en construir proyectos Java. [[Ant]] utiliza archivos XML para expresar las instrucciones de ejecución de build.<br />
Ella posee una gran variedad de tareas que permiten la realización de actividades como generación de pruebas unitarias, publicación de información, entre otras.<br />
<br />
Algunos ejemplos de tareas pueden ser:<br />
<br />
* Prepare -> Realiza la creación de directorios que contendrán los ejecutables.<br />
* Compile -> Compila el código fuente del producto.<br />
* Instrument -> Instrumenta el código para permitir la generación de información de cobertura de código.<br />
* Compile-test -> Compila el código de pruebas unitarias automatizadas.<br />
* Test -> Ejecuta la batería de pruebas unitarias automatizadas, genera la información en HTML de las pruebas ejecutadas con éxito y con falla y genera la información en HTMl de la cobertura de código.<br />
* [[PMD]] -> Ejecuta la generación de información de análisis estática de código.<br />
* Javadoc -> Ejecuta la generación de documentación de las clases en base a los comentarios en el código fuente.<br />
* Run -> Ejecuta el software.<br />
* Clean -> Realiza la limpieza de los directorios que contienen los ejecutables.<br />
* Jar -> Realiza el empaquetado del software para que pueda se utilizado en producción.<br />
<br />
El script de build puede ser ejecutado de diversas maneras y con múltiples opciones.<br />
En el caso de línea de comando, por ejemplo "ant test pmd javadoc jar", todas las secciones del archivo XML serán ejecutadas.<br />
<br />
Ant puede ser utilizado para realizar la implantación de una aplicación JEE Web en producción.<br />
Un ejemplo de una sección que haría eso sería el siguiente:<br />
<code xml><br />
<target name="deploy"><br />
<deploy url="${tomcat.manager.url}"<br />
username="${tomcat.manager.username}"<br />
password="${tomcat.manager.password}"<br />
path="/${webap.name}"<br />
war="file:${warfile.path}" /><br />
</target><br />
</code><br />
<br />
==Ver también==<br />
* [[Automatizacion De Build]]<br />
* [[Maven]]<br />
* [http://ant.apache.org/ Web oficial de Ant]<br />
* [http://www.dosideas.com/java/391-automatizacion-de-despliegues-ino-mas-dolores-de-cabeza.html Patrones para la automatización de despliegues]</div>200.115.213.201https://dosideas.com/wiki/index.php?title=Ant&diff=1576Ant2009-02-11T00:45:35Z<p>200.115.213.201: /* Ver también */</p>
<hr />
<div>[[Ant]] es una herramienta de build de [[Software Libre]] especializada en construir proyectos Java. [[Ant]] utiliza archivos XML para expresar las instrucciones de ejecución de build.<br />
Ella posee una gran variedad de tareas que permiten la realización de actividades como generación de pruebas unitarias, publicación de información, entre otras.<br />
<br />
Algunos ejemplos de tareas pueden ser:<br />
<br />
* Prepare -> Realiza la creación de directorios que contendrán los ejecutables.<br />
* Compile -> Compila el código fuente del producto.<br />
* Instrument -> Instrumenta el código para permitir la generación de información de cobertura de código.<br />
* Compile-test -> Compila el código de pruebas unitarias automatizadas.<br />
* Test -> Ejecuta la batería de pruebas unitarias automatizadas, genera la información en HTML de las pruebas ejecutadas con éxito y con falla y genera la información en HTMl de la cobertura de código.<br />
* [[PMD]] -> Ejecuta la generación de información de análisis estática de código.<br />
* Javadoc -> Ejecuta la generación de documentación de las clases en base a los comentarios en el código fuente.<br />
* Run -> Ejecuta el software.<br />
* Clean -> Realiza la limpieza de los directorios que contienen los ejecutables.<br />
* Jar -> Realiza el empaquetado del software para que pueda se utilizado en producción.<br />
<br />
El script de build puede ser ejecutado de diversas maneras y con múltiples opciones.<br />
En el caso de línea de comando, por ejemplo "ant test pmd javadoc jar", todas las secciones del archivo XML serán ejecutadas.<br />
<br />
Ant puede ser utilizado para realizar la implantación de una aplicación JEE Web en producción.<br />
Un ejemplo de una sección que haría eso sería el siguiente:<br />
<target name="deploy"><br />
<deploy url="${tomcat.manager.url}"<br />
username="${tomcat.manager.username}"<br />
password="${tomcat.manager.password}"<br />
path="/${webap.name}"<br />
war="file:${warfile.path}" /><br />
</target><br />
<br />
==Ver también==<br />
* [[Automatizacion De Build]]<br />
* [[Maven]]<br />
* [http://ant.apache.org/ Web oficial de Ant]<br />
* [http://www.dosideas.com/java/391-automatizacion-de-despliegues-ino-mas-dolores-de-cabeza.html Patrones para la automatización de despliegues]</div>200.115.213.201https://dosideas.com/wiki/index.php?title=Cobertura&diff=1575Cobertura2009-02-11T00:44:45Z<p>200.115.213.201: /* Ver también */</p>
<hr />
<div>[[Cobertura]] es una herramienta de [[Java]] libre para calcular el porcentaje de código accedido por las pruebas. Puede ser usada para identificar cuales partes de su código [[Java]] carece de cobertura de pruebas. Se basa en [[JCoverage]].<br />
<br />
==Características==<br />
<br />
* Se puede ejecutar desde [[Ant]] o desde linea de comando.<br />
* Instrumenta los bytecode de [[Java]] después que este ha sido compilado.<br />
* Puede generar reportes en [[HTML]] or [[XML]].<br />
* Muestra el porcentaje de líneas y ramas cubiertas de cada clase, cada paquete, y en todo el proyecto.<br />
* Muestra el McCabe [[Complejidad Ciclomatica]] de cada clase, y el promedio de la [[Complejidad Ciclomatica]] para cada paquete y para todo el producto.<br />
* Puede ordenar los resultados en [[HTML]] por nombre de clase, porcentaje de líneas cubiertas, porcentaje de ramas cubiertas, etc. Y puede ordenar en forma ascendente o descendente.<br />
<br />
<br />
==Ver también==<br />
* [[Herramientas Para Metricas De Producto]]<br />
* [http://cobertura.sourceforge.net/ Web oficial de Cobertura]<br />
* [http://ivanator.wordpress.com/2009/02/07/cobertura-con-netbeans-y-hudson/ Tutorial para integrar Cobertura, NetBeans y Hudson]</div>200.115.213.201https://dosideas.com/wiki/index.php?title=Fluir&diff=1573Fluir2009-02-05T02:04:46Z<p>200.115.213.201: /* Ver también */</p>
<hr />
<div>[[Fluir]] (o "flujo", o "zona"), en psicología es un estado de operación en el cual una persona está completamente inmersa en lo que está haciendo, sientiendo un foco energizante, involucramiento total, y éxito en el proceso de la actividad. El concepto fue propuesta por el psicólogo Mihály Csíkszentmihályi, y hoy en día es utilizado en diversos campos. <br />
<br />
== Componentes ==<br />
Se identifican los siguientes componentes que acompañan a una experiencia de Fluir: <br />
# Objetivos claros (se conocen los resultados esperados y las reglas, los objetivos son alcanzables y están alineados con las habilidades y capacidades de la persona).<br />
# Concentración y foco, un alto grado de concentración en un campo limitado de atención (una persona haciendo una actividad va a ttener la oportunidad de enfocarse y sumergirse profundamente en ella). <br />
# Pérdida del sentido de consciencia propia, se mezclan la acción y la atención.<br />
# Pérdida del sentido del tiempo, se altera la experiencia subjetiva del tiempo.<br />
# Feedback directo e inmediato (son evidentes el éxito y el fracaso en el transcurso de la actividad, por lo que se puede ajustar el comportamiento según se necesite). <br />
# Balance entre el nivel de habilidad y el desafio (la actividad no es ni muy facil ni muy dificil). <br />
# Sensación de control personal sobre la situación o la actividad.<br />
# La actividad es satisfactoria por si misma, por lo que no hay esfuerzo en la acción.<br />
# La persona se compenetra totalmente en la actividad, el foco y la atención se reducen a la actividad en si misma. <br />
<br />
== Flujo grupal ==<br />
Hay varias formas por las cuales un grupo puede trabajar junto de manera que cada miembro individual logre Fluir. Las características de estos grupos son: <br />
* Organización espacial creativa: sillas, paredes para pegar cosas, gráficos pero sin tablas; el trabajo se realiza en movimiento.<br />
* Diseño de salón de juegos: gráficos para mostrar información, gráficos de flujo, resumen de proyectos, locura (aquí las "cosas locas" también tienen su lugar), lugar segur (aquí todos pueden decir lo que sino sólo sería pensamiento), pared de resultados, temas abiertos.<br />
* Trabajo organizado y paralelo. <br />
* Foco en un objetivo grupal.<br />
* Avances por sobre lo existente (prototipado).<br />
* Incremento de la eficiencia a través de la visualización.<br />
* La existencia de diferencias entre los participantes representa una oportunidad, en vez de un obstáculo.<br />
<br />
== Ver también ==<br />
* [[Juegos Agiles]]<br />
* [http://en.wikipedia.org/wiki/Flow_(psychology) Fluir en la Wikipedia]</div>200.115.213.201https://dosideas.com/wiki/index.php?title=Hudson&diff=1572Hudson2009-02-05T00:38:21Z<p>200.115.213.201: /* Ver también */</p>
<hr />
<div>Hudson es un software para la gestión y [[Automatizacion De Build]], permitiendo también la creación de un ambiente de [[Integracion Continua]].<br />
<br />
Algunos de sus características mas interesantes son:<br />
<br />
* De forma diferente a [[CruiseControl]], toda la configuración se hace a través de la aplicación Web y no a través de archivos XML.<br />
* Cada build puede tener un link con la información HTML de [[JUnit]] e información de cobertura de código y anásis estático.<br />
* Posee integración con una buena variedad de software de control de versiones.<br />
* Posee integración conlas siguientes herramientas de build; [[Ant]], [[Maven]], archivos batch o shell.<br />
* Su facilidad de instalación y configuración es un gran beneficio para proyectos de pequeño y medio tamaño que quieren iniciar rápidamente un proceso de integración continua y gestión automatizada de builds.<br />
* Extensión de la herramienta a través de plugins. Actualmente se cuentan con plugins de [[JIRA]], [[findbugs]], [[Plot]], [[Polarion]], [[Trac]], [[Clover]], [[PMD]], [[Checkstyle]], [[Cobertura]] entre otros.<br />
<br />
==Ver también==<br />
* [[Herramientas Para Integracion Continua]]<br />
* [https://hudson.dev.java.net/ Web oficial de Hudson]<br />
* [http://hudson.gotdns.com/wiki/display/HUDSON/Plugins Plugins para Hudson]<br />
* [http://ivanator.wordpress.com/2009/01/12/montando-un-entorno-integracion-continua-hudson-ant-svn-netbeans/ Tutorial para integrar Hudson, NetBeans, Ant y SVN]</div>200.115.213.201https://dosideas.com/wiki/index.php?title=Herramientas_Para_Integracion_Continua&diff=1571Herramientas Para Integracion Continua2009-02-05T00:37:56Z<p>200.115.213.201: </p>
<hr />
<div>Existen diversos productos en el mercado para la [[Integracion Continua]]. La mayoria cuentan con una interfaz web que muestra el estado de los proyectos, ultimas corridas, e informes gráficos de diversos tipos.<br />
<br />
* [[Hudson]]<br />
* [[Luntbuild]]<br />
* [[CruiseControl]]<br />
* [[AntHill]]<br />
* [[Continuum]]<br />
<br />
==Ver también==<br />
* [[Integracion Continua]]</div>200.115.213.201https://dosideas.com/wiki/index.php?title=Integracion_Continua&diff=1570Integracion Continua2009-02-05T00:36:06Z<p>200.115.213.201: /* Ver también */</p>
<hr />
<div>La integración contínua es un concepto que surge a partir de la idea de realización de builds diarios. El modelo ideal de integración contínua permite que la construcción y ejecución de pruebas sea realizada cada vez que el código cambia o es enviado al software de [[Control De Versiones]]. <br />
<br />
Existe una gran cantidad de [[Herramientas Para Integracion Continua]] en el mercado.<br />
<br />
==Contexto==<br />
<br />
Un proyecto de desarrollo de software con [[Control De Versiones]] y [[Automatizacion De Build]] posee la necesidad de integrar el código con frecuencia para reducir los riesgos de problemas en la integración final del proyecto.<br />
<br />
==Problema==<br />
<br />
Integración de código en el trabajo de todo el equipo despúes de ciclos largos (semanas o meses) se torna una sesión de carga a defectos de integración.<br />
Integraciones poco frecuentes pueden generar atrasos en el cronograma y problemas de calidad en el producto.<br />
Sin integraciones frecuentes no es posible certificar diariamente la estabilidad del producto.<br />
<br />
==Fuerzas==<br />
<br />
* Los problemas de integración se deben detectar idealmente cuando son insertados en el código que puede generarlos.<br />
* Los desarrolladores no poseen el hábito de hacer check-in de código con frecuencia.<br />
* La compilación de código se puede demorar y tornarse un impidimento para la construcción e integración continua del código.<br />
<br />
==Solución==<br />
<br />
Utilice una herramienta que permita realizar la integración contínua del código (al menos una vez por día).<br />
Adopte un proceso que torne los resultados de la herramienta cruciales para avalar el estado del proyecto.<br />
<br />
==Raciocinio==<br />
<br />
La integración contínua es un concepto que surge a partir de la idea de realización de builds diarios con pruebas de humo.<br />
El modelo ideal de integración contínua permite que la construcción y ejecución de pruebas de humo sea realizada cada vez que el código cambia o es enviado al software de control de versiones.<br />
<br />
El proceso de build diario minimiza los riesgos de integración porque los problemas son identificados continuamente.<br />
También reduce el riesgo de baja calidad de código, pues un conjunto de pruebas básico permite que las funcionalidades principales del software sean continuamente avaladas.<br />
<br />
Grandes empresas desarrolladores de software como Microsoft, Netscape, IBM, Oracle utilizan este proceso de integración continua diaria en sus principales proyectos.<br />
<br />
El proceso de integración continua se hace efectivo cuando el build es generado con éxito.<br />
En el caso que el build no sea generado debido a problemas, la prioridad del equipo pasa a la corrección de los defectos.<br />
Normalmente el error en un build ocurre cuando este no compila o no pasa las pruebas básicas automatizadas.<br />
<br />
El proceso de integración continua funciona de la siguiente manera:<br />
<br />
* Los desarrolladores del equipo hacen modificaciones en el código fuente, compilan y ejecutan las pruebas unitarias automatizadas y hacen el check-in (o commit) del código en la línea activa del desarrollo en la herramienta de control de versiones.<br />
* La herramienta de integración continua de acuerdo a ciertos períodos de tiempo (se recomienda colocar períodos cortos menores a cuatro horas) verifica si nuevo código se ha colocado en la línea activa del software de control de versiones.<br />
* Si es así, la herramienta de integración continua extrae todo el código fuente y compila en el servidor isolado que tiene por objetivo generar builds limpios.<br />
* Si compila, la herramienta de integración continua ejecuta otras tareas que pueden ser definidas por la herramienta de build como: compilar y ejecutar pruebas unitarias, pruebas de aceptación, generar información de las pruebas, de la cobertura y de análisis estático de código.<br />
* La herramienta de Integración Continua actualiza los datos de la página Web del proyecto con todos los resultados de la ejecución del build y con todos los fuentes alterados y con los datos de que se hizo en cada iteración.<br />
* La herramienta envía mensajes (por email, page, MSN, etc) para el equipo informando el resultado del proceso de build durante la integración continua.<br />
<br />
==Contexto Resultante==<br />
<br />
El proyecto posee una herramienta de integración continua que ejecuta automáticamente los builds al mismo tiempo que ocurren las modificaciones en el código.<br />
<br />
El [[Control De Versiones]], la [[Automatizacion De Build]] y la [[Integracion Continua]] se tornan fundamentales para la ejecución continua y automatizada de [[Automatizacion De Pruebas Unitarias]], [[Automatizacion De Pruebas De Aceptacion]], [[Automatizacion De Metricas De Producto]] y la generacion de [[Radiadores De Informacion]].<br />
<br />
<br />
<br />
==Patrones Relacionados==<br />
<br />
* [[Control De Versiones]]<br />
* [[Automatizacion De Build]]<br />
* [[Automatizacion De Pruebas Unitarias]]<br />
* [[Automatizacion De Pruebas De Aceptacion]]<br />
* [[Automatizacion De Metricas De Producto]]<br />
* [[Radiadores De Informacion]]<br />
<br />
==Ver también==<br />
* [[Herramientas Para Integracion Continua]]<br />
* [http://ivanator.wordpress.com/2009/01/12/montando-un-entorno-integracion-continua-hudson-ant-svn-netbeans/ Tutorial para integrar Hudson, NetBeans, Ant y SVN]<br />
<br />
==Reconocimientos==<br />
<br />
* (BERCZUK e APPLETON, 2002)<br />
* (CLARK, 2004)<br />
* (COCKBURN, 2004a)<br />
* (CUSUMANO e YOFFIE, 1998)<br />
* (CUSUMANO e SELBY, 1996)<br />
* (DUVALL, 2007)<br />
* (FOGEL, 2005)<br />
* (FOWLER e FOEMMEL, 2006)<br />
* (MCCONNELL, 1996b)<br />
* (RICHARDSON e GWALTNEY, 2005)<br />
* (SCHUH, 2005)</div>200.115.213.201https://dosideas.com/wiki/index.php?title=Transacciones_Con_Spring&diff=1546Transacciones Con Spring2009-01-30T22:08:29Z<p>200.115.213.201: /* Ver también */</p>
<hr />
<div>[[Spring Framework]] permite configurar transacciones en forma declarativa. De esta forma, la manipulación de transacciones queda establecida en archivos de configuración, sin generar ningún impacto en el código.<br />
<br />
==Transacciones en Spring==<br />
<br />
En Spring cualquier bean puede ser transaccional. La transaccionalidad se declara por método. En ningún momento se utiliza explícitamente JTA, sino que Spring inyecta funcionalidad de acuerdo a ciertas reglas (similares a las de EJB).<br />
<br />
===Rollback de transacciones===<br />
<br />
Por default, una transacción falla solamente cuando el método tira una unchecked exception (las que no se declaran, heredan de RuntimeException). Cuando una transacción falla, se realiza un rollback.<br />
<br />
Noten que, por lo tanto, las excepciones de negocio no realizan un rollback (declaradas en el "throws" del método). Es decir, pese a que se lance una excepción de negocio, igualmente se hará un commit de la transacción. Este comportamiento puede cambiarse en la configuración, como veremos más adelante.<br />
<br />
==Configuración==<br />
<br />
Spring 2.x introduce una forma extensible de agregar tags en los archivos de configuración. Así, existen distintas extensiones que se pueden agregar a la configuración de Spring, ampliando la funcionalidad.<br />
<br />
Esta configuración se agrega en el encabezado de cada XML de Spring, e indica que schemas utiliza dicho archivo.<br />
<br />
Para la configuración de transacciones usaremos los schemas "aop" y "tx". El encabezado de nuestro archivo entonces queda:<br />
<code xml><br />
<?xml version="1.0" encoding="UTF-8"?><br />
<beans xmlns="http://www.springframework.org/schema/beans"<br />
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"<br />
xmlns:aop="http://www.springframework.org/schema/aop"<br />
xmlns:tx="http://www.springframework.org/schema/tx"<br />
xsi:schemaLocation="<br />
http://www.springframework.org/schema/beans<br />
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd<br />
http://www.springframework.org/schema/tx<br />
http://www.springframework.org/schema/tx/spring-tx-2.0.xsd<br />
http://www.springframework.org/schema/aop<br />
http://www.springframework.org/schema/aop/spring-aop-2.0.xsd"><br />
</beans><br />
</code><br />
<br />
==Pointcuts y Advices==<br />
<br />
Con ese encabezado estamos entonces listos para configurar transacciones. Lo que haremos será declarar todos los objetos que necesitamos sean transaccionales, y luego aplicaremos transacciones a todo un grupo de objetos.<br />
<br />
Es decir, la configuración de transacciones ya no será "por objeto", sino mucho más amplia (por ejemplo, "todos las clases del paquete business").<br />
<br />
Crearemos entonces un [[Pointcut]] que indicará qué clases serán interceptadas para agregar transacción, al cual le agregaremos un [[Advice]]. El advice indicará qué tipo de transacción tendrán las clases interceptadas por el pointcut.<br />
<br />
En la práctica, esto es realmente muy simple:<br />
<code xml><br />
<tx:advice id="txAdvice" transaction-manager="txManager"><br />
<tx:attributes><br />
<tx:method name="buscar*" read-only="true"/><br />
<tx:method name="*"/><br />
</tx:attributes><br />
</tx:advice><br />
<br />
<aop:config><br />
<aop:pointcut id="businessOperation" expression="execution(* com.dosideas.business.*.*(..))"/><br />
<br />
<aop:advisor advice-ref="txAdvice" pointcut-ref="businessOperation"/><br />
</aop:config><br />
<br />
<br />
<bean id="business.PaisBo" class="com.dosideas.business.impl.PaisBoImpl"/><br />
<bean id="business.ProvinciaBo" class="com.dosideas.business.impl.ProvinciaBoImpl"/><br />
<br />
<bean id="business.LocalidadBo" class="com.dosideas.business.impl.LocalidadBoImpl"/><br />
</code><br />
<br />
<br />
Todas las clases de "business.impl" serán interceptadas, y se les aplicará el advice "txAdvice". Este advice indica que los métodos que comienzan con "buscar" son de sólo lectura, y el resto serán transaccionales (de tipo "REQUIRED", que es el default).<br />
<br />
Es posible tambien tener mas de un pointcut:<br />
<code xml><br />
<aop:pointcut id="businessOperation" <br />
expression="execution(* com.dosideas.business.*.*(..)) <br />
and<br />
!execution(* com.dosideas.business.Cliente.guardar(..))"/><br />
<br />
<aop:pointcut id="businessOperationGuardarCliente" <br />
expression="execution(* com.dosideas.business.Cliente.guardar(..))"/><br />
</code><br />
<br />
El pointcut ''businessOperation'' referencia a todas las clases de ''business.impl'', salvo el metodo ''guardar'' de la clase ''com.dosideas.business.Cliente'' (que es referenciado por el pointcut ''businessOperationGuardarCliente'').<br />
<br />
<br />
Noten entonces que la definición de transaccionalidad se escribe una única vez (o por paquete, o como sea más cómodo), y los los BO se declaran luego normalmente.<br />
<br />
===Configurando un Advice===<br />
<br />
Como sabemos, las transacciones realizan un rollback ante una RuntimeException, aunque esto es posible cambiarlo:<br />
<code xml><br />
<tx:advice id="txAdvice" transaction-manager="txManager"><br />
<tx:attributes><br />
<tx:method name="buscar*" read-only="true" rollback-for="ObjetoNoEncontradoException"/><br />
<tx:method name="*"/><br />
</tx:attributes><br />
</tx:advice><br />
</code><br />
<br />
Por otro lado, también es posible cambiar la propagación de las transacciones para determiandos métodos:<br />
<code xml><br />
<tx:advice id="noTxAdvice"><br />
<tx:attributes><br />
<tx:method name="*" propagation="NEVER"/><br />
</tx:attributes><br />
</tx:advice><br />
</code><br />
<br />
==Ver también==<br />
*[[Transacciones En Java]]<br />
*[[Concepto De Transaccion]]<br />
*[[Spring Framework]]<br />
*[http://static.springframework.org/spring/docs/2.0.x/reference/transaction.html Manual de Spring: Capítulo 9]</div>200.115.213.201https://dosideas.com/wiki/index.php?title=Administrador_De_Contenidos&diff=1476Administrador De Contenidos2009-01-06T22:33:37Z<p>200.115.213.201: </p>
<hr />
<div>Un sistema de gestión de contenidos, o Administrador de Contenidos (Content Management System en inglés, abreviado CMS) es un programa que permite crear una estructura de soporte (framework) para la creación y administración de contenidos por parte de los participantes principalmente en páginas web.<br />
<br />
Consiste en una interfaz que controla una o varias bases de datos donde se aloja el contenido del sitio. El sistema permite manejar de manera independiente el contenido y el diseño. Así, es posible manejar el contenido y darle en cualquier momento un diseño distinto al sitio sin tener que darle formato al contenido de nuevo, además de permitir la fácil y controlada publicación en el sitio a varios editores. Un ejemplo clásico es el de editores que cargan el contenido al sistema y otro de nivel superior que permite que estos contenidos sean visibles a todo el público.<br />
<br />
== Operación ==<br />
Un CMS a menudo funciona en el servidor del sitio web. Muchos sistemas proporcionan diferentes niveles de acceso dependiendo del usuario, variando si es el administrador, editor, o creador de contenido. El acceso al CMS es generalmente vía el navegador.<br />
<br />
Los creadores de contenido crean sus documentos en el sistema. Los editores comentan, aceptan o rechazan los documentos. El editor en jefe es responsable por publicar el trabajo en el sitio. El CMS controla y ayuda a manejar cada paso de este proceso, incluyendo las labores técnicas de publicar los documentos a uno o más sitios. En muchos sitios con CMS una sola persona hace el papel de creador y editor, los blogs generalmente funcionan de esta manera.<br />
<br />
== Estandarización ==<br />
Dentro de los portales se han realizado procesos de estandarización encaminados a la homogeneización en las interfaces de programación de los mismos de tal manera que un servicio desarrollado para un portal pueda ejecutarse en cualquier otro portal compatible con el estándar. El objetivo es obtener portales interoperables evitando desarrollo propietarios.<br />
<br />
Las dos iniciativas más importantes son la [[Portlet Specification Api]] JSR-168 y la [[Java Content Repository]] JSR-170.<br />
<br />
== Ver también ==<br />
* [[Portlet Specification Api]]<br />
* [[Joomla]]<br />
* [[Alfresco]]<br />
* [http://es.wikipedia.org/wiki/CMS CMS en la Wikipedia]<br />
* [http://www.opensourcecms.com/ OpenSource CMS - Prueba online de varios CMS ]<br />
* [http://www.cmsmatrix.org/ CMS Matrix - Comparación de CMS ]</div>200.115.213.201https://dosideas.com/wiki/index.php?title=Joomla&diff=1475Joomla2009-01-06T22:33:12Z<p>200.115.213.201: </p>
<hr />
<div>Joomla es un [[Administrador De Contenidos]] web, de [[Software Libre]]<br />
<br />
Joomla permite la gestión artículos, noticias, encuestas, usuarios y más. Es sumamente extensible, y cuanta con una enorme comunidad que crea diversos componentes para agregarle funcionalidad.<br />
<br />
Joomla está está escrito en PHP, y funciona con MySQL, PostgreSQL y otras bases.<br />
<br />
Dos Ideas está armado sobre un Joomla 1.5.x, MySQL como base de datos, y Apache como web server.<br />
<br />
== Ver también ==<br />
* [[Administrador De Contenidos]]<br />
* [http://www.joomla.org Web oficial de Joomla]</div>200.115.213.201https://dosideas.com/wiki/index.php?title=Joomla&diff=1474Joomla2009-01-06T22:30:56Z<p>200.115.213.201: </p>
<hr />
<div>Joomla es un [[Administrador De Contenidos]] web, de [[Software Libre]]<br />
<br />
Joomla permite la gestión artículos, noticias, encuestas y usuarios. Es sumamente extensible, y cuanta con una enorme comunidad que crea diversos componentes para agregarle funcionalidad.<br />
<br />
Joomla está está escrito en PHP, y funciona con MySQL, PostgreSQL y otras bases.<br />
<br />
Dos Ideas está armado sobre un Joomla 1.5.x, MySQL como base de datos, y Apache como web server.<br />
<br />
== Ver también ==<br />
* [[Administrador De Contenidos]]<br />
* [http://www.joomla.org Web oficial de Joomla]</div>200.115.213.201https://dosideas.com/wiki/index.php?title=Retrospectiva_Del_Sprint&diff=1468Retrospectiva Del Sprint2008-12-26T22:19:01Z<p>200.115.213.201: /* Opiniones abiertas */</p>
<hr />
<div>[[Category:Scrum]]<br />
[[Category:Reuniones de Scrum]]<br />
En [[Scrum]], la Retrospectiva del [[Sprint]] es una reunión facilitada por el [[Scrum Master]] en la cual los [[Miembros Del Equipo De Scrum]] discuten el [[Sprint]] que acaba de finalizar, y determinan qué podría cambiarse en el próximo Sprint para que sea más productivo y mejor. La [[Revision Del Sprint]] se focaliza en "Qué" construye el equipo, mientras que la Retrospectiva se centra en "Cómo" están construyendo el sistema.<br />
<br />
Cualquier cosa que afecte cómo el equipo construye software está abierto para discutirse. Esto puede incluir: procesos, prácticas, comunicación, entorno, artefactos y herramientas.<br />
<br />
[[Scrum]] no es una metodología prescriptiva, sino más bien un framework que debe adaptarse apropiadamente para cada proyecto, equipo y circunstancias particulares. La Retrospectiva del Sprint es un mecanismo importante que le permite al equipo evolucionar continuamente y mejorar durante toda la vida del proyecto.<br />
<br />
Es importante que todos tengan la oportunidad de opinar abiertamente (incluyendo al equipo, al [[Dueño Del Producto]] y al [[Scrum Master]]), en un ambiente honesto y constructivo. A menudo puede ayudar conseguir a un facilitador externo que ayude a lograr un mayor efecto de la retrospectiva; este enfoque tiene el beneficio adicional de permitirle al [[Scrum Master]] participar más libremente de la reunión. Un facilitador imparcial es particularmente útil cuando las emociones o relaciones entre los integrantes del equipo no están en su mejor momento.<br />
<br />
==Resumen==<br />
* Las mejoras al proceso se realizan al finalizar cada [[Sprint]]: asegurarse que el equipo mejore continuamente su forma de trabajo.<br />
* La Retrospectiva es un proceso colaborativo entre todos los miembros del equipo, el [[Dueño Del Producto]] y el [[Scrum Master]].<br />
* Todos los miembros del equipo identifican las cosas que salieron bien y aquellas para mejorar.<br />
* El [[Scrum Master]] prioriza las acciones y lecciones aprendidas de acuerdo a la dirección del equipo.<br />
* El Equipo visualiza soluciones para los problemas más importantes. Esto ayuda a aumentar el sentido de auto-administración y confianza del equipo.<br />
* La Retrospectiva ayuda a la formación y unión del equipo, ya que cualquier área de conflicto puede ser tratada.<br />
<br />
== Directiva de una retrospectiva ==<br />
Uno de los principales miedos en las retrospectivas es la sensación de que se esté intentando buscar un "culpable" por los problemas que enfrentó el equipo. Nada más lejos de la intención real de una retrospectiva, que es la mejora continua. <br />
<br />
Por esto, antes de comenzar cada retrospectiva es bueno que el equipo lea en voz alta la siguiente directiva: <br />
<br />
'''"Sin importar lo que descubramos, comprendemos y verdaderamente creemos que todos hicieron el mejor trabajo posible, dado lo que sabían a ese momento, sus capacidades y habilidades, los recursos disponibles, y la situación en general"'''<br />
<br />
Al finalizar un proyectos todos saben mucho más. Naturalmente se van a descubrir decisiones y acciones que desearíamos haber hecho distinto. Este nuevo conocimiento debe ser celebrado, y no usado para avergonzar a las personas. <br />
<br />
==Libros==<br />
Existen libros que hablan sobre las actividades a desarrollarse en las retrospectivas, donde tenemos que recoger datos, información y sugerencias sobre las medidas que deben ser adoptadas en relación con determinados "problemas" que se encontraron anteriormente en el sprint.<br />
<br />
* [http://www.amazon.com/Agile-Retrospectives-Making-Teams-Great/dp/0977616649/ref=sr_1_4?ie=UTF8&s=books&qid=1220238908&sr=8-4 Agile Retrospectives]<br />
* [http://www.amazon.com/Project-Retrospectives-Handbook-Team-Reviews/dp/0932633447/ref=sr_1_1?ie=UTF8&s=books&qid=1220238860&sr=8-1 Project Retrospectives]<br />
* [http://www.amazon.com/Project-Management-Tool-Kit-Techniques/dp/0814408109/ref=sr_1_5?ie=UTF8&s=books&qid=1220238374&sr=8-5 Project Management Toolkit]<br />
*[http://www.amazon.com/Project-Meeting-Facilitator-Facilitation-Meetings/dp/0787987069/ref=sr_1_1?ie=UTF8&s=books&qid=1220238691&sr=1-1 The Project Meeting Facilitator]<br />
<br />
== Formas de hacer una retrospectiva ==<br />
Como buen facilitador de retrospectivas se debe tener muchas opciones para la facilitación de estas sesiones. Técnicas que funcionan bien para un equipo o el tipo de negocio pueden no funcionar bien en lugares con una cultura diferente. Si la única técnica de retrospectiva que sabe es "¿Qué ha ido bien?", "¿Qué podría mejorarse ?"... recuerde que esto se puede mejorar mucho conociendo otras actividades.<br />
<br />
=== Temas en papel ===<br />
Una manera adaptada y simplificada, es que cada miembro del equipo recibe un papel en blanco y define un tema, por lo general algo que debe mejorar en el próximo sprint, según su opinión. <br />
<br />
El facilitador establece 5 minutos para que escriban un poco sobre el tema elegido. Después de este tiempo cada uno de los miembros pasa el papel para el miembro de su derecha, el cual lee sobre el tema sugerido por el colega y escribe sus opiniones sobre este tema por otros 5 minutos ... el ciclo se repite hasta que el papel vuelve a su escritor original. <br />
<br />
Al final, el facilitador de la reunión puede leer lo que se ha escrito sobre cada tema y abrir debates.<br />
<br />
=== Opiniones abiertas ===<br />
Se escriben dos grandes categorías: "Bueno" y "A mejorar". <br />
<br />
En forma de debate abierto, cada miembro del equipo va escribiendo temas en notas adhesivas, y las coloca bajo la categoría correspondiente. Cada vez que se pega una nueva nota, se explica exactamente a qué hace referencia. No se critica la opinión del que escribe, sino que se escucha y se responden dudas que puedan surgir.<br />
<br />
Cuando no surjan más temas, el equipo vota por alguno de los "temas a mejorar". El tema ganador se debate y se proponen "Mejoras concretas" para poder resolver el tema. Luego, de entre todas las posibles mejoras concretas, el equipo vota y selecciona las 2-3 más votadas para implementar en el Sprint que se inicia.<br />
<br />
=== Asociación muda ===<br />
Ver [http://www.dosideas.com/metodologias/364-retrospectiva-por-asociacion-muda.html Retrospectiva por asociación muda]<br />
<br />
== Ver también ==<br />
* [[Scrum]]<br />
* [http://www.dosideas.com/metodologias/363-no-olvidemos-la-esencia-de-una-retrospectiva.html La directiva principal]<br />
* [http://www.dosideas.com/metodologias/364-retrospectiva-por-asociacion-muda.html Diagrama con un formato de retrospectiva]<br />
* [http://www.retrospectives.com/ Sitio dedicado a las Retrospectivas]</div>200.115.213.201https://dosideas.com/wiki/index.php?title=Retrospectiva_Del_Sprint&diff=1467Retrospectiva Del Sprint2008-12-26T22:18:13Z<p>200.115.213.201: /* Ver también */</p>
<hr />
<div>[[Category:Scrum]]<br />
[[Category:Reuniones de Scrum]]<br />
En [[Scrum]], la Retrospectiva del [[Sprint]] es una reunión facilitada por el [[Scrum Master]] en la cual los [[Miembros Del Equipo De Scrum]] discuten el [[Sprint]] que acaba de finalizar, y determinan qué podría cambiarse en el próximo Sprint para que sea más productivo y mejor. La [[Revision Del Sprint]] se focaliza en "Qué" construye el equipo, mientras que la Retrospectiva se centra en "Cómo" están construyendo el sistema.<br />
<br />
Cualquier cosa que afecte cómo el equipo construye software está abierto para discutirse. Esto puede incluir: procesos, prácticas, comunicación, entorno, artefactos y herramientas.<br />
<br />
[[Scrum]] no es una metodología prescriptiva, sino más bien un framework que debe adaptarse apropiadamente para cada proyecto, equipo y circunstancias particulares. La Retrospectiva del Sprint es un mecanismo importante que le permite al equipo evolucionar continuamente y mejorar durante toda la vida del proyecto.<br />
<br />
Es importante que todos tengan la oportunidad de opinar abiertamente (incluyendo al equipo, al [[Dueño Del Producto]] y al [[Scrum Master]]), en un ambiente honesto y constructivo. A menudo puede ayudar conseguir a un facilitador externo que ayude a lograr un mayor efecto de la retrospectiva; este enfoque tiene el beneficio adicional de permitirle al [[Scrum Master]] participar más libremente de la reunión. Un facilitador imparcial es particularmente útil cuando las emociones o relaciones entre los integrantes del equipo no están en su mejor momento.<br />
<br />
==Resumen==<br />
* Las mejoras al proceso se realizan al finalizar cada [[Sprint]]: asegurarse que el equipo mejore continuamente su forma de trabajo.<br />
* La Retrospectiva es un proceso colaborativo entre todos los miembros del equipo, el [[Dueño Del Producto]] y el [[Scrum Master]].<br />
* Todos los miembros del equipo identifican las cosas que salieron bien y aquellas para mejorar.<br />
* El [[Scrum Master]] prioriza las acciones y lecciones aprendidas de acuerdo a la dirección del equipo.<br />
* El Equipo visualiza soluciones para los problemas más importantes. Esto ayuda a aumentar el sentido de auto-administración y confianza del equipo.<br />
* La Retrospectiva ayuda a la formación y unión del equipo, ya que cualquier área de conflicto puede ser tratada.<br />
<br />
== Directiva de una retrospectiva ==<br />
Uno de los principales miedos en las retrospectivas es la sensación de que se esté intentando buscar un "culpable" por los problemas que enfrentó el equipo. Nada más lejos de la intención real de una retrospectiva, que es la mejora continua. <br />
<br />
Por esto, antes de comenzar cada retrospectiva es bueno que el equipo lea en voz alta la siguiente directiva: <br />
<br />
'''"Sin importar lo que descubramos, comprendemos y verdaderamente creemos que todos hicieron el mejor trabajo posible, dado lo que sabían a ese momento, sus capacidades y habilidades, los recursos disponibles, y la situación en general"'''<br />
<br />
Al finalizar un proyectos todos saben mucho más. Naturalmente se van a descubrir decisiones y acciones que desearíamos haber hecho distinto. Este nuevo conocimiento debe ser celebrado, y no usado para avergonzar a las personas. <br />
<br />
==Libros==<br />
Existen libros que hablan sobre las actividades a desarrollarse en las retrospectivas, donde tenemos que recoger datos, información y sugerencias sobre las medidas que deben ser adoptadas en relación con determinados "problemas" que se encontraron anteriormente en el sprint.<br />
<br />
* [http://www.amazon.com/Agile-Retrospectives-Making-Teams-Great/dp/0977616649/ref=sr_1_4?ie=UTF8&s=books&qid=1220238908&sr=8-4 Agile Retrospectives]<br />
* [http://www.amazon.com/Project-Retrospectives-Handbook-Team-Reviews/dp/0932633447/ref=sr_1_1?ie=UTF8&s=books&qid=1220238860&sr=8-1 Project Retrospectives]<br />
* [http://www.amazon.com/Project-Management-Tool-Kit-Techniques/dp/0814408109/ref=sr_1_5?ie=UTF8&s=books&qid=1220238374&sr=8-5 Project Management Toolkit]<br />
*[http://www.amazon.com/Project-Meeting-Facilitator-Facilitation-Meetings/dp/0787987069/ref=sr_1_1?ie=UTF8&s=books&qid=1220238691&sr=1-1 The Project Meeting Facilitator]<br />
<br />
== Formas de hacer una retrospectiva ==<br />
Como buen facilitador de retrospectivas se debe tener muchas opciones para la facilitación de estas sesiones. Técnicas que funcionan bien para un equipo o el tipo de negocio pueden no funcionar bien en lugares con una cultura diferente. Si la única técnica de retrospectiva que sabe es "¿Qué ha ido bien?", "¿Qué podría mejorarse ?"... recuerde que esto se puede mejorar mucho conociendo otras actividades.<br />
<br />
=== Temas en papel ===<br />
Una manera adaptada y simplificada, es que cada miembro del equipo recibe un papel en blanco y define un tema, por lo general algo que debe mejorar en el próximo sprint, según su opinión. <br />
<br />
El facilitador establece 5 minutos para que escriban un poco sobre el tema elegido. Después de este tiempo cada uno de los miembros pasa el papel para el miembro de su derecha, el cual lee sobre el tema sugerido por el colega y escribe sus opiniones sobre este tema por otros 5 minutos ... el ciclo se repite hasta que el papel vuelve a su escritor original. <br />
<br />
Al final, el facilitador de la reunión puede leer lo que se ha escrito sobre cada tema y abrir debates.<br />
<br />
=== Opiniones abiertas ===<br />
Se escriben dos grandes categorías: "Bueno" y "A mejorar". <br />
<br />
En forma de debate abierto, cada miembro del equipo va escribiendo temas en notas adhesivas, y las coloca bajo la categoría correspondiente. Cada vez que se pega una nueva nota, se explica exactamente a qué hace referencia. No se critica la opinión del que escribe, sino que se escucha y se responden dudas que puedan surgir.<br />
<br />
Cuando no surjan más temas, el equipo vota por alguno de los "temas a mejorar". El tema ganador se debate y se proponen "Mejoras concretas" para poder resolver el tema. Luego, de entre todas las posibles mejoras concretas, el equipo vota y selecciona las 2-3 más votadas para implementar en el Sprint que se inicia.<br />
<br />
== Ver también ==<br />
* [[Scrum]]<br />
* [http://www.dosideas.com/metodologias/363-no-olvidemos-la-esencia-de-una-retrospectiva.html La directiva principal]<br />
* [http://www.dosideas.com/metodologias/364-retrospectiva-por-asociacion-muda.html Diagrama con un formato de retrospectiva]<br />
* [http://www.retrospectives.com/ Sitio dedicado a las Retrospectivas]</div>200.115.213.201https://dosideas.com/wiki/index.php?title=Testing_De_Aplicaciones&diff=1352Testing De Aplicaciones2008-12-14T12:48:56Z<p>200.115.213.201: </p>
<hr />
<div>Testear una aplicación es un paso fundamental para asegurar la calidad de la misma. Además, es una actividad central en prácticas de desarrollo como [[Test Driven Development]].<br />
<br />
Existen distintos tipos de pruebas para una aplicación:<br />
* [[Prueba Unitaria]]<br />
* [[Prueba De Integracion]]<br />
* [[Prueba De Aceptacion]]<br />
* [[Prueba De Carga]]<br />
<br />
==Ver también==<br />
* [[Automatizacion De Pruebas Unitarias]]<br />
* [[Automatizacion De Pruebas De Aceptacion]]</div>200.115.213.201https://dosideas.com/wiki/index.php?title=Concordion&diff=1350Concordion2008-12-14T12:45:32Z<p>200.115.213.201: /* Ver también */</p>
<hr />
<div>Concordion es un framework [[Java]] de [[Software Libre]] que permite convertir descripciones en texto común sobre requerimientos en pruebas automatizadas.<br />
<br />
==Los requerimientos==<br />
En Concordion los requerimientos (o pruebas de aceptación) se escriben normalmente en archivos HTML, usando tablas y todos los elementos comunes para darle formato. De esta manera se logran especificaciones muy fáciles de leer y que todos pueden comprender (desde analistas de negocio hasta desarrolladores).<br />
<br />
==Las pruebas==<br />
<br />
A partir del requerimiento en HTML se realizan asociaciones entre el texto y las pruebas (instrumentación del HTML), extrayendo la información valiosa para la prueba automatizada.<br />
<br />
Las pruebas en Concordion son pruebas [[JUnit]].<br />
<br />
== Ver también ==<br />
* [[Herramientas Para Pruebas De Aceptacion]]<br />
* [http://www.concordion.org/ Web oficial de Concordion]</div>200.115.213.201https://dosideas.com/wiki/index.php?title=JBehave&diff=1349JBehave2008-12-14T12:45:15Z<p>200.115.213.201: /* Ver también */</p>
<hr />
<div>JBehave es un framework [[Java]] para mejorar la colaboración entre desarrolladores, QA, analistas de negocio, [[Dueño Del Producto]] y todos los miembros del equipo a través de escenarios automatizados y legibles. <br />
<br />
== Características ==<br />
* Escenarios escritos en texto plano<br />
* Posibilidad de crear múltiples escenarios en un único archivo<br />
* Escenarios pendientes<br />
* Resultados claros y fáciles de leer<br />
* Captura de parámetros de los escenarios<br />
* Conversión de parámetros a objetos propios<br />
* Soporte para múltiples lenguajes y términos de escenarios<br />
* Altamente configurable<br />
* Soporte para [[Maven]]<br />
<br />
==Los escenarios==<br />
La forma de escribir escenarios de JBehave es similar a una [[Historia De Usuario]]. En general, una [[Historia De Usuario]] suele escribirse como: <br />
Como [Rol]<br />
Quiero [Caracteristica]<br />
De manera que reciba [Valor]<br />
<br />
Los escenarios en JBehave se escriben de la siguiente forma: <br />
Given [Contexto]<br />
When [Evento que ocurre]<br />
Then [Salida esperada]<br />
<br />
==Ejemplo==<br />
Vamos a probar un escenario de login. Las clases que intervienen en esto serán: <br />
* '''LoginService''': la clase de negocio bajo prueba<br />
* '''login_exitoso''': un archivo de texto que contiene el escenario<br />
* '''LoginExitoso''': una clase Java que representará al escenario<br />
* '''LoginSteps''': una clase Java que contendrá la lógica de la prueba<br />
<br />
=== LoginService.java ===<br />
Esta será la clase de negocio que probaremos. Tiene un único método ''login'' el cual recibe un usuario y una clave. Si la clave es igual al usuario en mayúsculas devuelve true, sino false. <br />
<br />
<code java><br />
package com.dosideas.business;<br />
<br />
public class LoginService {<br />
<br />
public boolean login(String user, String pass) {<br />
if (user.toUpperCase().equals(pass)) {<br />
return true;<br />
} else {<br />
return false;<br />
}<br />
}<br />
}<br />
</code><br />
<br />
=== login_exitoso ===<br />
Este es el archivo de texto con el escenario. Aquí podremos ir agregando los diferentes escenarios que querramos validar.<br />
Given No estoy logueado<br />
When me logueo como usuario Zim y clave ZIM<br />
Then el login tiene que devolver true<br />
<br />
=== LoginExitoso.java ===<br />
Esta clase extiende a ''org.jbehave.scenario.Scenario'' y se encarga de representar al escenario a utilizar. Lo único que hace es cargar la implementación a usar para realizar las pruebas, en este caso ''LoginSteps''. <br />
<br />
Esta clase tiene que estar junto al archivo de texto ''login_exitoso''.<br />
<br />
Esta clase es un test de [[JUnit]], y será la que ejecutaremos para realizar las pruebas.<br />
<br />
<code java><br />
package com.dosideas.jbehave;<br />
<br />
import org.jbehave.scenario.Scenario;<br />
<br />
public class LoginExitoso extends Scenario {<br />
<br />
public LoginExitoso() {<br />
super(new LoginSteps());<br />
}<br />
}<br />
</code><br />
<br />
=== LoginSteps.java ===<br />
Esta clase contiene la lógica de las pruebas, y es quien realmente asocia los mensajes de los escenarios a código para ejecutar. En esta clase, a través de las anotaciones, se convierte parte del texto en parámetros.<br />
<br />
<code java><br />
package com.dosideas.jbehave;<br />
<br />
import static org.jbehave.Ensure.ensureThat;<br />
import com.dosideas.business.LoginService;<br />
import org.jbehave.scenario.annotations.Given;<br />
import org.jbehave.scenario.annotations.Then;<br />
import org.jbehave.scenario.annotations.When;<br />
import org.jbehave.scenario.steps.Steps;<br />
<br />
public class LoginSteps extends Steps {<br />
<br />
private boolean login;<br />
<br />
@Given("No estoy logueado")<br />
public void logout() {<br />
login = false;<br />
}<br />
<br />
@When("me logueo como usuario $usuario y clave $pass")<br />
public void login(String usuario, String pass) {<br />
LoginService loginService = new LoginService();<br />
login = loginService.login(usuario, pass);<br />
}<br />
<br />
@Then("el login tiene que devolver $loginEsperado")<br />
public void comprobarLogin(String loginEsperado) {<br />
ensureThat(login == Boolean.valueOf(loginEsperado));<br />
}<br />
}<br />
</code><br />
<br />
=== Ejecutamos... ===<br />
La ejecución es como un test [[JUnit]] más, ya que la clase ''LoginExitoso'' es un test JUnit. <br />
<br />
== Ver también ==<br />
* [[Herramientas Para Pruebas De Aceptacion]]<br />
* [http://jbehave.org Web oficial de JBehave]</div>200.115.213.201https://dosideas.com/wiki/index.php?title=Herramientas_Para_Pruebas_De_Aceptacion&diff=1348Herramientas Para Pruebas De Aceptacion2008-12-14T12:44:50Z<p>200.115.213.201: </p>
<hr />
<div>Existen actualmente en el mercado una enorme cantidad de herramientas para realizar las Pruebas de Aceptación.<br />
<br />
* [[Canoo]]<br />
* [[Concordion]]<br />
* [[Fitnesse]]<br />
* [[JBehave]]<br />
* [[JMeter]]<br />
* [[Sahi]]<br />
* [[Selenium]]<br />
* [[SoapUI]]<br />
* [[Watir]]<br />
<br />
==Ver También==<br />
<br />
*[[Automatizacion De Pruebas De Aceptacion]]</div>200.115.213.201https://dosideas.com/wiki/index.php?title=Concordion&diff=1347Concordion2008-12-14T12:41:33Z<p>200.115.213.201: Página nueva: Concordion es un framework Java de Software Libre que permite convertir descripciones en texto común sobre requerimientos en pruebas automatizadas. ==Los requerimientos== En...</p>
<hr />
<div>Concordion es un framework [[Java]] de [[Software Libre]] que permite convertir descripciones en texto común sobre requerimientos en pruebas automatizadas.<br />
<br />
==Los requerimientos==<br />
En Concordion los requerimientos (o pruebas de aceptación) se escriben normalmente en archivos HTML, usando tablas y todos los elementos comunes para darle formato. De esta manera se logran especificaciones muy fáciles de leer y que todos pueden comprender (desde analistas de negocio hasta desarrolladores).<br />
<br />
==Las pruebas==<br />
<br />
A partir del requerimiento en HTML se realizan asociaciones entre el texto y las pruebas (instrumentación del HTML), extrayendo la información valiosa para la prueba automatizada.<br />
<br />
Las pruebas en Concordion son pruebas [[JUnit]].<br />
<br />
== Ver también ==<br />
* [[JBehave]]<br />
* [http://www.concordion.org/ Web oficial de Concordion]</div>200.115.213.201https://dosideas.com/wiki/index.php?title=JBehave&diff=1346JBehave2008-12-14T12:35:50Z<p>200.115.213.201: /* Ver también */</p>
<hr />
<div>JBehave es un framework [[Java]] para mejorar la colaboración entre desarrolladores, QA, analistas de negocio, [[Dueño Del Producto]] y todos los miembros del equipo a través de escenarios automatizados y legibles. <br />
<br />
== Características ==<br />
* Escenarios escritos en texto plano<br />
* Posibilidad de crear múltiples escenarios en un único archivo<br />
* Escenarios pendientes<br />
* Resultados claros y fáciles de leer<br />
* Captura de parámetros de los escenarios<br />
* Conversión de parámetros a objetos propios<br />
* Soporte para múltiples lenguajes y términos de escenarios<br />
* Altamente configurable<br />
* Soporte para [[Maven]]<br />
<br />
==Los escenarios==<br />
La forma de escribir escenarios de JBehave es similar a una [[Historia De Usuario]]. En general, una [[Historia De Usuario]] suele escribirse como: <br />
Como [Rol]<br />
Quiero [Caracteristica]<br />
De manera que reciba [Valor]<br />
<br />
Los escenarios en JBehave se escriben de la siguiente forma: <br />
Given [Contexto]<br />
When [Evento que ocurre]<br />
Then [Salida esperada]<br />
<br />
==Ejemplo==<br />
Vamos a probar un escenario de login. Las clases que intervienen en esto serán: <br />
* '''LoginService''': la clase de negocio bajo prueba<br />
* '''login_exitoso''': un archivo de texto que contiene el escenario<br />
* '''LoginExitoso''': una clase Java que representará al escenario<br />
* '''LoginSteps''': una clase Java que contendrá la lógica de la prueba<br />
<br />
=== LoginService.java ===<br />
Esta será la clase de negocio que probaremos. Tiene un único método ''login'' el cual recibe un usuario y una clave. Si la clave es igual al usuario en mayúsculas devuelve true, sino false. <br />
<br />
<code java><br />
package com.dosideas.business;<br />
<br />
public class LoginService {<br />
<br />
public boolean login(String user, String pass) {<br />
if (user.toUpperCase().equals(pass)) {<br />
return true;<br />
} else {<br />
return false;<br />
}<br />
}<br />
}<br />
</code><br />
<br />
=== login_exitoso ===<br />
Este es el archivo de texto con el escenario. Aquí podremos ir agregando los diferentes escenarios que querramos validar.<br />
Given No estoy logueado<br />
When me logueo como usuario Zim y clave ZIM<br />
Then el login tiene que devolver true<br />
<br />
=== LoginExitoso.java ===<br />
Esta clase extiende a ''org.jbehave.scenario.Scenario'' y se encarga de representar al escenario a utilizar. Lo único que hace es cargar la implementación a usar para realizar las pruebas, en este caso ''LoginSteps''. <br />
<br />
Esta clase tiene que estar junto al archivo de texto ''login_exitoso''.<br />
<br />
Esta clase es un test de [[JUnit]], y será la que ejecutaremos para realizar las pruebas.<br />
<br />
<code java><br />
package com.dosideas.jbehave;<br />
<br />
import org.jbehave.scenario.Scenario;<br />
<br />
public class LoginExitoso extends Scenario {<br />
<br />
public LoginExitoso() {<br />
super(new LoginSteps());<br />
}<br />
}<br />
</code><br />
<br />
=== LoginSteps.java ===<br />
Esta clase contiene la lógica de las pruebas, y es quien realmente asocia los mensajes de los escenarios a código para ejecutar. En esta clase, a través de las anotaciones, se convierte parte del texto en parámetros.<br />
<br />
<code java><br />
package com.dosideas.jbehave;<br />
<br />
import static org.jbehave.Ensure.ensureThat;<br />
import com.dosideas.business.LoginService;<br />
import org.jbehave.scenario.annotations.Given;<br />
import org.jbehave.scenario.annotations.Then;<br />
import org.jbehave.scenario.annotations.When;<br />
import org.jbehave.scenario.steps.Steps;<br />
<br />
public class LoginSteps extends Steps {<br />
<br />
private boolean login;<br />
<br />
@Given("No estoy logueado")<br />
public void logout() {<br />
login = false;<br />
}<br />
<br />
@When("me logueo como usuario $usuario y clave $pass")<br />
public void login(String usuario, String pass) {<br />
LoginService loginService = new LoginService();<br />
login = loginService.login(usuario, pass);<br />
}<br />
<br />
@Then("el login tiene que devolver $loginEsperado")<br />
public void comprobarLogin(String loginEsperado) {<br />
ensureThat(login == Boolean.valueOf(loginEsperado));<br />
}<br />
}<br />
</code><br />
<br />
=== Ejecutamos... ===<br />
La ejecución es como un test [[JUnit]] más, ya que la clase ''LoginExitoso'' es un test JUnit. <br />
<br />
== Ver también ==<br />
* [[Concordion]]<br />
* [http://jbehave.org Web oficial de JBehave]</div>200.115.213.201https://dosideas.com/wiki/index.php?title=JBehave&diff=1345JBehave2008-12-14T12:26:58Z<p>200.115.213.201: </p>
<hr />
<div>JBehave es un framework [[Java]] para mejorar la colaboración entre desarrolladores, QA, analistas de negocio, [[Dueño Del Producto]] y todos los miembros del equipo a través de escenarios automatizados y legibles. <br />
<br />
== Características ==<br />
* Escenarios escritos en texto plano<br />
* Posibilidad de crear múltiples escenarios en un único archivo<br />
* Escenarios pendientes<br />
* Resultados claros y fáciles de leer<br />
* Captura de parámetros de los escenarios<br />
* Conversión de parámetros a objetos propios<br />
* Soporte para múltiples lenguajes y términos de escenarios<br />
* Altamente configurable<br />
* Soporte para [[Maven]]<br />
<br />
==Los escenarios==<br />
La forma de escribir escenarios de JBehave es similar a una [[Historia De Usuario]]. En general, una [[Historia De Usuario]] suele escribirse como: <br />
Como [Rol]<br />
Quiero [Caracteristica]<br />
De manera que reciba [Valor]<br />
<br />
Los escenarios en JBehave se escriben de la siguiente forma: <br />
Given [Contexto]<br />
When [Evento que ocurre]<br />
Then [Salida esperada]<br />
<br />
==Ejemplo==<br />
Vamos a probar un escenario de login. Las clases que intervienen en esto serán: <br />
* '''LoginService''': la clase de negocio bajo prueba<br />
* '''login_exitoso''': un archivo de texto que contiene el escenario<br />
* '''LoginExitoso''': una clase Java que representará al escenario<br />
* '''LoginSteps''': una clase Java que contendrá la lógica de la prueba<br />
<br />
=== LoginService.java ===<br />
Esta será la clase de negocio que probaremos. Tiene un único método ''login'' el cual recibe un usuario y una clave. Si la clave es igual al usuario en mayúsculas devuelve true, sino false. <br />
<br />
<code java><br />
package com.dosideas.business;<br />
<br />
public class LoginService {<br />
<br />
public boolean login(String user, String pass) {<br />
if (user.toUpperCase().equals(pass)) {<br />
return true;<br />
} else {<br />
return false;<br />
}<br />
}<br />
}<br />
</code><br />
<br />
=== login_exitoso ===<br />
Este es el archivo de texto con el escenario. Aquí podremos ir agregando los diferentes escenarios que querramos validar.<br />
Given No estoy logueado<br />
When me logueo como usuario Zim y clave ZIM<br />
Then el login tiene que devolver true<br />
<br />
=== LoginExitoso.java ===<br />
Esta clase extiende a ''org.jbehave.scenario.Scenario'' y se encarga de representar al escenario a utilizar. Lo único que hace es cargar la implementación a usar para realizar las pruebas, en este caso ''LoginSteps''. <br />
<br />
Esta clase tiene que estar junto al archivo de texto ''login_exitoso''.<br />
<br />
Esta clase es un test de [[JUnit]], y será la que ejecutaremos para realizar las pruebas.<br />
<br />
<code java><br />
package com.dosideas.jbehave;<br />
<br />
import org.jbehave.scenario.Scenario;<br />
<br />
public class LoginExitoso extends Scenario {<br />
<br />
public LoginExitoso() {<br />
super(new LoginSteps());<br />
}<br />
}<br />
</code><br />
<br />
=== LoginSteps.java ===<br />
Esta clase contiene la lógica de las pruebas, y es quien realmente asocia los mensajes de los escenarios a código para ejecutar. En esta clase, a través de las anotaciones, se convierte parte del texto en parámetros.<br />
<br />
<code java><br />
package com.dosideas.jbehave;<br />
<br />
import static org.jbehave.Ensure.ensureThat;<br />
import com.dosideas.business.LoginService;<br />
import org.jbehave.scenario.annotations.Given;<br />
import org.jbehave.scenario.annotations.Then;<br />
import org.jbehave.scenario.annotations.When;<br />
import org.jbehave.scenario.steps.Steps;<br />
<br />
public class LoginSteps extends Steps {<br />
<br />
private boolean login;<br />
<br />
@Given("No estoy logueado")<br />
public void logout() {<br />
login = false;<br />
}<br />
<br />
@When("me logueo como usuario $usuario y clave $pass")<br />
public void login(String usuario, String pass) {<br />
LoginService loginService = new LoginService();<br />
login = loginService.login(usuario, pass);<br />
}<br />
<br />
@Then("el login tiene que devolver $loginEsperado")<br />
public void comprobarLogin(String loginEsperado) {<br />
ensureThat(login == Boolean.valueOf(loginEsperado));<br />
}<br />
}<br />
</code><br />
<br />
=== Ejecutamos... ===<br />
La ejecución es como un test [[JUnit]] más, ya que la clase ''LoginExitoso'' es un test JUnit. <br />
<br />
== Ver también ==<br />
* [http://jbehave.org Web oficial de JBehave]</div>200.115.213.201https://dosideas.com/wiki/index.php?title=JBehave&diff=1344JBehave2008-12-14T12:26:44Z<p>200.115.213.201: /* Características */</p>
<hr />
<div>JBehave es un framework [[Java]] para mejorar la colaboración entre desarrolladores, QA, analistas de negocio, [[Dueño Del Producto]] y todos los miembros del equipo a través de escenarios automatizados pero legibles. <br />
<br />
== Características ==<br />
* Escenarios escritos en texto plano<br />
* Posibilidad de crear múltiples escenarios en un único archivo<br />
* Escenarios pendientes<br />
* Resultados claros y fáciles de leer<br />
* Captura de parámetros de los escenarios<br />
* Conversión de parámetros a objetos propios<br />
* Soporte para múltiples lenguajes y términos de escenarios<br />
* Altamente configurable<br />
* Soporte para [[Maven]]<br />
<br />
==Los escenarios==<br />
La forma de escribir escenarios de JBehave es similar a una [[Historia De Usuario]]. En general, una [[Historia De Usuario]] suele escribirse como: <br />
Como [Rol]<br />
Quiero [Caracteristica]<br />
De manera que reciba [Valor]<br />
<br />
Los escenarios en JBehave se escriben de la siguiente forma: <br />
Given [Contexto]<br />
When [Evento que ocurre]<br />
Then [Salida esperada]<br />
<br />
==Ejemplo==<br />
Vamos a probar un escenario de login. Las clases que intervienen en esto serán: <br />
* '''LoginService''': la clase de negocio bajo prueba<br />
* '''login_exitoso''': un archivo de texto que contiene el escenario<br />
* '''LoginExitoso''': una clase Java que representará al escenario<br />
* '''LoginSteps''': una clase Java que contendrá la lógica de la prueba<br />
<br />
=== LoginService.java ===<br />
Esta será la clase de negocio que probaremos. Tiene un único método ''login'' el cual recibe un usuario y una clave. Si la clave es igual al usuario en mayúsculas devuelve true, sino false. <br />
<br />
<code java><br />
package com.dosideas.business;<br />
<br />
public class LoginService {<br />
<br />
public boolean login(String user, String pass) {<br />
if (user.toUpperCase().equals(pass)) {<br />
return true;<br />
} else {<br />
return false;<br />
}<br />
}<br />
}<br />
</code><br />
<br />
=== login_exitoso ===<br />
Este es el archivo de texto con el escenario. Aquí podremos ir agregando los diferentes escenarios que querramos validar.<br />
Given No estoy logueado<br />
When me logueo como usuario Zim y clave ZIM<br />
Then el login tiene que devolver true<br />
<br />
=== LoginExitoso.java ===<br />
Esta clase extiende a ''org.jbehave.scenario.Scenario'' y se encarga de representar al escenario a utilizar. Lo único que hace es cargar la implementación a usar para realizar las pruebas, en este caso ''LoginSteps''. <br />
<br />
Esta clase tiene que estar junto al archivo de texto ''login_exitoso''.<br />
<br />
Esta clase es un test de [[JUnit]], y será la que ejecutaremos para realizar las pruebas.<br />
<br />
<code java><br />
package com.dosideas.jbehave;<br />
<br />
import org.jbehave.scenario.Scenario;<br />
<br />
public class LoginExitoso extends Scenario {<br />
<br />
public LoginExitoso() {<br />
super(new LoginSteps());<br />
}<br />
}<br />
</code><br />
<br />
=== LoginSteps.java ===<br />
Esta clase contiene la lógica de las pruebas, y es quien realmente asocia los mensajes de los escenarios a código para ejecutar. En esta clase, a través de las anotaciones, se convierte parte del texto en parámetros.<br />
<br />
<code java><br />
package com.dosideas.jbehave;<br />
<br />
import static org.jbehave.Ensure.ensureThat;<br />
import com.dosideas.business.LoginService;<br />
import org.jbehave.scenario.annotations.Given;<br />
import org.jbehave.scenario.annotations.Then;<br />
import org.jbehave.scenario.annotations.When;<br />
import org.jbehave.scenario.steps.Steps;<br />
<br />
public class LoginSteps extends Steps {<br />
<br />
private boolean login;<br />
<br />
@Given("No estoy logueado")<br />
public void logout() {<br />
login = false;<br />
}<br />
<br />
@When("me logueo como usuario $usuario y clave $pass")<br />
public void login(String usuario, String pass) {<br />
LoginService loginService = new LoginService();<br />
login = loginService.login(usuario, pass);<br />
}<br />
<br />
@Then("el login tiene que devolver $loginEsperado")<br />
public void comprobarLogin(String loginEsperado) {<br />
ensureThat(login == Boolean.valueOf(loginEsperado));<br />
}<br />
}<br />
</code><br />
<br />
=== Ejecutamos... ===<br />
La ejecución es como un test [[JUnit]] más, ya que la clase ''LoginExitoso'' es un test JUnit. <br />
<br />
== Ver también ==<br />
* [http://jbehave.org Web oficial de JBehave]</div>200.115.213.201https://dosideas.com/wiki/index.php?title=Actualizacion_Dinamica_Con_Hibernate&diff=1292Actualizacion Dinamica Con Hibernate2008-12-08T02:41:54Z<p>200.115.213.201: /* Dynamic-Update en archivo XML */</p>
<hr />
<div>[[Hibernate]], al iniciar, lee el archivo de configuracion ''hibernate.cfg.xml''. De manera predeterminada se generan y se levantan a memoria todas las sentencias de select, insert, update, delete de cada clase.<br />
<br />
Estas sentencias son las básicas por ID.<br />
<br />
Con respecto a los UPDATE esto presenta el inconveniente que ante un update de un solo campo del objeto, hibernate me genera el update de todos los campos del objeto.<br />
<br />
Para las bases de datos esto es poco beneficioso ya que estamos generando mas undo (guardar en el rollback el valor anterior de los campos) del necesario.<br />
<br />
Y pensemos lo malo que puede ser este comportamiento si ademas por el update de alguno de los campos, en la base de datos se dispara un trigger, independientemente si el valor es distinto o no.<br />
<br />
Estaríamos generando no solo undo innecesariamente, sino que tambien estaríamos aumentando el procesamiento.<br />
<br />
Para evitar esto Hibernate permite configurar la clase como '''dynamic-update'''<br />
<br />
===Dynamic-Update en archivo XML===<br />
<br />
<code xml><br />
<class name="Message" table="MESSAGES" dynamic-update="true"><br />
...<br />
</class><br />
</code><br />
<br />
===Dynamic-Update con anotaciones===<br />
<br />
<code java><br />
@Entity<br />
@org.hibernate.annotations.Entity(dynamicUpdate = true)<br />
@Table(name="MESSAGES")<br />
@SequenceGenerator(name="seq", sequenceName = "MESSAGES_SEQ", allocationSize=1)<br />
public class Message {<br />
...<br />
}<br />
</code><br />
<br />
En estas anotaciones vemos que además de usar las anotaciones estandar de JPA, estamos usando extensiones propias de Hibernate. Es el caso de la annotation Entity.<br />
<br />
Utilizar la Entity de Hibernate no nos libra de tener que utilizar la anotación estandar Entity, ya que cada tiene funcionalidad diferente. La de Hibernate no incluye el significado de la estandar, solo la extiende.<br />
<br />
Las annotations standard estan en la libreria ''ejb3-persistence.jar'' y para usarlas debemos importar el package ''javax.persistence.*''<br />
<br />
Para el caso de las anotaciones propias de Hibernate se recomienda no importar el package y escribirlas completas para diferenciarlas de las estandar.<br />
<br />
==Ver también==<br />
* [[Hibernate]]</div>200.115.213.201https://dosideas.com/wiki/index.php?title=CruiseControl&diff=1257CruiseControl2008-11-10T00:46:55Z<p>200.115.213.201: </p>
<hr />
<div>CruiseControl es un framework para el proceso de [[Integracion Continua]]. Incluye, aunque no es limitado, plugins para notificaciones por Email, [[Ant]], y se puede usar con varias herramientas de control de versiones. Provee una interfaz web para ver el detalle del actual y anteriores build's.<br />
<br />
<br />
==Ver También==<br />
* [[Herramientas Para Integracion Continua]]<br />
* [http://cruisecontrol.sourceforge.net/ Web oficial de CruiseControl]</div>200.115.213.201https://dosideas.com/wiki/index.php?title=Equipo_Pnt&diff=1256Equipo Pnt2008-11-10T00:45:06Z<p>200.115.213.201: /* Ex-integrantes */</p>
<hr />
<div>PNT (Proyectos de Nuevas Tecnologías) es un equipo de desarrollo de una consultora de sistemas, trabajando para una empresa multinacional de telefonía móvil.<br />
<br />
PNT fue formado inicialmente en diciembre de 2004 para resolver el diseño y desarrollo de proyectos basados en tecnologías Java.<br />
<br />
La experiencia de PNT fue documentada a lo largo de los años por varios de sus integrantes en una intranet propia del grupo, a través de notas en un [[Joomla]].<br />
<br />
== Integrantes ==<br />
Los integrantes actuales de PNT son:<br />
* Adrian Prados<br />
* Alejandra Holman<br />
* Andres Candal<br />
* Cristian DeBenedetti<br />
* Demian Berjman<br />
* Diego Gomez<br />
* Fabian Soliz<br />
* Gabriel Teolis<br />
* German DelTuffo<br />
* Juan José Barrera<br />
* Leonardo De Seta<br />
* Marcela Diaz<br />
* Nicolas Ferrucci<br />
* Matias Zamorano<br />
* Pablo Rivero<br />
* Ramiro Gomez Mazza<br />
* Victor Cabás<br />
<br />
== Ex-integrantes ==<br />
Las siguientes personas fueron miembros de PNT y aportaron a Dos Ideas a través de artículos y notas varias:<br />
* Agustin Fernandez<br />
* Agustin Gallego<br />
* Alejandro Amaya<br />
* Andrea Girimonte<br />
* Claudia Blatter<br />
* Federico Cherchyk<br />
* Federico Ferrer<br />
* Fernando Piccirillo<br />
* Fernando Requena<br />
* Mariano Cifre<br />
* Mariela Eujanian<br />
* Sergio Sanchez<br />
* Valeria Molinari<br />
<br />
== Otros participantes ==<br />
Las siguientes personas interactuaron directamente con PNT y también realizaron aportes:<br />
* Alejandro Vega<br />
* Carlos Alvarez<br />
* Carolina Barbiero</div>200.115.213.201https://dosideas.com/wiki/index.php?title=JAX-WS&diff=1255JAX-WS2008-11-10T00:44:38Z<p>200.115.213.201: /* Ejemplo */</p>
<hr />
<div>JAX-WS (Java Api for XML Web Services) es el API [[Java]] que se utiliza para la creación de [[Web Service]]. JAX-WS forma parte del estándar [[Java EE]]. <br />
<br />
La implementación de referencia de JAX-WS es parte del proyecto [[GlassFish]], y es de calidad productiva. <br />
<br />
En la plataforma Java EE 5, JAX-WS 2.0 reemplaza al API JAX-RPC. El cambio se basa en moverse hacia Web Services orientados a documentos (en vez de RPC). <br />
<br />
== Ejemplo ==<br />
La siguiente clase representa un Web Service usando JAX-WS: <br />
<br />
<code java5><br />
package com.dosideas.ws;<br />
<br />
import javax.jws.WebMethod;<br />
import javax.jws.WebParam;<br />
import javax.jws.WebService;<br />
<br />
@WebService()<br />
public class FlotaEspacialWebService {<br />
<br />
@WebMethod(operationName = "buscarInvasor")<br />
public Invasor buscarInvasor(@WebParam(name = "legajo") String legajo) {<br />
// buscar al invasor...<br />
return null;<br />
}<br />
}<br />
</code><br />
<br />
La anotacion ''@WebService()'' indica que la clase será un Web Service. La anotación ''@Webmethod()'' crea una operación para el Web Service, en base al método anotado. La anotación ''@WebParam()'' indica el nombre del parámetro en el web service. <br />
<br />
En base a estas clases anotadas, existen tareas Ant que crean las clases de soporte necesarias. [[NetBeans]] 6.x trae un amplio soporte para JAX-WS, y genera automáticamente todos los artefactos.<br />
<br />
== Ver también ==<br />
* [[Web Service]]<br />
* [https://jax-ws.dev.java.net Página oficial de JAX-WS]</div>200.115.213.201https://dosideas.com/wiki/index.php?title=Ant&diff=1219Ant2008-11-05T00:03:28Z<p>200.115.213.201: </p>
<hr />
<div>[[Ant]] es una herramienta de build de [[Software Libre]] especializada en construir proyectos Java. [[Ant]] utiliza archivos XML para expresar las instrucciones de ejecución de build.<br />
Ella posee una gran variedad de tareas que permiten la realización de actividades como generación de pruebas unitarias, publicación de información, entre otras.<br />
<br />
Algunos ejemplos de tareas pueden ser:<br />
<br />
* Prepare -> Realiza la creación de directorios que contendrán los ejecutables.<br />
* Compile -> Compila el código fuente del producto.<br />
* Instrument -> Instrumenta el código para permitir la generación de información de cobertura de código.<br />
* Compile-test -> Compila el código de pruebas unitarias automatizadas.<br />
* Test -> Ejecuta la batería de pruebas unitarias automatizadas, genera la información en HTML de las pruebas ejecutadas con éxito y con falla y genera la información en HTMl de la cobertura de código.<br />
* [[PMD]] -> Ejecuta la generación de información de análisis estática de código.<br />
* Javadoc -> Ejecuta la generación de documentación de las clases en base a los comentarios en el código fuente.<br />
* Run -> Ejecuta el software.<br />
* Clean -> Realiza la limpieza de los directorios que contienen los ejecutables.<br />
* Jar -> Realiza el empaquetado del software para que pueda se utilizado en producción.<br />
<br />
El script de build puede ser ejecutado de diversas maneras y con múltiples opciones.<br />
En el caso de línea de comando, por ejemplo "ant test pmd javadoc jar", todas las secciones del archivo XML serán ejecutadas.<br />
<br />
Ant puede ser utilizado para realizar la implantación de una aplicación JEE Web en producción.<br />
Un ejemplo de una sección que haría eso sería el siguiente:<br />
<target name="deploy"><br />
<deploy url="${tomcat.manager.url}"<br />
username="${tomcat.manager.username}"<br />
password="${tomcat.manager.password}"<br />
path="/${webap.name}"<br />
war="file:${warfile.path}" /><br />
</target><br />
<br />
==Ver también==<br />
* [[Automatizacion De Build]]<br />
* [[Maven]]<br />
* [http://ant.apache.org/ Web oficial de ANT]</div>200.115.213.201