Translate

jueves, 17 de marzo de 2011

Apache Shiro


Apache Shiro es un poderoso y fácil de usar framework para la seguridad de nuestras aplicaciones echas en java. Este framework provee autorización, autenticación, criptografía y manejador de sessiones y además puede ser usado en diferentes aplicaciones, desde una aplicación de lineas de comando, una aplicación móvil o empresarial

Shiro proporciona una API para llevar a cabo los siguientes aspectos:

  • Autenticación - que verifique la autenticidad del usuario, a menudo llamada "entrada" del usuario.
  • Autorización - control de acceso
  • Criptografía - proteger u ocultar los datos de miradas indiscretas
  • Gestión de sesiones - el estado del usuario en el tiempo

Shiro también es compatible con algunas características auxiliares, tales como seguridad de aplicaciones web, pruebas unitarias, y el soporte a multi-hilo, pero estos aspectos existen para reforzar las cuatro principales preocupaciones.

Como todos los proyectos apache es open source y ademas es Apache Software Foundation Top Level Project.

Muchas comunidades open-source estan usando Shiro por ejemplo: Spring, Grails, Wicket, Tapestry, Tynamo, Mule y Vaadin, entre otros.

Como siempre dejo links:

http://www.infoq.com/articles/apache-shiro
http://shiro.apache.org/
http://shiro.apache.org/10-minute-tutorial.html



domingo, 13 de marzo de 2011

Skinnability









Siguiendo con los post sobre RichFaces:

http://emanuelpeg.blogspot.com/2011/02/richfaces.html
http://emanuelpeg.blogspot.com/2011/03/arquitectura-de-richfaces.html
http://emanuelpeg.blogspot.com/2011/03/manejo-entre-componentes-en-richfaces.html

Skinnability es la habilidad que tiene RichFaces de darle un mismo estilo a todos sus componentes.

Una importante característica son los skin parameters con estos se puede definir un valor y reusar esto en un selector css. Estos valores puede asociarlos a un particular skin.

Un skin es un simple archivo de propiedades que contiene parámetros y valores. Para crear un skin solo es necesario crear un archivo con la siguiente forma skin_name.skin.properties y es necesario que este dentro del classpath.

Con el objetivo de cambiar el skin por defecto es necesario setear la propiedad org.richfaces.SKIN en el web xml.



org.richfaces.SKIN
skin_name



RichFaces incorpora skins predefinidos, estos son:
  • DEFAULT
  • plain
  • emeraldTown
  • blueSky
  • wine
  • japanCherry
  • ruby
  • classic
  • deepMarine

Estos skin cotienen los parametros usados por Riche Faces para dar el Look and Fell a los componentes de de RichFaces.

Plain sking es un sking que no tiene parámetros es usado para proyectos que tienen su propio css.

RichFaces skinnability también permite asociar custom renders, nuevos skin y skings para nuevos custom componentes.

RichFaces permite cambiar skin es tiempo de ejecución. Permitiendo elegir al usuario un skin que prefiera.

Manejo entre componentes en RichFaces

Siguiendo con los post sobre RichFaces:

http://emanuelpeg.blogspot.com/2011/02/richfaces.html
http://emanuelpeg.blogspot.com/2011/03/arquitectura-de-richfaces.html

Veamos un concepto importante en Richfaces, RichFaces no puede agregar, ni eliminar ningún elemento pero puede remplazar a uno existente. Veamos un ejemplo que gráfica este comportamiento:










Este código a simple vista funciona, pero no es así. OutputText es renderizado al inicio con el valor false en rendered por esta razón el javascript no puede encontrar este elemento. Para seleccionar este problema se debe recurrir a un contenedor para outputText:










Como se puede ver, lo que se refresca es out2 el cual siempre esta presente y de esta forma se refrescara out1.

Arquitectura de RichFaces

RichFaces
Siguiendo con los post sobre RichFaces

http://emanuelpeg.blogspot.com/2011/02/richfaces.html

Ahora vamos a ver un poco su arquitectura. Con RichFaces se puede utilizar componentes Ajax para invocar pedidos asincronos que son automáticamente sincronizados con el árbol de componentes y actualizar un área de la pagina, sin recargar toda la pagina. La siguiente Imagen fue tomada de la documentación de Rich Faces y muestra el camino de procesamiento de un pedido:


Arquitectura RichFaces

