matiaspakua

Why Automated Tests Boost Your Development Speed o ¿Por qué la automatización de Test incrementa la velocidad de Desarrollo? Hola, Este articulo ofrece un punto de vista muy útil al momento de decidir comenzar a utilizar automatización de Test. Vale la pena pegarle una leída!

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

10 Object Oriented Design principles for the Java programmer Comparto un artículo realmente muy bueno sobre principios de diseño orientado a objetos (orientado a java), pero que son aplicables a cualquier tipo de desarrollo de SW. --- Object Oriented Design Principles are core of OOPS programming but I have seen most of Java programmer chasing design patterns like Singleton pattern , Decorator pattern or Observer pattern but not putting enough attention on Object oriented analysis and design or following these design principles. I have regularly seen Java programmers and developers of various experience level who either doesn’t heard about these OOPS and SOLID design principle or simply doesn’t know what benefits a particular design principle offers or how to use these design principle in coding. Bottom line is always strive for highly cohesive and loosely couple solution, code or design and looking open source code from Apache and Sun are good examples of Java design principles or how design principles should be used in Java coding. Java Development Kit follows several design principle like Factory Pattern in BorderFactory class, Singleton pattern in Runtime class and if you interested more on Java code read Effective Java by Joshua Bloch , a gem by the guy who wrote Java API. My another personal favorite on object oriented design pattern is Head First Design Pattern by Kathy Sierra and others and Head First Object Oriented Analysis and Design . " Though best way of learning design principles or pattern is real world example and understanding the consequences of violating that design principle, subject of this article is Introducing Object oriented design principles for Java Programmers who are either not exposed to it or in learning phase. I personally think each of these design principle need an article to explain it clearly and I will definitely try to do it here but for now just get yourself ready for quick bike ride on design principle town " 1 - Object oriented design principle 1 – DRY (Don’t repeat yourself) As name suggest DRY (don’t repeat yourself) means don’t write duplicate code, instead use abstraction to abstract common things in one place. if you use a hardcoded value more than one time consider making it public final constant, if you have block of code in more than two place consider making it a separate method. Benefit of this SOLID design principle is in maintenance. Its worth to note is don?€™t abuse it, duplicate is not for code but for functionality means if you used common code to validate OrderID and SSN it doesn?€™t mean they are same or they will remain same in future. By using common code for two different functionality or thing you closely couple them forever and when your OrderID changes its format , your SSN validation code will break. So beaware of such coupling and just don?€™t combine anything which uses similar code but are not related. 2 - Object oriented design principle 2 – Encapsulate what varies Only one thing is constant in software field and that is “Change”, So encapsulate the code you expect or suspect to be changed in future. Benefit of this OOPS Design principle is that Its easy to test and maintain proper encapsulated code. If you are coding in Java then follow principle of making variable and methods private by default and increasing access step by step e.g. from private to protected and not public. Several of design pattern in Java uses Encapsulation, Factory design pattern is one example of Encapsulation which encapsulate object creation code and provides flexibility to introduce new product later with no impact on existing code. 3 - Object oriented design principle 3 – Open Closed principle Classes, methods or functions should be Open for extension (new functionality) and Closed for modification. This is another beautiful object oriented design principle which prevents some-one from changing already tried and tested code. Ideally if you are adding new functionality only than your code should be tested and that’s the goal of Open Closed Design principle. 4 - Object oriented design principle 4 – Single Responsibility Principle (SRP) There should not be more than one reason for a class to change or a class should always handle single functionality. If you put more than one functionality in one Class in Java it introduce coupling between two functionality and even if you change one functionality there is chance you broke coupled functionality which require another round of testing to avoid any surprise on production environment. 5 - Object oriented design principle 5 – Dependency Injection or Inversion principle Don’t ask for dependency it will be provided to you by framework. This has been very well implemented in Spring framework, beauty of this design principle is that any class which is injected by DI framework is easy to test with mock object and easier to maintain because object creation code is centralized in framework and client code is not littered with that.There are multiple ways to implemented Dependency injection like using byte code instrumentation which some AOP (Aspect Oriented programming) framework like AspectJ does or by using proxies just like used in Spring. 6 - Object oriented design principle 6 – Favour Composition over Inheritance Always favour composition over inheritance if possible. Some of you may argue this but I found that Composition is lot more flexible than Inheritance. Composition allows to change behaviour of a class at runtime by setting property during runtime and by using Interfaces to compose a class we use polymorphism which provides flexibility of to replace with better implementation any time. Even Effective Java advise to favor composition over inheritance. 7 - Object oriented design principle 7 – Liskov Substitution Principle (LSP) According to Liskov Substitution Principle Subtypes must be substitutable for super type i.e. methods or functions which uses super class type must be able to work with object of sub class without any issue”. LSP is closely related to Single responsibility principle and Interface Segregation Principle. If a class has more functionality than subclass might not support some of the functionality and does violated LSP. In order to follow LSP design principle, derived class or sub class must enhance functionality not reducing it. 8 - Object oriented design principle 8 – Interface Segregation principle (ISP) Interface Segregation Principle stats that a client should not implement an interface if it doesn’t use that. this happens mostly when one interface contains more than one functionality and client only need one functionality and not other.Interface design is tricky job because once you release your interface you can not change it without breaking all implementation. Another benefit of this desing principle in Java is, interface has disadvantage to implement all method before any class can use it so having single functionality means less method to implement. 9 - Object oriented design principle 9 – Programming for Interface not implementation Always program for interface and not for implementation this will lead to flexible code which can work with any new implementation of interface. So use interface type on variables, return types of method or argument type of methods in Java. This has been advised by many Java programmer including in Effective Java and head first design pattern book. 10 - Object oriented design principle 10 – Delegation principle Don’t do all stuff by yourself, delegate it to respective class. Classical example of delegation design principle is equals() and hashCode() method in Java. In order to compare two object for equality we ask class itself to do comparison instead of Client class doing that check. Benefit of this design principle is no duplication of code and pretty easy to modify behaviour. All these object oriented design principle helps you write flexible and better code by striving high cohesion and low coupling. Theory is first step but what is most important is to develope ability to find out when and to apply these design principle and find our whether we are violating any design principle and compromising flexibility of code. but again as nothing is perfect in this world, don’t always try to solve problem with design patterns and design principle they are mostly for large enterprise project which has longer maintenance cycle. Dejo el Link al artículo original, donde se pueden ver referencias a otros articulos muy buenos! http://www.javacodegeeks.com/2012/08/10-object-oriented-design-principles.html

