Apuntes y Referencias sobre Software & Sistemas
Hola,
Este post tienen como objetivo ser una recopilación de herramientas y metodologías que cualquiera que trabaje o estudie sistemas sería conveniente que conozca, con el fin de mejorar en todos los sentidos el know-how relacionado a ésta tan extensa rama de la ingeniería.
Iré agregando, completando, corrigiendo y dando formato a cada uno de los "puntos" abajo listado. La idea es armar una "guia" de referencia sobre herramientas, metodologías, mejores prácticas, framework, etc, que incluya alguna pequeña reseña o explicación detallada (según sea el caso) y link hacia información o recursos más especializados.
Maven:
- WEB: http://maven.apache.org/
- Introducción
- Gestión y Administrador de proyectos de software Java.
- Utiliza un modelo de configuración XML => pom.xml
- settings.xml => repositorios, políticas, proxys, etc.
- Maven aplica el concepto de POM (Project Object Model link ) = pom.xml. Este archivo describe la dependencia de los modulo, componentes externos y el orden de construcción de los elementos.
- Maven permite:
* Generar y versionar un proyecto dentro de un “war”
* Ordenar y comprimir las librerías JAR dentro de un ZIP
* Generar un completo JavaDoc de la aplicación.
- Características:
- Estandarización de la estructura de un proyecto => por medio del archivo pom.xml.
- Mecanismos de gestión de dependencias => actualizaciones, resolución de dependencias, etc.
- Construcción basada en modelos: el software se puede empaquetar en: WAR, EAR, JAR, etc.
- Generación de un portal web en base al proyecto.
- Generación de releases y publicación => integración con Control de Versiones.
- Maven trabaja si o si con una conexión a internet (para descargar los Repositorios).
- Maven utiliza lo que se denomina COC (conventions over Configuration) y esto se hace a través de “arquetipos”. Un arquetipo es un estructura de proyecto predefinida y reconocidas en un archivo pom.xml.
- El modelo que usa para asegurarse que todas las dependencias del proyectos son correctas, consiste en descargar desde el repositorio configurado en el archivo de configuración de maven, todas las bibliotecas y módulos necesarios por el proyecto (indicando la versión de cada elemento) y guardando todos estos componentes en un repositorio local ubicado en /home/user/.m2/repository/...
Comandos
Algunos de los comandos de consola más usados son:
- mvn compile => compila el proyecto java, creado la carpeta /target (.class)
- mvn javadoc:javadoc => crea el javadoc del proyecto en la carpeta /target/site/apidocs
- mvn jar:jar / war/war
- mvn build => genera los binarios de nuestro proyecto (.class y JAR)
- mvn install => lleva los JAR de nuestra aplicación a nuestro repositorio local.
- mvn replay =>
- mvn deploy => lleva los JAR de nuestra aplicación a un repositorio compartido.
Dependencias
Son aquellos componentes que nuestro software necesita en algún momento de su ciclo de vida. Las dependencias un ámbito/scope según el momento en el que se la necesite:
- compile
- test
- privider
- run-time
- system
Junit (tests cases and tests suites)
Introducción
- WEB: http://junit.org/
- Framework para la generación de casos de pruebas (test cases).
- Utilizar los Assert para comprar los valores actuales y los esperados. Un Assert es un predicado (verdadero, falso, nulo, etc.) que se utiliza para determinar si un enunciado cumple el predicado.
- Escribir y utilizar los Casos de Prueba debe ser fácil.
- Los resultados de un Assert pueden ser:
* Exitoso (successfully)
* Fracaso (failure) = no se cumplió el predicado
* Error = un error inesperado
Estructura
- El ciclo de ejecución de cada testCase es el siguiente:
- Se llama a setUp() => configura un entorno iniciar
- Se llama a un caso de prueba particular: testXxx()
- Se llama a tearDown() => es cómo un finalice. Finaliza el entorno del caso de pruebas.
Testing
- Escribir los TestCases primero.
- Es recomendable que los casos de pruebas estén separados bajo otro nodo en la estructura de directorio del proyecto y además, se puede imitar el nombre de los paquetes donde viven las clases que se van a probar, así cada clase de prueba vive en un paquete del mismo nombre que la clase original (hace fácil la identificación de los casos de prueba).
- Todos los casos de prueba debe ser “pequeños y simples”.
- No se debe asumir nada acerca del orden de ejecución de los casos de prueba.
- Varios testCases se pueden agrupar en un testSuite, el cual sirve para probar un sub-sistema por ejemplo. En una testSuite se puede determinar el orden de ejecución de casa testCase.
Extensiones de Junit:
- Mock Object: Allows testing of code that accesses resources such as database connections and servlet containers without the need of the actual resources.
- Cactus
- DBUnits
Best Practices:
probar todo lo que posiblemente puede fallar.
Un buen caso de prueba debe ser difícil de pasar con éxito.
Agregar un caso de prueba por cada bug se que encuentre.
Cuando un caso de prueba falla, hacer más casos de pruebas sobre el problema encontrado.
Hacer casos de prueba que usen datos inválidos para cada parámetros de métodos.
Limpiar los logs de casos de pruebas anteriores antes de ejecutar nuevos.
Separa el código de prueba del código de producción.
Usar nombres claro para cada testCase: testDatabaseLoaded()
Tratar de probar sólo una cosa por caso de prueba.
Si no se pueden escribir casos de prueba para una determinada clase, significa que el código es inestable.
Hudson/Jenkins (integración continua)
TODO
Control de Versiones SVN
El CV es el manejo de los cambios en la información (código fuente, archivos xml, etc,)
repositorio: almacén central de datos, donde la información esta estructurada en forma de árbol. El repositorio tiene la capacidad de recordar los cambios realizados sobre la información que contiene.
SVN utiliza el modelo copiar-modificar-mezclar. Cada cliente descarga una copia de la información, la modifica localmente y luego mezcla (commit and merge) la copia local con la que se encuentra en el repositorio.
Cuando se produce un “conflicto” la única forma de resolverlo es manualmente (debe haber comunicación entre los cliente).
Las operaciones de SVN: commit, update, checkout son atomicas.
Para cada fichero en la copia de trabajo, SVN registra dos cosas en el área administrativa ./svn:
revisión de trabajo
timestamp
Revisión: es un instantánea del contenido del repositorio en un momento dado.
Branch => rama: es una línea de desarrollo que existe de forma independiente a otra, pero que comparte una historia común si se mira suficientemente hacia atrás.
Merge => al igual que el comando diff, este comando es capaz de comparar dos objetos cualquiera y descubrir sus diferencias. Al aplicar este comando, los cambios remotos (o del trunk) son aplicados a la copia de trabajo (pudiendo haber conflictos para resolver), se hace una funsión. Se pueden aplicar los cambios o llamar al comando svn revert para deshacerlos.
Terms and Definitions - Agility and Scrum
Several topics about Scrum and agile software development in general:
Burndown Chart
The Burndown Chart is a chart showing the cumulative amount of hours - or User Story Points left to successfully complete the committed work for a Sprint. This line is called the 'actual burndown'.
Another important line is the 'ideal burndown' which shows the ideal way of getting work done: Starting from the commitment on the first day the ideal burndown decreases linearly until it hits the x axis on the last day of the sprint which represents a steady pace in development.
The Agilo Sprint Burndown Chart shows also two additional lines:
Capacity Line: measures the real capacity per day of the Team which is calculated by summing up the individual capacity settings of each Team Member.
Trend Line: shows the moving average calculated on the last three days of burndown, showing where the deliverable will probably end if the team continues to burndown with the current trend.
Business Value
Daily Scrum
Ideal Hour
Product Backlog
Product Owner
Release
Requirement
Return on Investment Factor
Scrum Master
Sprint
Sprint Backlog
Sprint Planning Meeting
Sprint Review Meeting
Task
Team Member
User Story
User Story Points
Velocity
OOP Mejores Prácticas y Consejos
(+) cohesión (-) acoplamiento.
Flujos de control simple (if-else, while, for)
Atributos/variables con estado inicial conocido / default.
Métodos simple, con contratos bien definidos (Design by contract)
Métodos y clases con un único propósito (alta cohesión)
Documentar: atributos estáticos, métodos y clases, incluso si son implementaciones o redeficiones de interfaces o clases abstractas.
Siempre respetar la sintaxis: {objeto / clase}.{atributo / método() }
Siempre usar getters/setters.
Tratar de no retornar / comprobar por null.
Nunca duplicar código.
Dependency Injection
Inicialización diferida
Libros de Referencia:
La lista de libros incluye unos cuantos más que son pilares en lo que respecta Desarrollo de Software. A Continuación la lista:
* Clean Code: A Handbook of Agile Software Craftsmanship
* Design patterns: elements of reusableobject-oriented software
* Design patterns: elements of reusableobject-oriented software
* Effective Java 2nd Edition
* Java In a Nutshell 5th Edition
* Object-oriented-analysis and design with applications 3rd Edition
* OSGi in Action: Creating Modular Applications in Java
* Patterns of Enterprise Application Architecture
* Refactoring: Improving the Design of Existing Code
* Testing with JUnit
* The Art of Agile Development
* The Elements of Java Style
* The Object Primer, Third Edition
* The Pragmatic Programmer: From Journeyman to Master
* The Scrum Primer (es)
Link DropBox: https://www.dropbox.com/sh/jtoy0o6l9a9sjgs/fvVEFC4Xmw
Hola,
Este post tienen como objetivo ser una recopilación de herramientas y metodologías que cualquiera que trabaje o estudie sistemas sería conveniente que conozca, con el fin de mejorar en todos los sentidos el know-how relacionado a ésta tan extensa rama de la ingeniería.
Iré agregando, completando, corrigiendo y dando formato a cada uno de los "puntos" abajo listado. La idea es armar una "guia" de referencia sobre herramientas, metodologías, mejores prácticas, framework, etc, que incluya alguna pequeña reseña o explicación detallada (según sea el caso) y link hacia información o recursos más especializados.
Maven:
- WEB: http://maven.apache.org/
- Introducción
- Gestión y Administrador de proyectos de software Java.
- Utiliza un modelo de configuración XML => pom.xml
- settings.xml => repositorios, políticas, proxys, etc.
- Maven aplica el concepto de POM (Project Object Model link ) = pom.xml. Este archivo describe la dependencia de los modulo, componentes externos y el orden de construcción de los elementos.
- Maven permite:
* Generar y versionar un proyecto dentro de un “war”
* Ordenar y comprimir las librerías JAR dentro de un ZIP
* Generar un completo JavaDoc de la aplicación.
- Características:
- Estandarización de la estructura de un proyecto => por medio del archivo pom.xml.
- Mecanismos de gestión de dependencias => actualizaciones, resolución de dependencias, etc.
- Construcción basada en modelos: el software se puede empaquetar en: WAR, EAR, JAR, etc.
- Generación de un portal web en base al proyecto.
- Generación de releases y publicación => integración con Control de Versiones.
- Maven trabaja si o si con una conexión a internet (para descargar los Repositorios).
- Maven utiliza lo que se denomina COC (conventions over Configuration) y esto se hace a través de “arquetipos”. Un arquetipo es un estructura de proyecto predefinida y reconocidas en un archivo pom.xml.
- El modelo que usa para asegurarse que todas las dependencias del proyectos son correctas, consiste en descargar desde el repositorio configurado en el archivo de configuración de maven, todas las bibliotecas y módulos necesarios por el proyecto (indicando la versión de cada elemento) y guardando todos estos componentes en un repositorio local ubicado en /home/user/.m2/repository/...
Comandos
Algunos de los comandos de consola más usados son:
- mvn compile => compila el proyecto java, creado la carpeta /target (.class)
- mvn javadoc:javadoc => crea el javadoc del proyecto en la carpeta /target/site/apidocs
- mvn jar:jar / war/war
- mvn build => genera los binarios de nuestro proyecto (.class y JAR)
- mvn install => lleva los JAR de nuestra aplicación a nuestro repositorio local.
- mvn replay =>
- mvn deploy => lleva los JAR de nuestra aplicación a un repositorio compartido.
Dependencias
Son aquellos componentes que nuestro software necesita en algún momento de su ciclo de vida. Las dependencias un ámbito/scope según el momento en el que se la necesite:
- compile
- test
- privider
- run-time
- system
Junit (tests cases and tests suites)
Introducción
- WEB: http://junit.org/
- Framework para la generación de casos de pruebas (test cases).
- Utilizar los Assert para comprar los valores actuales y los esperados. Un Assert es un predicado (verdadero, falso, nulo, etc.) que se utiliza para determinar si un enunciado cumple el predicado.
- Escribir y utilizar los Casos de Prueba debe ser fácil.
- Los resultados de un Assert pueden ser:
* Exitoso (successfully)
* Fracaso (failure) = no se cumplió el predicado
* Error = un error inesperado
Estructura
- El ciclo de ejecución de cada testCase es el siguiente:
- Se llama a setUp() => configura un entorno iniciar
- Se llama a un caso de prueba particular: testXxx()
- Se llama a tearDown() => es cómo un finalice. Finaliza el entorno del caso de pruebas.
Testing
- Escribir los TestCases primero.
- Es recomendable que los casos de pruebas estén separados bajo otro nodo en la estructura de directorio del proyecto y además, se puede imitar el nombre de los paquetes donde viven las clases que se van a probar, así cada clase de prueba vive en un paquete del mismo nombre que la clase original (hace fácil la identificación de los casos de prueba).
- Todos los casos de prueba debe ser “pequeños y simples”.
- No se debe asumir nada acerca del orden de ejecución de los casos de prueba.
- Varios testCases se pueden agrupar en un testSuite, el cual sirve para probar un sub-sistema por ejemplo. En una testSuite se puede determinar el orden de ejecución de casa testCase.
Extensiones de Junit:
- Mock Object: Allows testing of code that accesses resources such as database connections and servlet containers without the need of the actual resources.
- Cactus
- DBUnits
Best Practices:
probar todo lo que posiblemente puede fallar.
Un buen caso de prueba debe ser difícil de pasar con éxito.
Agregar un caso de prueba por cada bug se que encuentre.
Cuando un caso de prueba falla, hacer más casos de pruebas sobre el problema encontrado.
Hacer casos de prueba que usen datos inválidos para cada parámetros de métodos.
Limpiar los logs de casos de pruebas anteriores antes de ejecutar nuevos.
Separa el código de prueba del código de producción.
Usar nombres claro para cada testCase: testDatabaseLoaded()
Tratar de probar sólo una cosa por caso de prueba.
Si no se pueden escribir casos de prueba para una determinada clase, significa que el código es inestable.
Hudson/Jenkins (integración continua)
TODO
Control de Versiones SVN
El CV es el manejo de los cambios en la información (código fuente, archivos xml, etc,)
repositorio: almacén central de datos, donde la información esta estructurada en forma de árbol. El repositorio tiene la capacidad de recordar los cambios realizados sobre la información que contiene.
SVN utiliza el modelo copiar-modificar-mezclar. Cada cliente descarga una copia de la información, la modifica localmente y luego mezcla (commit and merge) la copia local con la que se encuentra en el repositorio.
Cuando se produce un “conflicto” la única forma de resolverlo es manualmente (debe haber comunicación entre los cliente).
Las operaciones de SVN: commit, update, checkout son atomicas.
Para cada fichero en la copia de trabajo, SVN registra dos cosas en el área administrativa ./svn:
revisión de trabajo
timestamp
Revisión: es un instantánea del contenido del repositorio en un momento dado.
Branch => rama: es una línea de desarrollo que existe de forma independiente a otra, pero que comparte una historia común si se mira suficientemente hacia atrás.
Merge => al igual que el comando diff, este comando es capaz de comparar dos objetos cualquiera y descubrir sus diferencias. Al aplicar este comando, los cambios remotos (o del trunk) son aplicados a la copia de trabajo (pudiendo haber conflictos para resolver), se hace una funsión. Se pueden aplicar los cambios o llamar al comando svn revert para deshacerlos.
Terms and Definitions - Agility and Scrum
Several topics about Scrum and agile software development in general:
Burndown Chart
The Burndown Chart is a chart showing the cumulative amount of hours - or User Story Points left to successfully complete the committed work for a Sprint. This line is called the 'actual burndown'.
Another important line is the 'ideal burndown' which shows the ideal way of getting work done: Starting from the commitment on the first day the ideal burndown decreases linearly until it hits the x axis on the last day of the sprint which represents a steady pace in development.
The Agilo Sprint Burndown Chart shows also two additional lines:
Capacity Line: measures the real capacity per day of the Team which is calculated by summing up the individual capacity settings of each Team Member.
Trend Line: shows the moving average calculated on the last three days of burndown, showing where the deliverable will probably end if the team continues to burndown with the current trend.
Business Value
Daily Scrum
Ideal Hour
Product Backlog
Product Owner
Release
Requirement
Return on Investment Factor
Scrum Master
Sprint
Sprint Backlog
Sprint Planning Meeting
Sprint Review Meeting
Task
Team Member
User Story
User Story Points
Velocity
OOP Mejores Prácticas y Consejos
(+) cohesión (-) acoplamiento.
Flujos de control simple (if-else, while, for)
Atributos/variables con estado inicial conocido / default.
Métodos simple, con contratos bien definidos (Design by contract)
Métodos y clases con un único propósito (alta cohesión)
Documentar: atributos estáticos, métodos y clases, incluso si son implementaciones o redeficiones de interfaces o clases abstractas.
Siempre respetar la sintaxis: {objeto / clase}.{atributo / método() }
Siempre usar getters/setters.
Tratar de no retornar / comprobar por null.
Nunca duplicar código.
Dependency Injection
Inicialización diferida
Libros de Referencia:
La lista de libros incluye unos cuantos más que son pilares en lo que respecta Desarrollo de Software. A Continuación la lista:
* Clean Code: A Handbook of Agile Software Craftsmanship
* Design patterns: elements of reusableobject-oriented software
* Design patterns: elements of reusableobject-oriented software
* Effective Java 2nd Edition
* Java In a Nutshell 5th Edition
* Object-oriented-analysis and design with applications 3rd Edition
* OSGi in Action: Creating Modular Applications in Java
* Patterns of Enterprise Application Architecture
* Refactoring: Improving the Design of Existing Code
* Testing with JUnit
* The Art of Agile Development
* The Elements of Java Style
* The Object Primer, Third Edition
* The Pragmatic Programmer: From Journeyman to Master
* The Scrum Primer (es)
Link DropBox: https://www.dropbox.com/sh/jtoy0o6l9a9sjgs/fvVEFC4Xmw