14
abr
14

Heartbleed

Heartbleed es, probablemente, una de las fallas de seguridad más graves en toda la historia de internet. En términos generales, consistía en un método a través del cual se podía robar información con mucha facilidad de los servicios más importantes del mundo. Aunque ya la resolvieron, los expertos recomiendan que la mayoría de las personas cambien sus contraseñas, pues muchos sitios se vieron comprometidos.
Es muy recomendable que las personas que tienen cuenta en los siguientes servicios cambien su contraseña lo más pronto que puedan: Facebook, Pinterest, Tumblr, Google, Yahoo, Gmail, servicios web de Amazon, Dropbox y Sound Cloud. Todos esas páginas usan el protocolo a través del cual se formó la vulnerabilidad. Ni Twitter ni Hotmail se vieron comprometidos por ello.
Sobra decir que la vulnerabilidad se haya manifestado en todos estos sitios no significa que nos van a hackear a todos, pero nunca sobra un saludable cambio de contraseña. Esa es una de las prácticas más recomendadas por los especialistas en seguridad y la mejor manera de evitar que lo hackeen. Recuerden que en algunos de esos sitios ustedes pueden tener información bancaria y otros datos que pueden resultar comprometidos.

Todas las empresas ya anunciaron que arreglaron el problema, lo que quiere decir que la nueva contraseña será segura.

02
oct
13

MVC – Model View Controller (Patrón de diseño)

MVC es un patrón de diseño, que se ubica en la categoría de patrones arquitectónicos; este patrón se especifica bajo la proposición de dividir la aplicación en tres tipos de elementos, el modelo, las vistas (GUIs) y controladores. Estos elementos están separados por límites abstractos lo que convierte a MVC más paradigma que patrón, ya que la comunicación entre sí a través de esos límites no se especifica más. La manera en que los elementos dentro de MVC se comunican difieren y no sólo lo diferencia el tipo de aplicación que se está describiendo (Desktop, WEB),  sino también por la parte de la aplicación que actualmente está mirando (frontend, backend).

MVC

MVC

Sin embargo, en el centro de cada arquitectura MVC se encuentran presentaciones separadas lo que declara una división especifica entre los objetos de dominio que modelan nuestra percepción del mundo real (modelo de objetos), y la presentación de dichos objetos que son los elementos de la GUI que vemos en la pantalla (objetos de vista).

MVC define la separación de estos tres tipos de elementos:

  1. Modelo: elementos (objetos) que contienen los datos y definen la lógica para manipular dichos datos. A menudo los objetos tienen una naturaleza reutilizable, distribuida, persistente y portátil para una variedad de plataformas.
  2. Vista: hace referencia a los elementos que representan algo visible en la interfaz de usuario, por ejemplo, un panel o botones. Con el fin de mostrar datos de los objetos de modelo es posible que desee crear sus propios objetos personalizados, como un gráfico, por ejemplo.
  3. Controlador: actúa como un mediador entre los objetos del modelo y la vista . Un objeto Controller comunica datos de ida y vuelta entre los objetos del modelo y de la vista. Un controlador también realiza todas las tareas específicas de la aplicación, tales como la entrada del usuario o la carga de procesamiento de datos de configuración. Por lo general un se puede ver un controlador por aplicación o ventana, en muchas aplicaciones, el controlador está estrechamente acoplado a la vista. Dado que los controladores son específicos de aplicaciones por lo general es muy difícil encontrar reutilización en otras aplicaciones.

Diseño de una aplicación estrictamente de acuerdo con MVC no es siempre recomendable. Si está diseñando un programa intensivo de gráficos, probablemente tendremos muy pocas vistas y clases de modelo mucho más de lo que sugiere MVC. y al programar una aplicación muy simple es común combinar el controlador con las clases de vista. por otro lado el paradigma MVC no es necesariamente específico para lenguajes de programación orientados a objetos. Por ejemplo, una aplicación escrita en PHP no siendo orientada a objetos, también puede seguir los principios del patrón Modelo Vista Controlador utilizando sistemas de plantillas o marcos MVC diseñado para PHP.

