Publica tu how-to

Dinos como hacer lo que sabes hacer, mándanos un email a wdonet@gmail.com y lo publicamos (dos días máximo) o si te interesa unirte al equipo de redactores, también háznoslo saber por correo.

Instalar Trac para administrar proyectos

Administrar proyectos es parte que llega a volverse esencial cuando se  trata con proyectos que crecen poco a poco, como es el caso de los proyectos open source. Existe software hecho justamente para facilitar la administración de proyectos de software. En esta ocasión, vamos a hablar sobre Trac, un software hecho en Python con interfaz web para permitir la administración de proyectos.

Trac incluye:
  • un wiki para que el proyecto tenga su propio sitio en linea, y wiki es aun mejor si es un proyecto open source, para que los usuarios y desarrolladores puedan contar con la información más actualizada, de primera mano de parte de los mismos usuarios y desarrolladores
  • un administrador de issues o tickets para permitir estar al tanto de los bugs y sus correcciones, así como las mejoras hechas al software
  • conexión con el repositorio del código fuente del proyecto. Por defecto, Trac se conecta con repositorios SVN, pero permite también otros
  • utiliza una base de datos, ya sea SQLite, PostgreSQL o MySQL
  • otras características más, propias de un administrador de proyectos y que resultan útiles en ciertos momentos

40 años de UNIX

Esta entrada no es un how-to, pero creo pertinente escribir sobre la importancia de este hecho. 2009 es el año en que el sistema operativo UNIX cumple 40 años de haber sido creado en los laboratorios Bell...

De los primeros sistemas en tener éxito como sistema multitarea, el primero en poder ser portado a muchas plataformas gracias al lenguaje C, que prácticamente nació a la par de UNIX, ancestro de sistemas de tanta importancia hoy en día como Linux, openBSD, openSolaris. UNIX es, sin duda, uno de los grandes inventos del siglo XX.

Como pequeño homenaje, una serie de links para narrar la historia de este sistema:


Historia de UNIX, parte 1
Historia de UNIX, parte 2
Historia de UNIX, parte 3
Historia de UNIX, parte 4


saludos!

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'/>

El Zen de Python

    Bello es mejor que feo.
    Explícito es mejor que implícito.
    Simple es mejor que complejo.
    Complejo es mejor que complicado.
    Plano es mejor que anidado.
    Escaso es mejor que denso.
    La legibilidad cuenta.
    Los casos especiales no son tan especiales como para romper las reglas.
    Aunque lo práctico vence a lo puro.
    Los errores nunca deben ocurrir silenciosamente.
    A menos que hayan sido silenciados explícitamente.
    Ante la ambigüedad, rehuye la tentación de adivinar.
    Debería haber una-- y preferiblemente solamente una --manera obvia de hacerlo.
    Aunque esa manera puede no ser obvia de inmediato a menos que seas Holandés.
    Ahora es mejor que nunca.
    Aunque nunca es muchas veces mejor que *ahorita*.
    Si la implementación es difícil de explicar, es una mala idea.
    Si la implementación es fácil de explicar, puede que sea una buena idea.
    Los espacios de nombres son una tremenda gran idea -- ¡hay que hacer más de esos!



(traducido libremente al español por un servidor, del original en inglés)

Configuración de TurboGears 2.0

Introducción
TurboGears es un framework para desarrollar aplicaciones web basadas en el lenguaje de programación Python

La versión 2 está basada en el modelo MVC, con los siguientes frameworks como base:

-SQLAlchemy, el ORM que sirve como Modelo.
-Genshi, el framework que permite manipular la Vista a través de tags específicos.
-Pylons, proporciona el Controlador.

Levantando una sencilla VPN con OpenVPN parte 3

Configuración de la VPN

Generación de llaves (continuación...)
Teniendo claro cómo funciona la seguridad en una VPN, lo que sigue es generar las llaves y
certificados apropiados para poder configurar, ahora sí, la VPN entre las máquinas que deseamos
tener 'cerca'.

OpenVPN viene de por sí con algunos scripts que pueden aprovecharse para la generación del
esquema de seguridad de la red. El único requisito previo es tener instalado el software
OpenSSL, el cual utilizan dichos scripts. (Sin embargo, si instalas desde alguna utilidad de tu
distribución Linux, o desde Windows, el software SSL adecuado se preinstala también, pues es
un requisito previo).

Los pasos en este caso son sencillos:
  1. Se genera el certificado (conocido también como 'llave pública'), así como las llaves privadas tanto para el servidor como para cada cliente.
  2. Se genera un certificado y una llave para el 'master Certificate Authority' (CA), que se utilizan para firmar cada uno de los certificados generados anteriormente.

Configurar la capa de servicios como transaccionales con spring aop

Existen diversos conceptos que ya voy a dar por conocidos en esta publicación como lo son un advice, un target, un pointcut, un advisor y un aspecto, entre otros. Pero pueden conocer mas en la documentación de referencia sobre aop de Spring (inglés).

http://static.springsource.org/spring/docs/2.5.x/reference/images/tx.png
Conceptualmente una transacción luce como la imagen aqui arriba pero vamos a describir un poco mas el detalle.