Esto no difiere del estandar JSF y no es necesario escribir javascript para usar componentes RichFace Ajax.

La arquitectura del framework esta compuesta en 5 partes:
Filtro Ajax: Esto es esencial para agregar la capacidad Ajax a sus paginas JSF. Este filtro maneja todos los pedidos (ajax y jsf estándar), corrige y valida el código enviado, maneja los scripts, la carga de estilos, recursos de cache, etc. Se debe registrar el filtro en el web.xml
Componentes Ajax: Son similares a los componentes estándar de jsf pero envían pedidos asíncronos.
Contenedores Ajax: El framework soporta contenedores que describen áreas de la pagina web, las cuales van a ser refrescadas sin refrescar toda la pagina web. Se pueden definir varias áreas que van a ser refrescadas en una pagina, sin refrescar la pagina.
Skinnability: Permite agregar a su aplicación JSF la capacidad de skinning (temas)
RichFaces JavaScript Engine: Esto corre en el cliente y maneja las ajax requests y responces esto es manejado por el framework si necesidad de programar el comportamiento ajax, ni javascripts.

Se puede elegir cuando utilizas Ajax request o request estándar de JSF.

martes, 8 de marzo de 2011

Frases graciosas

  • Hay 10 tipos de personas en el mundo: Los que entienden binario, y los que no.
  • Me gustaría cambiar el mundo pero lamentablemente, no me dieron el codigo fuente.
  • Mi software nunca tiene fallos. Simplemente desarrolla características aleatorias
  • La caja decía “Requiere Win95 o superior". Asi que instale Linux
  • La gente dice que si pones un CD de WinXP al reves, escuchas voces satanicas. Pero eso no es nada! Si lo pones normal, te instala Windows!
  • Acabas de recibir un virus gallego. Como los Gallegos no tenemos experiencia en programación, este virus trabaja basado en un sistema de HONOR. Por favor: Borre todos los archivos de su disco duro manualmente. Gracias por su cooperación.
  • Las contraseñas son como la ropa interior. No debes dejarla tirada donde la gente la pueda ver. Debes cambiarla regularmente. Y no debes prestársela a desconocidos.
  • Linux para Servidores, Mac para graficos, Palm para Mobilidad y Windows para Solitario
  • La Inteligencia Artificial no es rival para la Estupidez Natural.
  • Las chicas son como los dominios de Internet, las que te gustan no están disponibles.
  • El código mas dificil de corregir es el que sabes que es imposible que tenga errores.
  • UNIX es basicamente un sistema operativo simple, pero tenes que ser un genio para entender su simplicidad
  • Alerta! Error del Usuario. Por favor reemplacelo y presione una tecla para continuar.
  • “Una imagen vale mil palabras”, pero consume mil veces mas memoria.

Libros sobre smalltalk

Smalltalk
Dejo un link de libros sobre smalltalk, si ven la lista al final hay uno que se llama Programando con Smalltalk de Diego Gomez a simple vista parece interesante lo voy a leer y les cuanto.

Dejo el link:

http://stephane.ducasse.free.fr/FreeBooks.html

jueves, 3 de marzo de 2011

Tutorial de Android



Gracias a JavaHipano encontré este tutorial de Android que esta muy bueno:


Que lo disfruten!

domingo, 27 de febrero de 2011

Validacion por Hibernate Validator


La JSR 303 - Bean Validation propone un API de validación basada en un modelo de metadatos, además establece como principal método de definición las anotaciones, aunque estas también pueden ser especificadas y/o extendidas a través de archivos de configuración XML. Otra de las características interesantes de la JSR 303 es que su API no liga especificamente la ejecución de las validaciones a una capa en particular como podría ser la capa web o la de persistencia, sino que puede ser utilizada desde cualquier punto de la aplicación.
Hibernate Validator es la implementación de referencia de la JSR 303.

Cuando validamos datos es posible que la validación sea puesta en la capa de presentación. Poniendo la validación en la capa de presentación corremos el riesgo de replicarla cuantas pantallas se puedan cargar los datos o si por ejemplo hay que exponer una funcionalidad por un web service o mecanismo remoto. El mejor lugar para las validaciones es la capa de presentación y hibernate validator nos ayuda a escribir estas validaciones por medio de anotaciones o xml.