El campo de aplicación de este patrón es bastante amplio casi se puede utilizar en cada aplicación. por supuesto dependiendo de la aplicación puede que algunas clases deben acoplarse a otras más que en otras aplicaciones, sin embargo, en general, siempre es una buena idea estructurar la aplicación en orden a MVC.

El patrón MVC en su implementación embebe diferentes patrones dependiendo de la  naturaleza de la aplicación que se está diseñando. Es común encontrar cosas como Intercepting Filters, View Helpers, Composite Views, Front Controllers, Value Objects, Session facades, Business Delegates y Data Access Objects que son utilizados por el patrón de arquitectura MVC, dentro de las cuales podemos resaltar:

Observer: este patrón es usado entre el Modelo y la Vista. Cuando los datos que están almacenados en los objetos del modelo sufren cambios, los objetos de la vista tienen que ser notificados y/o actualizados con respecto a la información con los cambios más reciente. Con el fin de mantener el acoplamiento entre los componentes Modelo/Vista y también debido al hecho de no tener varias instancias de objetos Vistas, el patrón Observer es el candidato ideal para lograr esto.

Estrategy: frecuente mente se implementa a nivel de modelo. El patrón DAO (Data Acces Object) es una forma del patrón de Estrategy que es utilizado  sobre todo por el modelo para acceder a diferentes formas de fuentes de datos. Por ejemplo, una base de datos MySQL/PostgreSQL, o archivos XML  almacenados en el disco.

Composite: utilizado por la Vista. No puede existir diferentes tipos de vistas dentro de un sistema diseñado de acuerdo con MVC, y alineandose a la finalidad de que todas las implementaciones sean compuestas y cambiadas a petición en tiempo de ejecución, se utiliza el patrón de Composite.

EJEMPLO DEL PATRÓN MVC EN JSP 

Ejemplo MVC en JSP

Ejemplo MVC en JSP

Referencias

Applications Programming in Smalltalk-80(TM)

Modelo Vista Controlador[Wikipedia]

The Ohio State University Software Development in Java Course 2009[Lecture 23]

Seminar Software Entwurf – Leif Singer

Designing Enterprise Applications with the J2EE Platform

Pattern Concepts – Oracle

16
sep
13

Patrones Arquitectónicos

Los patrones arquitectónicos se utilizan para expresar una estructura de organización base o esquema para un  software. Proporcionando un conjunto de sub-sistemas predefinidos, especificando sus responsabilidades, reglas, directrices que determinan la organización, comunicación, interacción y relaciones entre ellos.

Los patrones arquitectónicos heredan mucha de la terminología y conceptos de patrones de diseño, pero se centran en proporcionar modelos y métodos re-utilizables específicamente  para la arquitectura general de los sistemas de información. En otras palabras quiere decir que a diferencia de los patrones de diseño estas son plantillas incompletas y no se pueden aplicar directamente al código con modificaciones meramente contextuales. Los patrones arquitectónicos a su vez se salen del código puro de la aplicación y suben e incluyen software, hardware, redes, inclusos las personas.

Dentro de los patrones arquitectónicos podemos encontrar:

  • Modelo Vista Controlador: es uno de los modelos más antiguos (Smalltalk-80)  y por lo tanto se convirtió en uno de los patrones fundamentales para el desarrollo de software. MVC a grandes trazos, separa las preocupaciones con respecto a los datos (modelo) y la interfaz de usuario (vista/GUI), permitiendo modificaciones independientes en cada una  las partes sin afectar la otra, o sea, para que los cambios realizados en la interfaz de usuario (GUI) no afectan el manejo de datos, y los datos pueden ser reorganizados sin cambiar la interfaz de usuario.
  • Inyección de Dependencias: es un patrón que a pesar de ser relativamente nuevo es muy complejo. La utilización de inyección de dependencia en un proyecto es tan incidente, que puede modificar en grandes proporciones la arquitectura, de modo que se hace prudente una planificación a futuro sobre la utilización de este patrón. Este patrón puede dar la impresión de ir un poco “al revés”, porque el mismo, se trata de una aplicación de la “Inversión de Control – IoC”, concepto que hace exactamente eso, se invierte el flujo de control. El nombre de “la inyección de dependencia” en realidad se presta a confusión, ya que el modelo permite que se inyecte no dependencias en sí, sino en su lugar, la información para satisfacerlas la relación a las dependencias.
  • Arquitectura dirigida por eventos (Event-driven architecture o EDA): es un patrón de arquitectura software que para orquestar su comportamiento se centra en torno a la producción, detección, consumo y respuestas ante “eventos”. Teniendo en cuenta que un evento es: cualquier ocurrencia identificable que tiene un significado para el hardware o el software del sistema, en otras palabras, cualquier cambio de estado significante para el sistema. Y a su vez este cambio de estado puede ser conocido por otras aplicaciones en la arquitectura, o sea, que cada evento se propaga de manera inmediata a otras partes del sistema en la medida que sea necesario.
  • Arquitectura orientada a servicios: La ‘Arquitectura Orientada a Servicios de cliente’ (Service Oriented Architecture), es un concepto de arquitectura de software donde el software consta de una composición de servicios, prestaciones y reglas, y son los requisitos del negocio los que dictaminan la manera en la que estas se ínter-relaciona. Esta diseñado para que el sistema sea altamente escalable y flexible a nuevos requerimientos.

