Configurar SyntaxHighlighter en tu blog

Esta configuración está probada para blogger.com, pero quizá tengas wordpress, drupal,
joomla, o algún otro y no funcione del todo bien, en ese caso es
mejor que consultes el sitio original para una mejor ayuda y soporte
en: http://alexgorbatchev.com/
1. Primero apuntar al core de Syntax Highlighter.

<link href='http://alexgorbatchev.com/pub/sh/current/styles/shCore.css' rel='stylesheet' type='text/css'/>
<link href='http://alexgorbatchev.com/pub/sh/current/styles/shThemeDefault.css' rel='stylesheet' type='text/css'/>
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shCore.js' type='text/javascript'/>

Patrones de Diseño

Una lista de patrones de diseño

Patrón	Tipo	Otros nombres
Abstract Factory [fabrica abstracta]	de creación
Adapter [adaptador]	Estructural
Bridge [puente]	Estructural
Builder [constructor]	de creación
Chain of Responsability [cadena de responsabilidad]	Comportamiento
Command [comando]	Comportamiento	Action, Transaction
Composite [composición]	Estructural
Decorator [decorador]	Estructural
Facade [fachada]	Estructural
Factory Method [método de fábrica]	de creación
Flyweight [ligero]	Estructural
Interpreter [intérprete]	Comportamiento
Iterator [iterador]	Comportamiento
Mediator [mediador]	Comportamiento
Memento [recuerdo]	Comportamiento
Prototype [prototipo]	de creación
Proxy	Estructural
Observer [observador]	Comportamiento
Singleton [uno solo para siempre]	de creación
State [estado]	Comportamiento
Strategy [estrategia]	Comportamiento
Template Method [método plantilla]	Comportamiento
Visitor [visitante]	Comportamiento

Fuentes:
Una referencia rápida aquí, donde pueden descargar un PDF y sino, escribanme a wdonet@gmail.com, yo lo he de tener.

Mejores prácticas en JBPM

Me tope con un articulo sobre las mejores prácticas al usar JBPM y pues quise hacer una pequeña traducción al español, espero que nos sirva como referencia.

1. Mantén ordenado tu contexto de ejecución. No mezcles variables de proceso con variables del modelo y mantenlo simple.
2. Usa ExceptionHandler solo para asignar valores a variables o notificar errores. El manejo de excepciones en JBPM es distinto a java, pueden ser (A) cachadas por jbpm o (B) no cachadas y ser re-lanzadas al cliente que hizo un signal(). Así que no puedes usar exception-handler por ejemplo para controlar el flujo, es mas agradable cachar excepciones de la aplicacion en un Action y que éste, de acuerdo al error, asigne valores a una variable de contexto que permita al flujo (un Decision) tener el control de que procede.

Repositorios en Maven

Maven se coordina mediante cuatro elementos, los cuales definen una dirección para un punto específico desde lo general a lo específico.

1. groupId, se refiere al grupo, compañía, equipo u organización, considerando la convención para identificadores de grupo, el cual dicta que estos empiecen con el nombre de dominio de la organización en reversa, esto es com.santander para banco Santander por ejemplo.
2. artifactId, un identificador único para el grupo que permita ubicar al proyecto. Generalmente es el nombre del proyecto
   
3. version, un número específico para cada liberación del proyecto y se recomienda un identificador especial para proyectos en desarrollo (SNAPSHOT), y
4. packaging, define el tipo de proyecto que al final es la salida producida, por defecto es 'jar', el cual produce un paquete .jar.
   

Una vez que se instala el proyecto en el repositorio local de maven, éste queda disponible localmente para su uso en cualquier otro proyecto local. Por ejemplo, así se define la ruta que maven utiliza para almacenar un artefacto:

/<groupId>/<artifactId>/<version>/<artifactId>-<version>.<packaging>

Maven además de instalar el paquete en el repositorio seleccionado, también copia el pom.xml del proyecto en la misma ruta con el mismo nombre del paquete pero con extensión .pom y crea un archivo en la ruta hasta el artifactId llamado maven-metadata.xml con la identificación de grupo, artefacto y versiones disponibles.  Esto ese algo útil para maven puesto que permite la inclusión recursiva de paquetes dependientes (dependencies).  Por ejemplo, si defines una dependencia en el pom de tu proyecto hacia el paquete commons-email-1.1.jar y éste a su vez depende del paquete subethasmtp-smtp-1.2.jar (dependencia transitoria), ambos paquetes se descargan automáticamente a tu repositorio local cuando compilas tu proyecto.  De esta manera maven resuelve las dependencias de forma recursiva y con base a archivos checksum (archivos con mismo nombre pero extensión .md5) descarga lo que no se encuentre localmente.  Así también si varios proyectos locales requieren de las mismas dependencias, estas se copian al paquete del proyecto (en el caso de un war o ear por ejemplo) cuando se instalan en el repositorio.

Así mismo, una dependencia se puede incluir en cierto alcance (scope), por ejemplo pruebas (test), de manera que cuando se ejecute una prueba o todo el conjunto de pruebas del proyecto, se utilice dicha dependencia, pero no al momento de compilar. ejemplo JUnit:
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>3.8.1</version>
            <scope>test</scope>
            </dependency>
        <dependency>
solo se utilizaría la dependencia al ejecutar una prueba: mvn test -Dtest=MiPruebaTest o el conjunto de ellas: mvn test

Esto obligaría a que cuando se construya el paquete war o ear no se incluya la dependencia.  Otra forma de eviar que se incluya la dependencia en el paquete del proyecto es asignándole un alcance provided scope, el cual le dice a maven que es necesario para compilar, pero no debe se incluido en la construcción final del proyecto. Es útil por ejemplo cuando desarrollas una aplicación web y necesitas el jar de la API de Servlet para compilar, pero no par incluirla en el paquete final.