Hibernate validator permite:
  • Definir validaciones usando XML y/o anotaciones
  • Validación completa y recursiva de objetos
  • Definición a medida de constraints y validadores
  • Personalización de mensajes de error

Las anotaciones más útiles son:

@Length(min=, max=): Chequea si el largo del string se encuentra en el rango indicado.
@Max(value=): Chequea que el valor sea menor o igual que el valor indicado.
@Min(value=): Chequea que el valor sea mayor o igual que el valor indicado.
@NotNull: Chequea que el valor no sea nulo
@Email: Chequea que el valor sea un mail valido.
@Range(min=, max=): Chequea que el valor se encuentre entre el rango especificado.
@Future: Chequea que el valor sea una fecha futura.
@Past: Chequea que el valor sea una fecha pasada.
@Pattern(regex="regexp", flag=): Cheque a que la propiedad machea con la expresión regular, given a match flag (see java.util.regex.Pattern for more information)
@Patterns( {@Pattern(...)} ): Como @Pattern, pero con multiples expresiones regulares.

Veamos un ejemplo de una clase validada por medio de Hibernate Validator:




package org.assembly.fenrir.model.student;

import java.util.Calendar;
import java.util.Date;

import org.hibernate.validator.NotNull;
import org.hibernate.validator.Past;


/**
* class that represents a student
*
* @author emanuel
*
*/
public class Student {

private static final int COUNT_MONTH_IN_YEAR = 12;

private String name;

private String lastName;

private Date birthDate;

private String comment;

public Student(String name, String lastName, Date birthDate){
this.name = name;
this.lastName = lastName;
this.birthDate = birthDate;
}

public Student() { }


@NotNull
public String getName() {
return name;
}

public void setName(String name) {
this.name = name;
}

@NotNull
public String getLastName() {
return lastName;
}

public void setLastName(String lastName) {
this.lastName = lastName;
}

@NotNull
@Past
public Date getBirthDate() {
return birthDate;
}

public void setBirthDate(Date birthDate) {
this.birthDate = birthDate;
}

public String getComment() {
return comment;
}

public void setComment(String comment) {
this.comment = comment;
}


}




Pero como es que se valida? En cualquier punto de la aplicación se puede validar si los datos son correctos en cualquier capa de la aplicación, pero por ejemplo utilizando en la capa de presentación richfaces; este ya hace las validaciones atravez de las anotaciones o xml.

Si utilizas maven y quieres agregar este framework, aca va la dependencia del pom:





org.hibernate

hibernate-validator

3.1.0.GA





Como siempre dejo link:


miércoles, 23 de febrero de 2011

TDD vs BDD vs ASEREJE vs Equipo

A raíz de un post que ley de dos ideas, que me resulto sensacional. Me quede pensando como a travez del tiempo nos pasamos aprendiendo metodologías para que el equipo sea más productivo, en vez de concentrarnos en formar buenos equipos. Nos preocupamos más en la daily meeting que en programador trabaje, pueda trabajar y se sienta feliz con su trabajo.

Tal vez es más fácil diseñar una metodología nueva en vez de preocuparse por el equipo. Por ejemplo, un equipo bien capacitado en una metodología la cual a modificado según su forma de trabajo y de forma que el mismo cree que es más productivo va a ser más productivo que un equipo que sigue la ultima y más top de las metodologías. Además la persona se va a sentir cómoda y feliz con su trabajo.

En conclusión seguir una metodología a raja tabla, hacer cosas inútiles solo por la metodología es una perdida de tiempo. Tiempo que sería más útil para unir al equipo limar asperezas y crear un ambiente agradable para trabajar.

Y recuerden leer www.dosideas.com que esta muy buena esta web.

Apache Chemistry


Apache Chemistry Provee una implementación Open Source de Content Management Interoperability Services (CMIS) Pero que es CMIS? Bueno CMIS es una especificación de OASIS, para mejorar la interoperabilidad de los sistemas Enterprise Content Management (ECM)

CMIS es un conjunto de Web Services pensados para compartir información entre repositorios de contenidos y que buscan la interoperabilidad de los diferentes sistemas ECM.

CMIS está compuesto de los siguientes elementos:
  • Un modelo de dominio, para definir los objetos y relaciones que pueden existir en el repositorio.
  • Un conjunto de APIs de comunicación, Web Services y REST, que permiten a las aplicaciones conectarse, navegar, leer y crear contenidos en los diferentes repositorios.
  • Un lenguaje de consultas, similar a SQL, capaz de definir criterios de búsqueda sobre propiedades, ubicación o "full-text" de los objetos.

