Wednesday, February 25, 2015

Patrones de diseño - Patrón Observador

Patrones de diseño - Patrón Observador



Patrón Observer se utiliza cuando hay muchos-uno a la relación entre los objetos como si un objeto es modificado, sus objetos depenedent deben ser notificados automáticamente.Patrón Observer cae bajo la categoría patrón de comportamiento.

Implementación

Patrón Observer utiliza tres clases de actores. Asunto, Observador y Cliente. El sujeto es un objeto que tiene métodos para unir y separar los observadores a un objeto cliente. Hemos creado un Observador clase abstracta y una clase de sujeto concreto que se está extendiendo la clase Observer.
ObserverPatternDemo, nuestra clase de demostración, utilizará Asunto y concreto objeto de clase para mostrar el patrón de observador en la acción.
Patrón Observador UML Diagrama

Paso 1

Crear Subject clase.
Subject.java
import java.util.ArrayList;
import java.util.List;

public class Subject {
 
   private List<Observer> observers = new ArrayList<Observer>();
   private int state;

   public int getState() {
      return state;
   }

   public void setState(int state) {
      this.state = state;
      notifyAllObservers();
   }

   public void attach(Observer observer){
      observers.add(observer);  
   }

   public void notifyAllObservers(){
      for (Observer observer : observers) {
         observer.update();
      }
   }  
}

Paso 2

Create Observer class.
Observer.java
public abstract class Observer {
   protected Subject subject;
   public abstract void update();
}

Paso 3

crar concrete observer classes
BinaryObserver.java
public class BinaryObserver extends Observer{

   public BinaryObserver(Subject subject){
      this.subject = subject;
      this.subject.attach(this);
   }

   @Override
   public void update() {
      System.out.println( "Binary String: " + Integer.toBinaryString( subject.getState() ) ); 
   }
}
OctalObserver.java
public class OctalObserver extends Observer{

   public OctalObserver(Subject subject){
      this.subject = subject;
      this.subject.attach(this);
   }

   @Override
   public void update() {
     System.out.println( "Octal String: " + Integer.toOctalString( subject.getState() ) ); 
   }
}
HexaObserver.java
public class HexaObserver extends Observer{

   public HexaObserver(Subject subject){
      this.subject = subject;
      this.subject.attach(this);
   }

   @Override
   public void update() {
      System.out.println( "Hex String: " + Integer.toHexString( subject.getState() ).toUpperCase() ); 
   }
}

Paso 4

usar objectos observadores Subject y concrete.
ObserverPatternDemo.java
public class ObserverPatternDemo {
   public static void main(String[] args) {
      Subject subject = new Subject();

      new HexaObserver(subject);
      new OctalObserver(subject);
      new BinaryObserver(subject);

      System.out.println("First state change: 15"); 
      subject.setState(15);
      System.out.println("Second state change: 10"); 
      subject.setState(10);
   }
}

Paso 5

Verificar salida
First state change: 15
Hex String: F
Octal String: 17
Binary String: 1111
Second state change: 10
Hex String: A
Octal String: 12
Binary String: 1010

Fuente : http://www.tutorialspoint.com/design_pattern/observer_pattern.htm

Editorconfig en nuestro entorno de trabajo


¿Que es EditorConfig?

EditorConfig ayuda a los desarrolladores definir y mantener estilos de codificación uniformes entre los diferentes editores y entornos de desarrollo. El proyecto EditorConfig consiste en un formato de archivo para definir estilos de codificación y una colección de plugins editor de texto que permiten a los editores para leer el formato de archivo y se adhieren a los estilos definidos.Archivos EditorConfig son de fácil lectura y trabajan muy bien con los sistemas de control de versiones.

¿como es un archivo EditorConfig?

Archivo de ejemplo

A continuación se muestra un ejemplo .editorconfig archivo de ajuste de fin de línea y estilos de sangría para los archivos de Python y JavaScript.
 # EditorConfig is awesome: http://EditorConfig.org

# top-most EditorConfig file
root = true