4 great places to learn programming for free Desde el siguiente link se ofrece una breve perspectiva sobre 4 muy buenas fuentes para aprender a programar (plataformas de educación virtual). Conocidos han realizado cursos de la página Coursera.org y los resultados han sido muy satisfactorios. http://whynotsharing.blogspot.com.ar/2013/09/4-great-places-to-learn-programming-for.html

How to move your project from Subversion on Java.net to Git on GitHub without losing the change history. Cloning the Subversion Repository The normal way to duplicate a Subversion repository with full history is to use the svnadmin dump and load commands. Unfortunately most SVN hosting services, including Java.net, do not provide access to svnadmin commands or direct access to the file system. Fortunately there is another way to clone a repository, complete with all its history, that requires only read access to the repository: svnsync. The first step is to create a local SVN repository into which you will mirror the remote Java.net repository. svnadmin create myproject Before cloning the contents it is important that you add a pre-revprop-change hook to your new local repository. This is a script that must complete successfully (exit code 0) before any changes to revision properties are accepted. The easiest way to do this to add an empty script and make it executable. echo '#!/bin/sh' > myproject/hooks/pre-revprop-change chmod +x myproject/hooks/pre-revprop/change Bearing in mind that we want to preserve tags and branches too, not just the trunk, we can then mirror the top-level of the remote repository. svnsync init file:///pathto/myproject https://myproject.dev.java.net/svn/myproject svnsync sync file:///pathto/myproject This may take a while if the repository is large and/or your connection is slow. Stripping Java.net Web Content from the Repository Java.net uses the project SVN repository to manage the project website, with the files stored under trunk/www. When migrating from Java.net you probably don’t want to continue with this approach. If that’s the case then you’ll want to remove all traces of the www directory from the repository. The usual way of deleting a file – removing it from the working copy and then committing – will not purge its history so instead we use the svndumpfilter command. First dump the mirrored repository: svnadmin dump myproject > dump We can then remove all traces of the www directory. Any commits that only touched files under www are now empty and are dropped completely. All remaining revisions are renumbered to avoid gaps in the sequence. svndumpfilter --drop-empty-revs --renumber-revs exclude trunk/www < dump > filtered The final step is to restore the filtered dump in place of our local repository. rm -rf myproject svnadmin create myproject svnadmin load myproject < filtered Migrating the Repository from SVN to Git Now that the local SVN repository contains only what we wish to keep, we are ready to migrate it to Git. To achieve this I follow Paul Dowman’s instructions. The first step is to import the SVN repository into a new Git repository. git svn clone file:///pathto/myproject --no-metadata -A authors.txt -t tags -b branches -T trunk myproject-git The authors.txt file maps SVN users to Git users. Your Java.net repository may have commits attributed to the users root and httpd. You should probably just map these to your own user name. There should be one entry for each committer: root = Your Name <[email protected]> httpd = Your Name <[email protected]> you = Your Name <[email protected]> other = Someone Else <[email protected]> Refer to Paul’s full instructions if you have branches and tags to maintain. Pushing to GitHub Create a new repository on GitHub and then add this as a remote for your local Git repository. git remote add origin [email protected]:username/myproject.git And then push: git push origin master --tags Job done.