Primeramente necesitamos la dependencia de spring-aspects, considerando que nuestro proyecto sea maven, debemos agregar a nuestro pom.xml la siguiente dependencia (por ahora usaremos la ón 2.5.6):
<dependency>
<groupid>org.springframework</groupid>
<artifactid>spring-aspects</artifactid>
<version>2.5.6</version>
</dependency>


Basicamente necesitamos configurar tres elementos, (1) el manejador de las transacciones y su fuente de datos o DataSource, (2) un advice que es el código a ejecutar antes y/o despues de una petición a la base de datos punto central para iniciar-propagar-terminar una transaccion, y finalmente (3) un advisor, que es la relación de dicho advice con un pointcut.

Maven-Spring-Aspectos con @Configurable y Weaving

Porqué la mayoría de la gente usa Load Time Weaving (LTW)? Esto requiere reemplazar el javaagent/classloader para tu JVM el cual batalla con el ordenamiento de todas las cosas.
Echemos un vistazo usando mejor el Compile Time Weaving (CTW).
Este ejemplo usa Spring 2.5.2, AspectJ 1.5.4, Java 1.5 (Spring 2.5.4 usa una version posterior de weaver (3.0 contra 5.0) - Asumo que AspectJ 1.6.0 pero el aspectj-mave-plugin está también basado alrededor de la versión 1.5.4, así que por ahora trabajemos con esta combinación.
En Spring, podemos simplemente inyectar recursos a beans normales de Spring, incluso vía la configuración del contexto de Spring, o usando el soporte para anotaciones basadas en inyecciones ((@Resource, @Autowired junto con @Repository, @Service etc).
Sin embargo, beans que son de alcance prototipo (scope="prototype") son más difíciles de manejar. Estas son renovadas (Bean foo = new FooBean();) incluso por el desarrollador o por frameworks externos o (Hibernate para beans del modelo, contenedores de servlet, etc.).
El sitio spring framework provee la anotación @Configurable para esto.

Levantando una sencilla VPN con OpenVPN parte 2

Configuración de la VPN

Una vez que ya se tiene instalado OpenVPN en las máquinas servidor y clientes que serán miembros de la red virtual, hay que configurar correctamente el software, tanto en servicios como en generación de llaves de seguridad para poder tener la VPN funcionando.


Diseño de la red
La primer consideración importante a tener en cuenta es el diseño de la red virtual: qué máquinas formarán parte de la misma, si se formarán subredes dentro de la red virtual, cuestiones de ruteo y redireccionamiento, etc. Además se debe determinar el conjunto de direcciones IP que pertenecerán a las máquinas de la red.

En el RFC 1918, se establece que los rangos siguientes son exclusivos para redes privadas, es decir que ningún sitio en internet, que cualquiera podría ver, debe de tener asignada ninguna dirección de estos rangos, por lo que las múltiples redes privadas que puedan existir, virtuales o no, pueden hacer uso de estas direcciones IP para sus propósitos particulares.

Levantando una sencilla VPN con OpenVPN

¿Qué es una VPN?
VPN significa Virtual Private Network. Una VPN es una red virtual, que se configura para que todas las máquinas pertenecientes a la misma puedan verse como si se encontraran dentro de una misma LAN (Local Area Network), a pesar de poder encontrarse separadas por grandes distancias (y para el contexto del lenguaje de redes, fuera de una misma LAN).


¿Para qué sirve una VPN?
Bueno, pues las aplicaciones son muchas, pero en términos sencillos, se puede aprovechar para:
  • Compartir archivos
  • Establecer conexiones seguras
  • Disponer de servicios entre las máquinas que pertenecen a la VPN, como si estuvieran en una LAN
  • Juegos
  • etc. etc.

ORM : Mapeo Objeto - Relacional

Es una técnica de programación muy utilizada en paradigmas orientados a objetos, que te permite 'mapear' (es decir, emparejar un par de entidades de tu programa): por un lado una base de datos relacional y por otro lado objetos.

Por poner un ejemplo sencillo, una agenda con personas / direcciones y teléfonos.
En la base de datos relacional, pueden haber tablas para:
  1. Las personas, con datos como su nombre completo, edad, género
  2. Los teléfonos, con el dato del número telefónico y relacionados con las personas a través de una llave foránea (si la relación es 1-N) o una tabla de rompimiento (si la relación es N-M)
  3. Las direcciones, con datos para calle, número exterior e interior, colonia, etc. y relacionados con las personas, también a través de una llave foránea.

Por otro lado, en tu programa podrías tener los siguientes objetos:
  1. Un objeto persona, con una propiedad cadena para el nombre, una propiedad entera para la edad, una propiedad de una enumeración para el género.
  2. Un objeto telefono, con una propiedad cadena para el número telefónico.
  3. Un objeto direccion, con una propiedad cadena para cada campo de la misma tabla

Pero además, en tu objeto persona podrías tener lo siguiente:
  1. Una propiedad lista de objetos telefono
  2. Una propiedad de objeto direccion
Y de esta manera, una persona tiene uno o mas números telefónicos, y una dirección asociada.

Ahora bien, el ORM, además de permitirte modelar tu información de manera que utilices objetos para representar las relaciones de la base de datos, también puede permitirte la llamada persistencia. Esta propiedad se refiere al hecho de que, a través del motor del ORM y gracias al mapeo establecido (por ejemplo en un archivo de configuración XML) entre los objetos y las tablas de la base de datos, se consigue que los datos manipulados en los objetos se reflejen en la base de datos, y que cualquier cambio en los objetos mismos dentro del programa permita que el mapeo, además de ser declarativo (que establece el mapeo en sí entre objeto y relación), sea también del contenido.

En los lenguajes orientados a objetos existen muchos motores o frameworks que permiten implementar ORM en un sistema. Sin embargo, a veces es necesario o más sencillo implementar uno propio, con o sin persistencia.

En cuanto a los frameworks existentes, y que pueden usarse para desarrollar sistemas con un ORM, se encuentran por ejemplo:
  • Hibernate, para el lenguaje Java
  • Propel, para el lenguaje PHP
  • SQLAlchemy, para el lenguaje Python
  • Doctrine, también para PHP
  • etc...

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.

Intro a EAF (Enterprise AJAX Framework) de jackbe

Se trata de la parte AJAX de Jackbe y para trabajar con él podemos usar un proyecto en Eclipse con el plugin del EAF. Pero es necesario que Eclipse cuente con la funcionalidad WTP para poder trabajar. El proyecto en Eclipse se conforma por carpetas como:
  • WEB-INF - aquí van los archivos web
  • WEB-INF/jbml - son los archivos fuente de las pantallas web o con lo que se llama'jackbe markup language'.
  • WEB-INF/jsp - son creados de forma automática al crear pantallas jbml y básicamente, invocan al constructor de nuestra pantalla jbml
  • gc.jsp - es un archivo que almacena la configuración global para traerse al núcleo los archivos del EAF. Es de notar que en cada archivo jsp creado de forma automática, se incluye un código como sigue: <jsp:include page="./jackbe/jsp/gc.jsp"/>.
  • jackbe - almacena archivos del núcleo
  • fb - significa 'form behavior', que almacenan el comportamiento de las pantallas a través de programación javascript, así que se trata de archivos '.js'.
  • jf - aquí se guardan los 'jackbe forms' o los archivos compilados de jbml, también son archivos '.js'.
  • rb - resources boundle

Metodología de desarrollo XP

Ciclo de la metodología
  1. Planificación. Escuchar las necesidades del Cliente, hacerlo parte del equipo, pero explicar lo que es fácil de obtener y lo que no
  2. Diseño. Es importante usar patrones de diseño.
  3. Desarrollo. Hacer que el propio código comunique lo que está haciendo.
  4. Pruebas. Realizar pruebas unitarias, puedes usar frameworks muy conocidos como JUnit y DBUnit.
Valores que promueve : | Comunicación | Coraje | Simplicidad | Retroalimentación |

Ventajas:
  • Es un diseño simple
  • Obliga a que funcionen todas las pruebas unitarias, todo el tiempo.
  • Muchos comentan que no tiene, pero yo creo que solo se reduce la lógica duplicada.
  • Suele tener menor número de clases y métodos. Aunque esto depende de la modularidad de la aplicación y que el desarrollador realice un diseño claro, simple y use patrones.
Desventajas:
  • La documentación suele ser pobre.
Buenas prácticas:
  • Realizar un diseño simple
  • Pequeñas versiones. Hacer entregas constantes para que el Cliente perciba el avance y retroalimente las necesidades de negocio que afinen la funcionalidad efectiva de la aplicación.
  • Pruebas. Cada funcionalidad en la aplicacion (front, back, web-services, DAOs, VOs, Utilerías, etc.) debe ser probada.
  • Recodificar. Siempre que veamos código al que se puede aplicar un refactoring, aunque no sea nuestro, es conveniente avisar al equipo y planear su reestructuración a medida que la propia aplicación lo pida.
  • Programar en parejas. Un solo teclado, un solo ratón, una persona codifica, ambos piensan, se logran ideas más estratégicas (es importante que ambos estén abiertos a escuchar las ideas del otro con el fin de mejorar las propuestas planteadas y por consiguiente la aplicación).
  • Integrar una vez al día. Obviamente antes de integrar implica ejecutar las pruebas para validar que todo siga funcionando como lo esperan las pruebas unitarias.
  • 40 hrs por semana máximo permiten estar fresco, descansar 2 días para pensar en nuevas ideas y aplicarlas al inico de semana. Estaría bien disponer de un tiempo a medio día para descansar (siesta, break, tomar un pequeño postre) o despejar la mente realizando otras actividades (juegos de mesa, videojuegos, salas de lectura, reuniones de convivencia). Es parte del modelo laboral japonés y les funciona.
  • Establecer estándares de codificación. Usar un checkstyle y practicar revisiones en parejas del código de otros resulta bastante bueno para la aplicación pues ayuda a detectar posibles errores de estilo e incluso de lógica, de forma que cualquier nuevo integrante que llegue al equipo se familiarice más rápido con el código.

Servidor Linux desde tu hogar Intro 2

Antes de entrar en tema, demos un breve recorrido por los tres pasos para levantar un servidor en tu hogar, para averiguar por qué necesitamos llevarlos a cabo:
  1. Publicar mi dirección IP. Tal vez has notado alguna vez al momento de estar conectado en el hogar, que la dirección IP que tiene asignada tu máquina por parte del ISP es una dirección local, de la LAN creada en tu hogar con el ruteador al que te conectas a Internet. Mientras tanto la dirección IP 'real' que el mundo conoce de la LAN es otra. Puedes visitar algún sitio como este, y podrás notar que aunque tu sistema informa que su dirección IP es una (a través de ifconfig por ejemplo), 'desde afuera', la dirección IP es otra, pues se trata de la dirección con la que en realidad el ruteador de tu LAN se comunica al mundo exterior. El truco en este paso consistirá entonces en hacer que la dirección IP del ruteador con el que te conectas, quede de alguna manera asignada (o más bien ligada) también a la máquina que funcionará como tu servidor.

Servidor Linux desde tu hogar Paso 3

Recordando la localización de mi servidor


Y otra vez los tres incisos:
  1. conseguir el servicio de DNS
  2. configurar el servidor
  3. probar
Servicio de DNS
Lo más recomendable es utilizar un servicio DNS que por un lado ligue la dirección IP de tu servidor/ruteador con un nombre común y fácil de recordar. Por otro lado, en caso de que tengas una dirección IP dinámica, el servicio DNS también debería asociar dinámicamente la nueva dirección IP con el nombre de tu servidor.

Servidor Linux desde tu hogar Paso 2

Levantado mi servidor

De nuevo, este paso se realiza en tres incisos:
  1. configurar el firewall, para la seguridad
  2. instalar, configurar y levantar los servicios en sí mismos
  3. probar
Configurar el firewall
Dependiendo la distribución Linux que tengas, éstas muchas veces ya vienen con utilidades de configuración que permiten establecer la seguridad del firewall en la máquina. Todo lo puedes configurar a través de estas utilidades, o configurando directamente los archivos pertinentes. En este tutorial no nos enfocaremos en ninguna de esas dos formas, solamente mencionaré lo que en sí tienes que conseguir.

Una de las cosas que requieres, y que probablemente haya quedado configurada desde el inicio cuando instalaste (o te instalaron) Linux en la máquina, es que el firewall se active desde que arranca la máquina, de otra forma tendrías que estarlo activando manualmente cada vez que reinicias tu máquina.

Servidor Linux desde tu hogar Paso 1

Publicando mi dirección IP

Este paso se realiza en dos (bueno, tres) incisos:
  1. ligar la dirección IP del ruteador con el servidor, configurando el ruteador
  2. habilitar el servidor para tomar dicha dirección
  3. probar
Ligar la dirección IP
Para publicar la dirección IP, es decir, para que la dirección IP externa, del ruteador, quede ligada a la máquina que funcionará como servidor, debes acceder a la página de configuración del ruteador. Dependiendo el modelo del aparato, esta puede cambiar. En este caso te recomiendo que consultes la documentación del ruteador para conocerla. Un caso típico es en la dirección 192.168.1.254, aunque como dije, esto depende de cada ruteador.

Una vez dentro debes buscar la opción para redirigir todas las peticiones del ruteador hacia la máquina específica del servidor. Esto se conoce como port-forwarding, y normalmente se encuentra dentro de las opciones del firewall del ruteador. Por ejemplo, en un ruteador 2Wire, accediendo a las opciones del firewall para la máquina en particular que funcionará como servidor, deberías colocar dicha máquina en el modo DMZPlus. Esto provocará que todo el tráfico que entre al ruteador sea dirigido a la máquina servidora, excepto aquel que por configuraciones del mismo firewall del ruteador se haya especificado para dirigirse a otras máquinas, para aplicaciones particulares.

Conexión inalámbrica en linux

Este es una publicación de Andrea TD en chicaslinux.org (solo corregí errores ortográficos y formato) y me pareció interesante para todos aquellos que hemos tenido problemas configurando la tarjeta inalámbrica, incluso en laptops.
--------
La conexión inalámbrica funciona bien en linux, yo trabaje con un router inalámbrico D-Link Dl624 y tarjetas inalámbricas D-link, advantek, Encore PCI y usb. Si la distribución que uses de linux no te reconoce la tarjeta sigues los siguientes pasos:

1. Instalar Driver o controlador por terminal.
Paquetes que deben de estar instalados:
  • ndiswrapper-common,
  • ndiswrapper-modules-1.9,
  • ndiswrapper-utils-1.9
Luego, se realiza la instalación de los paquetes necesarios. Se puede hacer de dos formas:

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.

JBoss AS - Servicio de Seguridad

JBoss usa JAAS (Java Autthentication and Authorization Service) para proveer modulos de autenticación, puedes usar los que provee o implementar los tuyos propios.

La información de dominios de seguridad se encuentra en conf/login-config.xml, por lo tanto hay que (num. 1) indicar una política para nuestra aplicacion: <application-policy> con un modulo de autentication y sus opciones; en este caso para la aplicación jmx-console, se está usando UsersRolesLoginModule y obtiene los usuarios y roles desde archivos properties dentro de la carpeta props.

Los usuarios en los archivos .properties se configuran en lineas separadas cada uno como usuario=password y los roles como usuario=role

JBoss AS - Introducción

Mejor conocido como JBoss AS, se trata de un servidor de aplicaciones J2EE de código abierto (hay tambien versiones empresariales con un poco de $$), está preparado para la producción y certificación J2EE 1.4. También implementa la especificación inicial de EJB 3.
  1. Puedes descargar la ultima version estable desde http://www.jboss.org/jbossas/ y el zip que se descarga contiene carpetas como sigue:
    1. bin - como es de suponer, contiene los ejecutables, ente ellos, run.sh para iniciar y shutdown.sh para detenerlo.
    2. client - contiene jars usados por los clientes de los EJBs usados en JBoss y conviene agregarlos al CLASSPATH
    3. docs - contiene los documentos de jboss
    4. lib - contiene los jars usados por JBoss para su funcionamiento
    5. server - tiene subdirectorios referentes a modalidades del servidor de aplicaciones como all (permite emplear funcionalidades como Cluster y webservices, entre otros), minimal (permite ejecutarlo con los requerimientos mínimos) o default (para usarlo de forma básica),
  2. Para instalarlo necesitas un JDK: para linux o windows y varía en cada modalidad su contenido, pero en general se tienen las siguientes carpetas:
    1. conf - son archivos de configuración para las diferentes secciones de JBoss
    2. data* - distintos parametros y archivos de configuración sobre las bases de datos proporcionadas con JBoss como Hipersonic y Messaging
    3. deploy - este directorio se escanea contínuamente para montar las aplicaciones, basta copiar los paquetes war, ear, etc., al estilo tomcat.
    4. lib - contiene los jars que hacen funcionar a JBoss
    5. log* - contiene los archios de trazas (logs) del servidor
    6. tmp* - almacena archivos temporales creados por el servidor
    7. work* - clases y archivos usados por JBoss para su ejecución
    8. Nota: las carpetas con * son creadas automáticamente por el servidor y no deberían existir hasta que se inicie al menos un vez.
  3. Archivos de configuración.
    1. jboss-services.xml - Identifica los servicios (MBeans) que seran iniciados cuando inicie el servidor.
    2. jndi.properties - contiene las clases Factory usadas para hacer búsquedas JNDI
    3. jboss-jog4j.xml - parámetros empleados para ejecutar las trazas.
    4. login-config.xml - datos empleados para verificar/autentificar usuarios con JAAS.
    5. props - parámetros empleados para la seguridad
    6. standarjaws.xml - JAWS es el motor de mapeo objeto/relacional usado en EJBs Entity CMP
    7. standardjbosscmp-jdbc.xml - valores empleados para el CMP
    8. standardjboss.xml - valores de configuración para el servidor JBoss como tamaño de pools para EJBs, valores de cache, número de pools para bases de datos y clases para control de transacciones, entre otros.

Fuente:
Wikipedia
Como instalar en windows

Diagrama explicando el software libre

diagrama software libre

Para la imagen en tamaño completo aquí.

Instalar Presto



Aunque se pueden obtener mas detalles desde la pagina de jackbe, básicamente tienes que hacer lo siguiente para instalar Presto en tu equipo con una licencia de prueba ...

Para poner en marcha Presto.

1.- Descargar desde: http://www.jackbe.com/enterprise-mashup/content/download-presto-developer-edition, tienes que registrarte para obtener la licencia via email.
2.- Descomprimir zip en una carpeta a la que llamaremos PRESTO_HOME
3.- Iniciar repositorio de presto con: PRESTO_HOME\prestorepository\hsqldb\server.bat o .sh para linux
4.- Iniciar servicio web con : PRESTO_HOME\mashupserver\stopPresto.bat o .sh para linux
5.- Entrar a: http://localhost:8080/presto, se ingresa la key de la licencia por unica vez y luego se accede con el usuario admin y password adminadmin

Para detener el servicio de presto:

1.- Detener el servicio web con: PRESTO_HOME\mashupserver\startPresto.bat o .sh para linux
2.- Detener el repositorio de presto con: PRESTO_HOME\prestorepository\hsqldb\shutdown.bat o .sh para linux

Ahora a usarlo!! y para eso, tenemos una buena guia de jackbe con videos en: mashups training

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.

Servidor Linux desde tu hogar en tres pasos

Una de las ventajas que tiene Linux como sistema operativo es su facilidad y estabilidad al momento de utilizarlo como servidor. Actualmente en el mundo Linux es uno de los sistemas operativos a la cabeza en lo que a elección de sistema se refiere para tener un servidor de múltiples plataformas en Internet (web, ftp, correo electronico, etc.)

Pero lo que es menos conocido es que, en la práctica, cualquier máquina con un sistema Linux puede ser configurada (tanto en S.O. como en la red local) para funcionar como un servidor visible al amplio mundo externo de Internet.

En lo particular, yo lo utilizo tanto como un juguete para hacer experimentos y aprender sobre servidores, como de repente para algunas cosas útiles como tomar un archivo que tengo en mi casa a la hora de navegar por internet desde mi oficina o cualquier otro lugar, para iniciar sesión remota y trabajar en mis pendientes desde fuera de mi hogar, para versionar algunos proyectos que mantengo, entre otras cosas.

Usos de comando grep

El comando grep te ayuda a buscar un archivo, grupo de archivos, directorios o contenido de archivos mediante un patrón que puede ser una palabra, letra o una expresión regular.
La forma básica de este comando es como abajo se indica, donde lo encerrado entre comillas es la cadena a buscar y archivo.txt es el archivo dentro del cual se desea buscar.

grep "cadena a buscar" archivo.txt

Sin embargo, el comando grep tiene muchas más formas de ser mejor aprovechado y aquí listo algunas de ellas:
  • Para una búsqueda insensible a mayúsculas / minúsculas
grep -i "cadena a buscar" archivo.txt
  • La cadena a buscar puede ser también una expresión regular donde se pueden aprovechar los siguientes caracteres para significados especiales
    • ? - indica que el elemento anterior es opcional y puede aparecer al menos 1 vez
    • * - indica que el elemento anterior puede aparecer 0 o más veces
    • + - indica que el elemento anterior puede aparecer 1 o más veces
    • {n} - indica que el elemento anterior debe aparecer exactamente n veces
    • {n,} - indica que el elemento anterior puede aparecer n o más veces
    • {,m} - indica que el elemento anterior debe aparecer al menos m veces
    • {n,m} - indica que el elemento anterior debe aparecer al menos n veces, pero no más de m.

Patrón de Diseño Command

El patrón comando permite que solicitudes del cliente sean encapsuladas como objetos, indicar parámetros a diferentes solicitudes, encolarlas, registrarlas y hasta dar soporte para operaciones des-hacer.
Participantes:

Uso de mount para montar dispositivos de almacenamiento en Linux

El comando mount nos permite cargar un sistema de archivos, de cualquier dispositivo periférico o carpeta compartida en la red, en nuestro sistema linux y visualizarlo desde una carpeta de nuestro sistema. Esto, muchas veces los ambientes gráficos permiten hacerlo de manera automática, pero es importante conocer que se hace debajo o por lo menos como está trabajando.

Para empezar, debemos conocer como se clasifican los dispositivos. Te recomiendo esta presentación en PDF como introducción. Los canales más conocidos y casi de salida son los IDE, de los cuales hay dos por lo general en cada tarjeta madre, y de estos dos clasificaciones maestro y esclavo, por tanto:
  • /dev/hda - corresponde al canal primario configurado como maestro, si existen particiones, solo pueden existir hasta cuatro primarias y se enumeran hda1 .. hda4, de las cuales una puede ser extendida y dentro de ésta máximo 16 unidades lógicas, de las cuales siguen la numeración desde 5, esto es hda5 .. hda21. Lo mismo se hace para los otros canales IDE si fueran discos duros (hdb, hdc y hdd).
  • /dev/hdb - corresponde al canal primario configurado como esclavo
  • /dev/hdc - corresponde al canal secundario configurado como maestro
  • /dev/hdd - corresponde al canal secundario configurado como esclavo

Usos de comando find en linux

Para ejecutar el comando find, debes conocer lo siguiente:
  • Por defecto, el comando find, busca en la ruta actual y todos sus subdirectorios. No obstante se pueden modificar estas características y otras más según la tabla abajo descrita.
  • Se pueden encadenar los resultados de find con pipe '|' para manipular los resultados. Ejemplo, mostrar los 3 archivos mas grandes del sistema
    • find / -type f -exec ls -s {} \; | grep sort -n -r | head 3
  • Cada archivo, carpeta, enlace simbólico o duro, etc., es guardado en el sistema de archivos con un numero irrepetible conocido como 'inode', de esta manera podemos tener dos o mas archivos con nombres similares pero inodes distintos.
Ejemplo: "archivo1.txt", "archivo1 .txt" y "archivo1.txt " [Noten los espacios]. No obstante, al mostrarlos como 'ls -i1 archivo*' se mostraría algo como esto:
16187429 archivo1.txt
16187430 archivo1 .txt
16187431 archivo1.txt

Configurando log4j

Log4j tiene los siguientes niveles de traza que se definen con el tag <priority>:
  • OFF: no se muestra en ningún mensaje (se encuentra apagado)
  • FATAL: para mostrar mensajes de situaciones que probablemente harán abortar la aplicación
  • ERROR: para mostrar mensajes de errores que no son deseados pero que no interrumpirán la aplicación.
  • WARN: para mostrar mensajes de contextos peligrosos para la aplicación, o ciertas operaciones de uso no recomendado
  • INFO: para mostrar mensajes de información sobre la ejecución de la aplicación, o eventos importantes dentro de la misma
  • DEBUG: para mostrar mensajes interesantes para depurar la aplicación. Para la etapa de desarrollo.
  • ALL: se muestra en todos los casos
Se puede configurar en tres formas, con código Java, con archivo .properties o un archivo .xml, En esta ocasión veremos un xml debido que es más fácil para algunos desarrolladores, aunque yo me acomodo mejor con un .properties.

Uso de APT en Linux Debian, Ubuntu o Mint

APT es el acrónimo de Advanced Packaging Tool, el sistema de gestión de paquetes utilizado en Debian y sus derivados, como Ubuntu. Tanto aptitude como Synaptic o Adept se basan en este sistema.

dpkg es el programa base en el cual se apoya la gestión de paquetes Debian y las distribuciones derivadas. Permite instalar/desinstalar programas en forma de paquetes .deb (similar a los .rpm de RedHat o Fedora) y consultar información sobre ellos.

Para instalar un paquete
dpkg -i paquete.deb
Listar el contenido de un paquete
dpkg -L paquete
(usa grep para buscar un archivo o folder)
Para saber a que paquete pertenece un archivo
dpkg -S archivo.cfg
Listar paquetes instalados en el sistema
dpkg -l
Para reconfigurar un paquete (fase en la que se inician/paran servicios, crean archivos log, etc)
dpkg-reconfigure paquete
Buscar paquetes por palabras
aptitude search texto_a_buscar
Impedir que un paquete se actualice
aptitude hold paquete
Actualizar del sistema todos los paquetes a sus nuevas versiones sin involucrar aquellos que requieran nuevos paquetes o eliminarlos
aptitude upgrade ó
apt-get upgrade
Actualizar todos los paquetes del sistema, incluyendo aquellos que si requieren nuevos paquetes o eliminar otros
aptitude dist-upgrade ó
apt-get dist-upgrade
Para solicitar información de un paquete, esté o no instalado
aptitude show paquete

El equipo de Debian recomienda usar aptitude en lugar de apt-get.

Observaciones sobre Pruebas Unitarias

Analizando las constantes e incansables ocasiones que nuestro líder de proyecto habla sobre la necesidad de hacer pruebas unitarias (automatizadas), y que no siempre estuve de acuerdo, dado el tiempo que se requiere para construirlas y que en la mayoría de las veces, las fechas de entrega negociadas con el cliente nos ahorcan en los tiempos que podemos dedicar a esta práctica, me he dado cuenta de lo siguiente.

Evidentemente sería mucho más útil tener pruebas unitarias que se construyan desde un principio para que en la vida del proyecto se ejecuten periódicamente y nos aseguremos que las partes de dicho proyecto siguen funcionando como deben, independientemente de la integración de nuevos módulos, refactoring de clases, optimización de código e inclusive corrección de estilo.

Pero para lograrlo y evitar el tedio al realizar las pruebas unitarias considero que hay que pensar en lo siguiente:
  1. Para no hacer esfuerzos sin ganancia, es absolutamente necesario planear los puntos críticos a probar unitariamente en los distintos módulos del proyecto.
  2. Así como los Casos de Uso se desarrollan antes que el diseño y los diagramas UML preceden a la construcción de un proyecto, es vital que las pruebas unitarias se armen antes de la construcción.
  3. No es necesario crear una prueba unitaria por cada Dao, Servicio, Pojo, Controller, ViewHelper o Utilería habido o por haber.
  4. Las pruebas que deberían automatizarse son aquellas que tienen una mayor probabilidad de no cambiar (en concepto) a lo largo del proyecto. Cuando sea necesario integrar ajustes nuevos y provoquen un fallo en las pruebas automatizadas ya existentes, se pueden actualizar dichas pruebas con cambios mínimos para mantenerlas como símbolo de que nuestro sigue funcionando con los requerimientos de un principio.
  5. Es necesaria una comunicación plena en el equipo de desarrollo por cuestiones de conflictos de actualizaciones, sobre todo si se esta trabajando en el mismo repositorio y los cambios de uno afectan a las pruebas unitarias de otro.
  6. Para visualizar el correcto funcionamiento de una prueba unitaria y localizar el error si esta falla (sin hacer debug) es realizar un correcto logging, de manera que éste mismo explique claramente la etapa que transcurre (con datos self-explaining) y compruebe el estado del proceso en ejecución.
  7. Es importante contar con un grupo de herramientas adecuadas que nos permitan conectarnos a base de datos y trabajar con datos, simular comportamientos de servicios no-tan-fácilmente-probables, acceder a archivos y verificar su contenido y un grupo de agregados para comprobar los resultados de cada prueba. Quizá funcionen como adaptadores, servicios, factories o daos dedicados exclusivamente para comprobar cosas. Junit tiene un addons que se ve bastante bien.
  8. El que las pruebas unitarias estén correctamente automatizadas y con un adecuado logging (incluyendo los elementos a probar) implica que ya no es necesario hacer debugging para encontrar los errores (algo que solo se puede hacer manualmente).
Una vez planeado así, podríamos ver los resultados que dice el articulo de jamesgolick en su apartado "Breaking Even" : 'si te cuesta 20min. construir una prueba automatizada y 1min. una prueba manual, llegar al punto critico para compararlas es que probases manualmente 20 veces; después de eso, la prueba automatizada se vuelve mucho mas barata y la manual obviamente mas cara, disparándose ambas en sentido contrarios'.

Ustedes que piensan? alguna otra recomendación?

Buenas prácticas con Spring

  1. No abusar de las inyecciones
  2. Utilizar inyecciones por dependencias (setter) en vez de por constructor
  3. Agregar una descripcion al archivo de configuracion xml y notificar al equipo sobre los cambios realizados
  4. Usar ids como identificadores de beans
  5. Integrar archivos de configuración mediante ApplicationContext y no usar imports de xml
  6. Reutilizar definiciones de beans
  7. Si se usa inyección por constructor, utilizar TYPE en vez de INDEX para los argumentos del constructor
  8. Usar convenciones de nomenclatura para nombrar los beans
  9. Evitar el uso de autowiring
Leer más en dosIdeas

Instalar un artefacto en el repositorio de maven

Para instalar un artefacto en un repositorio local de maven. Por lo general lo copia en el directorio home_del_usuario/.m2/repository/, salvo los ajustes que hagamos en archivo de configuración de maven: settings.xml.

mvn clean install

Para instalar un artefacto de terceros hacer:

mvn install:install-file -Dfile=foo.jar -DgroupId=org.empresa -DartifactId=foo -Dversion=1.2.3 -Dpackaging=jar

Para instalar un artefacto en un repositorio remoto de maven.

mvn deploy:deploy-file -Dfile=foo.jar -DgroupId=org.empresa -DartifactId=foo -Dversion=1.2.3 -Dpackaging=jar -DrepositoryId=focus-repository -Durl=scp://host/home/mvn/public_html/repository

Intro comandos Maven 2.0

Para obtener ayuda del comando de Maven 2:
mvn --help

Sintaxis general:
mvn plugin:target [-Doption1 -Doption2 ...]

Para crear un proyecto JAR:
mvn archetype:create -DgroupId=com.empresa.proyecto -DartifactId=nombreAplicacionJAR
* Si vas a crear un módulo dentro de otro proyecto maven previamente creado, debes ejecutar el mismo comando pero dentro o al nivel raiz del proyecto que va a contener dicho módulo, automáticmante maven, hace que el nuevo proyecto sea módulo del proyecto a nivel raíz en el que te encuentras parado.
Observa el tag en el pom.xml del proyecto padre y el tag del proyecto hijo después de ejecutar el comando.
Para crear un proyecto WAR:

Particiones en tu HDD con linux

Una forma recomendable de particionar tu disco duro con linux. Recomendable que sea mayor de 80GB tu HDD para este esquema de particiones.
  • 1er. unidad física de 8GB para instalar la version del trabajo diario de linux. Ejemplo: Linux Mint o Ubuntu
  • 2a. unidad física de 8GB para instalar otras versiones de prueba de linux. Ejemplo: Fedora, Suse, Linpus, Debian, Xubuntu, Zenwalk, etc.
  • 3a. unidad física EXTENDIDA con el resto de espacio de tu HDD
    • 1a unidad lógica de 50GB para windows XP o windows 7
    • 2a unidad lógica de 4GB para /swap (o el doble de tu memoria RAM).
    • 3a unidad lógica con el resto de espacio de tu HDD para /home.
Las ventajas son variadas, las principales son que linux se encuentra como la primera particion en el HDD y eso te da ventaja sobre el grub para gestionar mejor el arranque entre sistemas operativos instalados.

Ademas tienes un arranque dual entre windows y linux, ademas de una de 8G para realizar otras pruebas con otras distribuciones de linux. Puedes compartir tu /home entre las distribuciones de linux al dejarla separada en otra particion logica, incluso windows pudiera acceder a ella si esta particion de /home estuviera con formato FAT32 (lo cual no es muy recomendable) u otra herramienta para windows que permita leer sistema de archivos ext3 o ext4.

Herramientas que puedes usar: Fdisk de msdos, GParted de linux, Partition Magic de windows.

Como instalar windows desde linux para inicio dual

Lo mejor es instalar Windows sobre un disco virtual usando VirtualBox o VMWare por ejemplo, estos programas estan ya bastante avanzados para ejecutar aplicaciones complejas, incluyendo las que despliegan graficos en 3D.

Pero si aún asi quieres aventurarte, debes instalar Windows normalmente en una particion que no sea la de linux. Si no la tienes ya creada, puedes usar 'GParted' desde linux o 'partition magic' para hacerlo. Incluso redimensionar la particion existente de linux primero para luego crear la de windows.

Una vez instalado Windows (la version mas antojada). Debes iniciar con un live CD de linux (desde un CD o una USB, es indistinto) y verificar si existe el grub 'sudo aptitude install grub' (si no esta instalado el paquete grub, basta con darle 'S' o 'yes' para instalarlo y esperar a que termine)