Apache Chemistry consiste en los siguientes proyectos:

  • OpenCMIS: CMIS librerias cliente y servidor para Java
  • cmislib: CMIS librerias cliente y servidor para Python
  • phpclient: CMIS librerias cliente y servidor para PHP
  • DotCMIS: CMIS librerias cliente y servidor para .NET

Y Obviamente con Licencia Apache.

Dejo links:

viernes, 18 de febrero de 2011

Maven!!!




Este post es para repasar un poco los aspectos de apache mave...

Maven es un framework de gestión de proyectos Java, basado en POM (Project Object Model), que nos proporciona funcionalidades desde la compilación hasta la distribución, despliegue y documentación de los proyectos.

Maven se basa en patrones y en estándares. Esto permite a los desarrolladores moverse entre proyectos sin la necesidad de aprender como compilar o empaquetar, mejorando de esta forma, el mantenimiento y la reusabilidad.

Que provee maven??

  • Características generales de Maven

    • Convención sobre configuración

      • Si todos estamos de acuerdo en ciertas cosas ¿Para qué configurarlas? Démoslas por hechas y mantengamos la opción de configuración por si fuera necesario

    • Uso de buenas prácticas

      • Por ejemplo ejecutar los test unitarios antes de hacer un deploy o instalación

    • Un ciclo de vida extensible declarativamente basado en fases y goals

      • Facilita automatizar tareas sencillas o todo el proceso de construcción de forma rápida y simple, una única orden

    • Un modelo centralizado y transparente de gestión de dependencias

      • Se acabó el “Jar Hell”, el buscar jars por internet y las dependencias de estos jars, o casi del todo…

El principal objetivo de maven es permitir a un desarrollador comprender el estado completo del esfuerzo del desarrollo en el período más corto de tiempo. Para lograr este objetivo existen distintas áreas de las que maven se ocupa:

  • Hacer el proceso de construcción sencillo.

  • Proporcionar un sistema de construcción uniforme

  • Proporcionar información de la calidad del proyecto.

  • Proporcionar lineamientos a seguir para el desarrollo de las mejores prácticas.

  • Permitir migraciones transparentes a nuevas características.

Maven utiliza el término artifact para denominar a la unidad mínima que maneja en su repositorio. Puede ser por ejemplo un jar, un ear, un zip, etc. Cuando Maven compila y empaqueta código, produce también artifacts que instala en el repositorio.

Los artifacts están agrupados bajo el id de grupo (groupId) y tienen un id propio (artifactId), una versión, un clasificador y una extensión.

Maven está basado en torno al concepto de ciclo de vida de build (build lifecycle). Esto significa que el proceso para construir y distribuir cualquier artifact (proyecto) está claramente definido.

Para la persona que construye un proyecto, esto significa que solo debe aprender un número pequeño de comandos para construir cualquier proyecto Maven.

Existen tres ciclos de vida built-in con Maven: default, clean y site.

Default

Administra hasta el proceso de deployment

Clean

Administra las tareas de reseteo del build anterior

Site

Administra la creación del sitio de publicación del proyecto

Cada uno de los ciclos de vida está definido por una lista de fases, donde cada fase representa una etapa en el ciclo de vida.

Este ciclo de vida define la secuencia de fases que va desde validar la integridad hasta el despliegue (deploy).

Cuando se solicita la ejecución de una fase Maven ejecuta primero todas las fases anteriores siguiendo la secuencia y termina en la fase solicitada.

Las principales fases del ciclo de vida default de maven son:

validate

Valida si el proyecto es correcto y si tiene toda la información necesaria

compile

Compila el código fuente del proyecto

test

Corre los test utilizando el framework de unit test disponible

package

Toma las clases compiladas y recursos y crea un paquete (jar, war, ear).

integration-test

Procesa y despliega el paquete, para que corran las pruebas de integración.

verify

Ejecuta los chequeos necesarios para verificar que el paquete cumple los criterios de calidad.

install

Instala el paquete en el repositorio local para ser usado como dependencia por otros proyectos localmente

deploy

Copia el paquete a un repositorio remoto para ser compartido con otros usuarios y proyectos.


Las fases del cilo de vida clean:

pre-clean

Ejecuta los procesos necesarios, previos al clean