Kunagi - Agile project management based on Scrum Excelente herramienta para administrar proyecto Agiles usando SCRUM. Se trata de una excelente herramienta WEB para administrar proyectos basados en scrum. Contiene un conjunto muy amplio de características, como por ejemplo: + Herramientas Colaborativas - Wiki - Forrum - Calendario - Repositorio de archivos - sala de justicia (o de castigos, muy divertido éste concepto) + Projecto - Impedimentos - Riesgos - Diario (o bitácota) - Administración de Sprints + Producto - Releases - Backlog - Issues - Releases - Blog - Dashboard - User Stories - Tasks ...y muchas carácterísticas más. Instalación La instalación es tan simple como: 1) tener instalado y configurados un servidor de aplicaciones (por ejemplo, Tomcat7). 2) bajar y desplegar el .WAR 3) Acceder a localhost:8080/kunagi 4) listo! Les dejor el link de la WEB del proyecto: http://kunagi.org/

Introduction to Git with Scott Chacon of GitHub Hola, Comparto un excelente video-tutorial para aprender a usar Git, de mano de unos de los Guru del tema: Scott Chacon. http://www.youtube.com/playlist?list=FLRmgnkkbIWrhNJTUNpn0o8w

Learn One Java Concept Everyday Comparto la siguiente página, la cual tiene un concepto bastante interesante. Te enseña un "concepto/tema" de Java (lenguaje de programación) por día. Todos los días se postea un nuevo tema. Link: http://javaconceptoftheday.com/

Hola, Comparto un curso muy bueno de Programación en Java presentado por la plataforma Virtual Udacity (MOOC): Curso de Programación en Java https://www.udacity.com/wiki/cs046 IDE para Java El curso utiliza como IDE de programación la siguiente herramienta, que me pareció muy sencilla y útil al momento de aprender a programar en Java: http://www.bluej.org/

Hola, Comparto un blog, donde el autor del mismo realizo un experimento con lo que él llamo "Personal Scrum", o sea, administrar un proyecto de desarrollo de software utilizando la metodología de trabajo SCRUM, pero con 1 sólo miembro en el equipo de trabajo. En el blog, enumera los todos los elementos: planillas Excel, detalle de los sprints, retrospectivas, etc. que fue generando para llevar adelante el proyecto, junto con lo más importante del mismo: LA EXPERIENCIA adquirida durante el proyecto. Dejo el link: http://blog.jgpruitt.com/tag/personal-scrum/