# Unix-style newlines with a newline ending every file
[*]
end_of_line = lf
insert_final_newline = true

# Matches multiple files with brace expansion notation
# Set default charset
[*.{js,py}]
charset = utf-8

# 4 space indentation
[*.py]
indent_style = space
indent_size = 4

# Tab indentation (no size specified)
[*.js]
indent_style = tab

# Indentation override for all JS under lib directory
[lib/**.js]
indent_style = space
indent_size = 2

# Matches the exact files either package.json or .travis.yml
[{package.json,.travis.yml}]
indent_style = space
indent_size = 2

¿Dónde se guardan estos archivos?

Al abrir un archivo, plugins EditorConfig buscan un archivo llamado.editorconfig en el directorio del archivo abierto y en cada directorio padre.Una búsqueda de .editorconfig archivos se detendrá si se alcanza la ruta de archivo raíz o un archivo EditorConfig con root=true se encuentra.
Archivos EditorConfig se leen de arriba a abajo y los archivos EditorConfig más cercanos se leen pasado. Propiedades de hacer juego secciones EditorConfig se aplican en el orden en que se leen, por lo que las propiedades de los archivos más estrechos tienen prioridad.
Para usuarios de Windows: Para crear un .editorconfig archivo en el Explorador de Windows, necesita crear un archivo llamado .editorconfig. , que el Explorador de Windows cambiará automáticamente el nombre de.editorconfig .

Formato de archivo detalles

Archivos EditorConfig utilizan un formato INI que es compatible con el formato utilizado por Python ConfigParser Biblioteca , pero [y] están permitidos en los nombres de las secciones. Los nombres de sección son FilePath pegotes , similar al formato aceptado por gitignore . Barras inclinadas (/) se utilizan como separadores de ruta y octothorpes (#) o punto y coma (;) son usadas como comentarios. Los comentarios deben ir en sus propias líneas. Archivos EditorConfig deben ser codificación UTF-8, ya sea con CRLF o separadores de línea LF.
Patrones globales filePath y propiedades EditorConfig actualmente soportados se explican a continuación.

Los patrones de comodines

Los caracteres especiales reconocidos en los nombres de sección para la coincidencia de comodines:
*Coincide con cualquier cadena de caracteres, excepto separadores de ruta ( / )
**Coincide con cualquier cadena de caracteres
?Coincide con cualquier carácter individual
[name]Coincide con cualquier carácter individual en nombre
[!name]Coincide con cualquier carácter individual no de nombre
{s1,s2,s3}Coincide con cualquiera de las cadenas dadas (separados por comas) (Disponible desde EditorConfig Core 0.11.0)
Los caracteres especiales se pueden escapar con una barra invertida para que no se pueden interpretar como patrones de comodines.

Propiedades compatibles

Tenga en cuenta que no todas las propiedades son apoyados por todos los plugins. El wiki tiene una lista completa de propiedades .
  • indent_style: set a la pestaña o el espacio para usar pestañas duras o suaves pestañas respectivamente.
  • indent_size: un número entero que define el número de columnas que se utilizan para cada nivel de sangrado y la anchura de las lengüetas suaves (cuando sea compatible). Cuando se establece en la ficha, se utilizará el valor de tab_width (si se especifica).
  • tab_width: un número entero que define el número de columnas que se utilizan para representar un carácter de tabulación. Por defecto es el valor deindent_size y no suele deben especificarse.
  • end_of_line: set de LF, CR o crlf para controlar cómo se representan los saltos de línea.
  • charset: set para latin1, UTF-8, UTF-8-bom, UTF-16BE o UTF-16LEpara controlar el juego de caracteres. El uso de UTF-8-bom se desalienta.
  • trim_trailing_whitespace: establecido en true para eliminar los espacios en blanco precedentes caracteres de nueva línea y falsa para asegurarse de que no lo hace.
  • insert_final_newline: set para asegurar cierto archivo termina con un salto de línea al guardar y falso para asegurarse de que no lo hace.
  • root: propiedad especial que debe especificarse en la parte superior del archivo fuera de cualquier sección. Se establece en true para detener.editorconfig archivos buscar en el archivo actual.
Actualmente todas las propiedades y valores distinguen entre mayúsculas y minúsculas. Ellos serán minúsculas cuando lo analiza. En general, si no se especifica una propiedad, se utilizarán los ajustes del editor, es decir EditorConfig toma ningún efecto sobre esa parte.
Es aceptable y, a menudo prefería dejar ciertas propiedades EditorConfig no especificado. Por ejemplo, tab_width No es necesario especificar a menos que difiere del valor de indent_size. Además, cuando indent_style se ajusta a lapestaña, puede ser deseable dejar indent_size no especificado para que los lectores pueden ver el archivo usando su formato indentación preferida.Además, si una propiedad no ha sido estandarizada en su proyecto(end_of_line por ejemplo), puede ser mejor para dejarlo en blanco.
Fuente: http://editorconfig.org/

Código Dinámico Evolución VM

Código Dinámico Evolución VM (o Dinamic Code Evolution en ingles)

La máquina virtual de código dinámico Evolución (DCE VM) es una modificación de la Java HotSpot (TM) VM que permite redefinición ilimitado de clases cargadas en tiempo de ejecución. El mecanismo hotswapping actual del HotSpot (TM) VM sólo permite cambiar cuerpos de los métodos. Nuestro mayor VM permite agregar y quitar campos y métodos, así como los cambios en los súper tipos de una clase.
Este es un proyecto de código abierto liberado bajo la GPL v2.0. Puede descargar el código fuente , así como los binarios para Windows, Mac y Linux VMs.

Instalacion


Advertencia: Este es un trabajo en progreso y en la actualidad en un estado experimental. Por el momento, la máquina virtual es lo suficientemente estable como para ser utilizado al depurar programas Java. No se aconseja su uso en un sistema de producción.
Nota: La última versión de Java 1.6 actualización 26 no es compatible con el DCE VM. Todos Java 1.6 versiones anteriores son compatibles.
Actualmente, la versión binaria de la máquina virtual está disponible para el 32-bit y 64-bit de Windows VM, de 32 bits Mac OS Soylatte VM (entiendes aquí ), y de 32 bits Linux 

Archivos ejecutables del instalador

Instrucciones de instalación

Los archivos JAR son ejecutables y contienen un instalador, por lo que es necesario instalar un JRE o JDK de antemano. Se recomienda utilizar la última JDK7 copia binaria disponible en https://jdk7.dev.java.net/ , pero el binario también debe trabajar con instalaciones JDK6 o jre6. Asegúrese de poner en marcha el programa de instalación con privilegios suficientes.
Para iniciar el programa de instalación en Windows con privilegios de administrador desde la línea de comandos abra una consola y el tipo de administrador:
> java -jar dcevm-0.2-win.jar
Para iniciar el programa de instalación en Mac OS con privilegios de administrador del tipo de línea de comandos:
$ sudo java -jar dcevm-0.2-mac.jar
Para iniciar el programa de instalación en Linux con privilegios de administrador del tipo de línea de comandos:
$ sudo java -jar dcevm-0.2-linux.jar
El instalador reemplaza el bin / cliente / jvm.dll y bin / server / jvm.dll con una versión modificada copias de seguridad de la anterior y añadiendo la dcevm.jar al directorio lib / ext /. Estos cambios se deshacen en la desinstalación.
Windows Installer
El instalador buscará instalaciones Java instaladas en los lugares comunes en el sistema de archivos y los muestra en una lista. Si el directorio de instalación deseada no está en la lista, que fácilmente se puede agregar al presionar el botón "Añadir directorio de instalación ...". El "Java Versión" y las columnas "Tipo" muestran información sobre esta instalación. La columna "DCE" muestra el estado de modificación de la máquina virtual.
Para instalar o desinstalar pulse los botones de acuerdo en la parte inferior derecha. Hay incluso un botón para ejecutar automáticamente algunas pruebas de unidad en su instalación.

Fuente : http://ssw.jku.at/dcevm/

Monday, February 23, 2015

JSP sintaxis Parte 2

Scriptles

Usualmente llamamos a todo lo que este dentro de <% %> scriptles pero como vemos hay diferentes tipos de elementos

En el caso de los Scriptles

son basicamente funcionalidades que podemos hacer en un JSP como declaras variables (locales) hacer iteraciones de elementos (while, for) y todo lo mismo que puedes hacer dentro de un metodo lo puedes hacer aqui, hasta declarar clases internas ;)




<html>
<body>
<%
    // This scriptlet declares and initializes "date"
    System.out.println( "Evaluating date now" );
    java.util.Date date = new java.util.Date();
%>
Hello!  The time is now
<%
    out.println( date );
    out.println( "Your machine's address is " );
    out.println( request.getRemoteHost());
%>
</body>
</html>

JSP Sintaxis Parte 1

sintaxis en JSP?

Basicamente es codigo "java insertado en un archivo JSP, que nos ayuda a poder generar procesos o funcionalidades combinados con Html (Scriptles, expressions, directives, declarations).

Pero un momento..

si, es cierto los scriptles son antiguos y ya no usados pero siempre es bueno tener conocimiento de este debido a que apuede que algun dia nos toque algun proyecto del año de la piedra (Dios nos protega y ampare :c ) y tengamos que tocar scriptles.


Todo JSP creado en nuestro proyecto pasa por una fase de traduccion el cual toma el archivo JSP y lo convierte a Servlet luego viene la etapa de compilacion.




Si! estas en lo cierto, asi es como nuestro codigo java en un JSP puede ser entendido por nuestro servidor por que todo es  compilado a codigo Java, todo JSP es un servlet y por lo tanto es codigo Java.

Ahora que tenemos eso claro (eso espero T_T) sigamos con los elementos que podemos usar en nuestros JSPs

Tipos de elementos en JSP

Scriptles:

<html>
<body>
The page count is:
<% out.println(Counter.getCount()); %>
</body>
</html>
Expression:
<html>
<body>
The page count is now:
<%= Counter.getCount() %>
</body>
</html>
Directives:
<%@ page import=”foo.*” %>
<html>
<body>
Hello World!!
</body>
</html>


Declarations:
<html>
<body>
<%! int x=0 %>
</body>
</html>



ver siguiente post Scriptles


Friday, April 18, 2014

A little background on TDD and BDD

I won’t go deep into Test Driven Development (TDD) theory since it’s a bigger subject than I can cover in this article. Many articles on the web go into detail on the subject. What’s important here are the basics of the process and of how they relate to BDD. BDD uses TDD as a starting point, and then takes it a few steps further.
TDD emphasizes writing unit tests (ideally) at the beginning of the application development process to help the developer design the code. Essentially designing your object and method interfaces through the test, and refactoring the code and tests and the code matures. The tests are often written as a white box test- inside-out which tests the specific implementation of a piece of code.
In a nut-shell, TDD suggests the user take the following steps when developing:
  1. Before any coding starts, write a test to design the code against a specification.
  2. Run the test. The test fails because there isn’t any code in place to support the code.
  3. Write some code.
  4. Test.
  5. Refactor.
  6. Test again and fix bugs and implementation.
BDD is an agile software development technique that also emphasizes writing unit tests. A difference is that instead of focusing on the inside-out test approach, it approaches the test from a business value perspective which tests outside-in. In doing so, test authors focus on why a piece of code is necessary, and what its goal is.

Test Syntax

A sample QUnit test case looks like the following code:
// your applications custom code function addValues( a, b ) {     return a + b; }; // the QUnit test code test("test addValues(a, b) function", function() {     equal(addValues( 1, 2), 3, "1 + 2 = 3" );     equal(addValues( 1.75, 2), 3.75, "1.75 + 2 = 3.75" );     notEqual(addValues( 1, 2), "3", "1 + 2 != '3' as a String"); });
A sample Jasmine test case is written as follows:
// your applications custom code function addValues( a, b ) {     return a + b; }; // the Jasmine test code describe("addValues(a, b) function", function() {     it("should equal 3", function(){         expect( addValues(1, 2) ).toBe( 3 );     });     it("should equal 3.75", function(){         expect( addValues(1.75, 2) ).toBe( 3.75 );      });     it("should NOT equal '3' as a String", function(){         expect( addValues(1, 2) ).not.toBe( "3" );     }); });
Notice both Qunit and Jasmine are testing the same things. But the Jasmine approach is easier to read, even for someone who does not know JavaScript. And if you have written Agile user stories, the structure of the test narrative also looks familiar, similar to the standard Agile user story format:

As an <actor> I want to <action> so that <achievment>

source : http://www.adobe.com/devnet/html5/articles/unit-test-javascript-applications-with-jasmine.html

Testing Javascript : Introduction to Jasmine

What is Jasmine?

Jasmine is an automated testing framework for JavaScript.
Testing in a nutshell: basically, your program will have a bunch of functions and classes. You want to make sure that, no matter what you throw at them, they'll perform how you want them to. For example, this function should always return a string that says "hello" in it. Testing ensures that everything goes down exactly how you planned. It's like you're God...but it's probably a little more boring because it's code.
If you've used languages other than JavaScript before, you might use JavaScript and get angry. If you've used other testing frameworks, I am sorry if the same frustration happens while you use Jasmine -- she changes the names of some stuff and she also makes fun of you. She called me a "turd-faced coward".
Jasmine is a testing framework for JavaScript. Let's learn all of her secrets.

Jasmine Test Syntax:
To create a suite of tests we basically need 2 functions:
describe(): groups tests together providing also setup and teardown hooks.
it(): contains the test itself
Suites: describe Tests:
A test suite begins with a call to the global Jasmine function describe with two parameters: a string and a function. The string is a name or title for a spec suite – usually what is under test. The function is a block of code that implements the suite.
Specs:
Specs are defined by calling the global Jasmine function it, which, like describe takes a string and a function. The string is a title for this spec and the function is the spec, or test. A spec contains one or more expectations that test the state of the code under test.
Expectation:
An expectation in Jasmine is an assertion that can be either true or false. A spec with all true expectations is a passing spec. A spec with one or more expectations that evaluate to false is a failing spec. Expectations are built with the function expect which takes a value, called the actual. It is chained with a Matcher function, which takes the expected value.
Syntax:
1
2
3
4
5
describe('Hello world', function() {
it('says hello', function() {
expect(helloWorld()).toEqual("Hello world!");
});
});
So let’s write a simple unit test for a function validating an email address. Let’s write the tests first.
Edit a file under the spec folder called index.js, with:
1
2
3
4
5
6
7
8
9
10
11
12
describe("Email validation", function() {
it("should validate info@<span class="skimlinks-unlinked">knoldus.com",function</span>(){
var result = isEmail_valid("info@<span class="skimlinks-unlinked">knoldus.com</span>");
expect(result).toBe(true);
});
it("should not validate info@knoldus",function(){
var result = isEmail_valid("info@knoldus");
expect(result).<span class="skimlinks-unlinked">not.toBe(true</span>);
});
});
As you can see I used one of the built in expectations called toBe() with the relativenot.toBe(), which is the logical not. It checks the return value from the isEmail_valid() function.
1
2
3
4
function isEmail_valid(email){
var pattern =/^[+a-zA-Z0-9._-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,4}$/i;
return <span class="skimlinks-unlinked">pattern.test(email</span>)
};
And finally load spec.html and see the results:
Selection_001
Just for curiosity let’s change the second test to:
1
2
3
4
5
it("should not validate info@knoldus",function(){
var result = isEmail_valid("info@knoldus");
expect(result).toBe(true);
});
});
Now, the second test should fail:
Selection_002
And in fact it does!
sources :
http://blog.knoldus.com/2013/03/11/jasmine-test-cases-part-1-unit-testing-javascript-in-phonegap-application/
http://evanhahn.com/how-do-i-jasmine/