Referencias

http://www.omg.org/soa/Uploaded%20Docs/EDA/bda2-2-06cc.pdf

http://searchsoa.techtarget.com/definition/event-driven-architecture

http://download.boulder.ibm.com/ibmdl/pub/software/dw/webservices/ws-soa-whitepaper.pdf

http://download.microsoft.com/download/e/9/d/e9d163db-5c96-46bc-9263-aac62fc38831/Service%20Oriented%20Architecture.pdf

13
sep
13

Become a Programmer, Motherfucker

Entre tantas páginas que visito ayer me encontré con esta. que a pesar de su publicidad fuera de lo común también brinda un buen contenido aunque está todo en inglés:

Become a Programmer, Motherfucker

Become a Programmer, Motherfucker

11
sep
13

Delegation (Patrón de diseño)

Para cerrar la parte de patrones fundamentales, trataremos el patrón de delegación, este patrón ha sido descrito como una manera de realizar “herencia múltiple manualmente mediante composición de objetos”.

Delegation, se trata de una técnica en la que un objeto permite mostrar cierto método al exterior, pero internamente la implementación o las acciones desencadenadas por el llamado de este método se delega a otro objeto de una clase distinta pero asociado. La delegación es utilizada como un mecanismo para centralizar en torno a un solo objeto  los compartimentos(métodos) de varios objetos donde dichos comportamientos mantienen cierto nivel de relación.

 

 

Podemos implementar Delegation de dos maneras, (1) la primera es haciendo uso de objetos dentro de otro (composición) y (2) la otra manera es la utilización de interfaces; permitiendo que la implementación del patrón pueda ser realizada, sin embargo en ocasiones la relación deseada entre clases es de contención en vez de herencia. Delegation no se limita solo a escenarios donde se debe evitar la herencia múltiple (la herencia múltiple no es permitida en Java) , pero se puede ver como una alternativa general a la herencia.

Este patrón se usa comúnmente en casos donde:

  • Se desea reducir el acoplamiento de métodos para una clase.
  • Existen componentes que tienen comportamientos similares, pero que en un futuro es posible que se realicen cambios.
  • Se desea remplazar la herencia, generalmente se usa la delegación como alternativa a la herencia.

Hay que tener en cuenta que la herencia a pesar de ser una buena estrategia para ser utilizada cuando existe una estrecha relación entre las clases involucradas, no es recomendada cuando la relación no es tan estrecha, ya que se crea una lazo de dependencia directa entre las clases; por otra parte la delegación es la forma más flexible para expresar una relación entre clases.

 

Ejemplo con clases:

package ingenio.ds.examples.patrones;
public class Clases{
	public static void main(String args[]){
		System.out.println("Usando el SuperAutoMovil");
		SuperAutoMovil superAutoMovil= new SuperAutoMovil();
		System.out.println("-- Funciones de AutoMovil:");
		superAutoMovil.iniciarMotor();
		superAutoMovil.andar();
		
		System.out.println();
		System.out.println("-- Funciones de Subergible:");
		superAutoMovil.navegar();
		superAutoMovil.navegarMasProfundo();
		superAutoMovil.navegarMasSuperficial();
		
		System.out.println();
		System.out.println("-- Funciones de Helicoptero:");
		superAutoMovil.volar();
		superAutoMovil.volarMasAlto();
		superAutoMovil.volarMasBajo();
	}
}