clean

Remueve todos los archivos generados en un build previo

post-clean

Ejecuta los procesos necesarios para finalizar el clean


Las fases del ciclo de vida site:

pre-site

Ejecuta los procesos necesarios, previos a la generación del site

site

Genera el site con la documentación del proyecto

post-site

Ejecuta los procesos necesarios para finalizar la creación del site

site-deploy

Realiza un deploy del site de documentación, en el web Server especificado.



Tener en cuenta que para el deploy del site, debemos configurar el web Server.







website
scp://www.mycompany.com/www/docs/project/




Bueno hasta aquí un maven, repaso general.


sábado, 12 de febrero de 2011

RichFaces


RichFaces es un framework web que combina las tecnologías Ajax con JSF. Lo cual permite hacer aplicaciones web con ajax de forma fácil sin preocuparse por mantener complicados métodos javascripts.
RichFaces es un proyecto open sources que permite agregar capacidades Ajax a su aplicación JSF sin escribir javascript por lo tanto sin preocuparse por la compatibilidad entre distintos browsers.

RichFaces provee 2 conjuntos de librerías:
  • Core Ajax: Contiene componentes que son útiles para “ajaxiar” las paginas jsf y los componentes estándares de JSF. También provee componentes que generan recursos binarios como imágenes, pdfs, cvs, etc.
  • UI: Es un conjunto avanzado de etiquetas Jsf que utilizan Ajax usados para agregar características de una interfaz rica de usuario en su aplicación. Estos componentes soportan Ajax y están perfectamente integrados a la librería Core. Además soportan skills y pueden ser totalmente adaptados a sus necesidades.

Otra característica de RichFace es Component Development Kit (CDK) el conjunto de herramientas usado para crear la libraría UI, y puede ser utilizado para crear nuevos componentes.


Este post explica solo un poco de RichFaces, en futuros post veremos como hacer una aplicación con este framework.

miércoles, 9 de febrero de 2011

PHP for Android project (PFA)


PHP for Android project (PFA) es una plataforma que nos permite programar en PHP sobre Android. Y además nos provee de la documentación y herramientas

Además esta bajo Licencia Apache!!






martes, 8 de febrero de 2011

Erjang


Erjang no es otra cosa que una mv escrita para correr erlang sobre la plataforma java.

Como trabaja esto? Lo que permite erjang es pasar un .beam a un .class lo que permite que este corra en la jvm. Además también tiene una consola interactiva.

Este proyecto esta en pañales pero le veo mucho futuro.

Dejo links:
http://groups.google.com/group/erjang
https://github.com/trifork/erjang/wiki

jueves, 3 de febrero de 2011

JBoss Seam


JBoss Seam es un framework que integra y unifica los distintos standars de la plataforma Java EE 5.0, pudiendo trabajar con todos ellos siguiendo el mismo modelo de programación.
Ha sido diseñado intentado simplificar al máximo el desarrollo de aplicaciones, basando el diseño en Plain Old Java Objects (POJOs) con anotaciones. Estos componentes se usan desde la capa de persistencia hasta la de presentación, poniendo todas las capas en comunicación directa.

El núcleo principal de Seam está formado por las especificaciones Enterprise JavaBeans 3 (EJB3) y JavaServer Faces (JSF).
A grandes rasgos podemos definir EJB3 como una arquitectura para un sistema transaccional (como bases de datos) de objetos distribuidos basado en componentes que permite construir aplicaciones portables, reusables y escalables.
JSF es un framework de la capa de presentación que define componentes para el interfaz gráfico y "managed beans" para la lógica de la aplicación que interactúan a travé de un sistema de eventos.

Sin embargo, estos frameworks tienen algunas limitaciones y no han sido concebidos para trabajar juntos (esto pretende resolverse con la futura especificación web beans ); tienen distinto tipo de configuraciones (JSF usa archivos XML mientras que EJB3 usa anotaciones), distinto ciclo de vida y no pueden comunicarse directamente a nivel de framework.
Para hacerlos cooperar necesitaríamos escribir "clases fachada" y multitud de código de relleno que se encargase de pasar las llamadas de una capa de la aplicación a otra. Ahí es donde entra en juego Seam.
Seam elimina la barrera existente entre estas tecnologías, permitiendo usar EJBs directamente como "backing beans" de JSF y lanzar o escuchar eventos web.