class Barco{
	public void iniciarMotor(){
		System.out.println("Barco: iniciando motor");
	}
	public void andar(){
		System.out.println("Barco: andando");
	}
}

class Automovil{
	public void iniciarMotor(){
		System.out.println("Automovil: iniciando motor");
	}
	public void andar(){
		System.out.println("Automovil: andando");
	}
}

class Helicoptero {
	public void iniciarMotor(){
		System.out.println("Helicoptero: iniciando motor");
	}
	public void andar(){
		System.out.println("Helicoptero: andando");
	}
	public void descender(){
		System.out.println("Helicoptero: descendiendo");
	}	
	public void ascender(){
		System.out.println("Helicoptero: ascendinedo");
	}
}

class Subergible extends Barco{
	public void descender(){
		System.out.println("Subergible: descendiendo");
	}	
	public void ascender(){
		System.out.println("Subergible: ascendinedo");
	}
}


class SuperAutoMovil extends Automovil{
	private Subergible  sumergible;
	private Helicoptero helicoptero;
	
	public SuperAutoMovil(){
		sumergible =new Subergible ();
		helicoptero=new Helicoptero();
	}
	
	public void andar(){
		super.iniciarMotor();
		super.andar();
	}
	
	public void navegar(){
		sumergible.iniciarMotor();
		sumergible.andar();
	}
	
	public void volar(){
		helicoptero.iniciarMotor();
		helicoptero.andar();
	}
	
	public void volarMasAlto(){
		helicoptero.ascender();
	}
	
	public void volarMasBajo(){
		helicoptero.descender();
	}
	
	public void navegarMasSuperficial(){
		sumergible.ascender();
	}
	
	public void navegarMasProfundo(){
		sumergible.descender();
	}
}

 
Ejemplo con interfaces:

package ingenio.ds.examples.patrones;

public class Interfaces {
	public static void main(String args[]) {
		Automovil automovil = new Automovil();
		automovil.andar();
		automovil.setMotor(new MotorElectrico());
		automovil.andar();
	}
}

interface Motor{
	public void andar();
}

class MotorVapor implements Motor {
	public void andar() {
		System.out.println("Aumenta persión");
		System.out.println("Aumenta velocidad");
	}
}

class MotorElectrico implements Motor {
	public void andar() {
		System.out.println("Aumenta revoluviones");
		System.out.println("Aumenta velocidad");
	}
}

class  Automovil{
	private Motor motor = new MotorVapor();
	
	public void andar() {
		motor.andar();
	}
	
	public void setMotor(Motor motorNuevo) {
		motor = motorNuevo;
	}
}

 

06
sep
13

Programar en simple (tutoriales java EE)

Excelente fuente de recurso Java EE…

Chapter 1: Introduction

Chapter 2: Just Enough Of: Database Design

Chapter 3: JPA 2.0( Java Persistence API 2.0)

Chapter 4: EJB 3.1( Enterprise Java Beans 3.1)

Chapter 5: JSF 2.0( Java Server Faces 2.0)

Chapter 6: JMS ( Java Message Service)

Chapter 7: JAX-RS( Java API For RESTful Web Services)

Chapter 8: CDI( Contexts And Dependency Injection)

 

 

06
sep
13

Container (Patrón de diseño)

Container o patrón de contenedores, Un contenedor es un objeto creado para contener otros objetos  y permite agregar, acceder, modificar, eliminar, en otras palabras, un contenedor debe almacenar otros objetos y permitir su gestión a través de los métodos proporcionados por la clase contenedora [en java ya existe la API Collections que describe una serie de contenedores] – colas, pilas, listas, vectores. Estos objetos (los elementos contenidos) por lo general son de tipo Object, y por herencia pueden ser de cualquier tipo  incluso pueden ser de la misma clase del contenedor. Cada Container debe implementar algún tipo de iterador asociado para permitir recorrer los elementos contenidos.

El término contenedor en la programación informática moderna realidad puede referirse a muchas cosas:

  • Los programadores de Java, C# suelen llamar a este tipo de clases de “colecciones” en lugar de “contenedores”. la Java Collections Framework proporciona implementaciones para muchos tipos de clases Container, una implementación típica de una clase de colección en Java sería ArrayList o HashMap.
  • Dentro del Framework  Spring los contenedores representan conceptos de más alto nivel, tales como la inversión de control (IoC). una explicación (en inglés) de lo que es IoC e inyección de dependencias  Inversion of Control Containers and the Dependency Injection pattern [Martin Flower].
  • Beans Enterprise son componentes de software que se ejecutan en un entorno especial llamado un contenedor EJB. Los contenedores sirven de hots y gestionan un “enterprise bean” de la misma manera que el Java Web Server aloja un servlet o un navegador HTML alberga un applet de Java.

Los usos más comunes del patrón Container son:

  • Quiere representar un grupo de objetos como uno solo.
  • Desea reutilizar funcionalidades para almacenar diferentes tipos de objetos.

Todo el código está encapsulado en unsolo archivo java

package ingenio.ds.examples.patrones;

/*definición de la interfaz mensajero*/
package ingenio.ds.examples.patrones;
import java.util.Iterator;

public class Main {

    public static void main(String[] args) {
        // Contenedor de Integer
        Contenedor contenedorEntero = new Contenedor();
        contenedorEntero.agregar(1);
        contenedorEntero.agregar(2);
        contenedorEntero.agregar(3);

        //Contenedor de String, solo soporta objetos String
        //contenedorCadena.add(1); genera error de compilacion
        Contenedor contenedorCadena = new Contenedor();
        contenedorCadena.agregar("uno");
        contenedorCadena.agregar("dos");
        contenedorCadena.agregar("tres");

        //Contenedor de Object, soporta objetos de cualquier clase
        Contenedor conetendorObject =new Contenedor();
        conetendorObject.agregar(new Integer(0));
        conetendorObject.agregar(new Double(0));
        conetendorObject.agregar(false);
        conetendorObject.agregar("String value");
        conetendorObject.agregar(0F);

       imprimir(contenedorEntero);
       imprimir(contenedorCadena);
       imprimir(conetendorObject);
    }

    public static void imprimir(Contenedor contenedor){
    	//Obtenemos el iterador
    	Iterator iterador = contenedor.iterador();
    	System.out.println("Container: ");
        while (iterador.hasNext()) {
        	Object elemento=iterador.next();
            System.out.println(elemento.getClass() +" - " + elemento);
        }
    }
}

class Contenedor {

	protected Nodo nodoInicial = null;
    protected Nodo nodoFinal = null;

    private class Nodo {
        private E elemento;
        Nodo siguiente = null;
        Nodo anterior = null;

        public Nodo(E elemento) {
            this.elemento = elemento;
        }
    }

    private class Iterador implements Iterator {
        protected Nodo nodoActual = nodoInicial;

		//retorna si tiene mas elemento
        public boolean hasNext() {
            return nodoActual != null;
        }

        //retorna el siguiente elemento
        public E next() {
            if (nodoActual == null) {
                return null;
            }
            E elemento = nodoActual.elemento;
            nodoActual = nodoActual.siguiente;
            return elemento;
        }

        //elimina el ultimo elelento retornado
        public void remove() {
            nodoActual.anterior.siguiente = nodoActual.siguiente;
            nodoActual.siguiente.anterior = nodoActual.anterior;
        }
    }

    public void agregar(E o) {
        if (nodoInicial == null) {
            nodoFinal = nodoInicial = new Nodo(o);
        } else {
            Nodo newnode = new Nodo(o);
            newnode.anterior = nodoFinal;
            nodoFinal = nodoFinal.siguiente = newnode;
        }
    }

    public Iterator iterador() {
        return new Iterador();
    }
}



I+Ds

Dudas consultas
Facebook
Twiter
Google +

Escribe tu dirección de correo electrónico para suscribirte a este blog, y recibir notificaciones de nuevas publicaciones por correo.

Únete a otros 340 seguidores

Redes Sociales y Archivos

Entradas

diciembre 2014
L M X J V S D
« abr    
1234567
891011121314
15161718192021
22232425262728
293031  

IngenioDS en twiter


Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 340 seguidores

A %d blogueros les gusta esto: