micro - How To

Autowiring basado en anotaciones con Spring Framework

2011-01-31T12:44:00.000-08:00

Autowiring se un método que tiene Spring Framework para inyectar de forma automática las dependencias entre clases (servicios, daos, controllers, etc).
Para cada DAO, agrega una anotación de nivel clase @Repository.

Estas anotaciones van en la clase de implementación y no en la intefaz.
import org.sringframework.stereotype.Repository;

@Repository("parametroDao")
public class ParametroDaoImpl implements ParametroDao {
    // ...
}

Para cada componente Servicio, agrega una anotacion de nivel clase @Service.
import org.springframework.stereotype.Service;

@Service("parametroService")
public class ParametroServiceImpl implements ParametroService {
    // ...
}

Para cada controller en Spring MVC, agrega una anotacion de nivel clase @Controller.

No te preocupes de proveer el nombre, no se necesita.
import org.springframework.stereotype.Controller;

@Controller
public class ParametroServiceImpl implements ParametroController {
    // ...
}

Hasta ahora no se ha cambiado nada a la aplicación, se pueden seguir teniendo los nombres de beans usados en la configuración manual, pero es recomendable compilar y construir el proyecto para revisar que no se haya afectado algo.

Una vez hecho lo anterior, hay que decirle a Spring dos cosas: dónde encontrar los nombres para nuestros beans y que estrategia usar para el autowiring.

Para definir donde encontrar los nombres de beans debemos usar el tag <context:component-scan> en el archivo de configuración del contexto de Spring. Se debe declarar el namespace y schema location:

<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:context="http://www.springframework.org/schema/context"
    xsi:schemaLocation="http://www.springframework.org/schema/aop
         http://www.springframework.org/schema/aop/spring-aop-3.0.xsd
         http://www.springframework.org/schema/beans
         http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
         http://www.springframework.org/schema/context
         http://www.springframework.org/schema/context/spring-context-3.0.xsd
         http://www.springframework.org/schema/jee
         http://www.springframework.org/schema/jee/spring-jee-3.0.xsd
         http://www.springframework.org/schema/tx
         http://www.springframework.org/schema/tx/spring-tx-3.0.xsd">    
    <context:component-scan base-package="x.y.dao">
        <context:include-filter type="annotation"
            expression="org.springframework.stereotype.Repository"/>
    </context:component-scan>
</beans>

Las piezas importantes del xml anterior son xmlns:context, xsi_schemaLocation y <context:component-scan>. Se le está diciendo a Spring que haga un escaneo (búsqueda) de componentes que tengan la aotación @Repository sobre el paquete x.y.dao y si a la anotacion usada se le coloca un valor textual, como en en nuestros casos anteriores del @Repository y el @Service, ése será el nombre a utlilizar como bean para el autowiring

Con la anotacion @Autowired aplicada a los atributos de las clases, se pueden evitar tener setters de dicho atributo, pero si tienes clases unitarias, necesitaríamos setter para inyectar mocks u otras implementaciones.

La convención es utilizar, como nombres de las propiedades que se pretende auto-inyectar, los mismos nombre del componente, lo cual nos permite eliminar los componentes Dao, Service y Controller del archivo de configuracion del contexto de Spring (xml) dado que la configuración ya se está dando en la misma clasa, mediante las anotaciones.

No obstante, sigue siendo recomendable configurar dentro del XML los objetos DataSource (la configuración del orígen de datos, es decir, la Base de Datos), SessionFactory (Hibernate o algún otro ORM) y TransactioManager (Para el control de las transacciones).

Referencia del entorno de programación en Unix

2011-01-04T09:49:00.000-08:00

Resulta que recomendando un libro sobre programación en Unix, me encontré con esta referencia que puedes descargar desde el mediafire.com :

http://www.mediafire.com/?hf3zzzmdwt3

Como referencia me pareció bastante buena, se las dejo para quien guste descargarla y si en algún momento el enlace está roto, me avisan para ver como repararlo.

Referencias:
=======================

El entorno de programación UNIX
Kernighan, Brian W.
Pike, Rob
Editorial Pearson

Del autor del PDF (Fernando Bellas Permuy).
Descargar capítulos del libro de Kerninghan aquí.

Manual de introducción al comando sed

2011-01-04T08:44:00.000-08:00

Se trata de un editor de cadenas, que deriva directamente del comando ed, por lo cual es fácil de aprender, una vez conocido el propio comando ed. Un editor de cadenas es usado para realizar transformaciones de texto básicas de una cadena de entrada (un archivo o la salida de un pipe). A diferencia de otros editores comunes, sed hace solo una revisión sobre cada entrada, por lo cual es mas eficiente, en especial lo es, cuando filtra texto que pasa por una unión pipe.

Cuando sed filtra un archivo, no altera su contenido, todos los cambios los realiza sobre la salida que imprime. Sed despliega cada renglón automáticamente y por ello p no se necesita después del comando de sustitución (s, por ejemplo s/old/new/). Las comillas son indispensables pues existen metacaracters de sed que tienen significado especial para el shell sobre el cual se ejecuta.

El comando sed tiene una limitación que no se encuentra en ed: no maneja números relativos de renglón. En particular, + y - no son entendidos como expresiones para indicar números de renglón, por lo cual resulta imposible de retroceder a uno o mas renglones anteriores o hacer direccionamientos relativos hacia adelante. Esto se debe a que una vez leído un renglón, el anterior se pierde para siempre; no hay manera de identificar el penúltimo renglón.

En la lista de comandos puede existir cualquiera de los listados más adelante. Cuando se hace uso de uno solo, basta con encerrarlo entre comillas simples como sigue:

sed 's/old/new/' archivo

Pero en el caso de que necesitemos ejecutar varios comandos sobre un mismo archivo, es necesario que estos se encuentren en diferentes lineas, por ejemplo:

sed 's/^/ /

3q' archivo

No hay que olvidar que antes de escribir el primer comando, se deben abrir las comillas simples y las mismas se deben cerrar después de teclear el último comando. También es posible almacenar los comandos dentro de un archivo y llamarlo a la hora de que se ejecute sed con el parámetro -f. Por ejemplo:

sed -f cmdarchivo archivo_texto

Se pueden utilizar otros selectores o patrones antes de cada comando, por ejemplo:

sed '/patron/q' Imprime cada linea de archivo hasta encontrar aquella que contenga el patron

sed '/patron/d' Cancela todas las lineas que contengan el patron y no se imprimen

Incluso si se desea el resultado inverso a lo que realiza un comando, basta con agregar un '!' antes

del comando. Por ejemplo, para los dos ejemplos anteriores se prosigue como sigue:

sed '/patron/!q' No imprime c/línea de archivo hasta encontrar aquella que contenga el patron

sed '/patron/!d' No cancela todas las lineas que contengan el patron y no se imprimen

Sintaxis

La sintaxis de sed es la siguiente

sed [-n] [-V] [--quiet] [--silent] [--version] [--help]

[-e script] [--expression=script]

[-f script-file] [--file=script-file]

[script-if-no-other-script]

[file...]

-----------------------------------------------------------------------------------------------

-V ó --version

Imprime la versiòn de sed y nota de copyright.

-h ó --help

Imprime un resumen de todas las opciones de sed.

-n ó --quiet ó --silent

Por defecto, sed imprime cada linea cuando termina de editarla. Esta opciòn deshabilita la impresiòn automàtica y no se produce ninguna salida, excepto que se incluya el comando p.

-e script ó --expression=script

Agrega los comandos de la cadena script, encerrada entre comillas simples, a la lista de comandos para ser ejecutados mientras se procesa la entrada.

-f script-file ó --file=script-file

Agrega los comandos contenidos en el archivo script para ser procesados sobre la entrada. Si ninguno de los dos parámetros anteriores es utilizado, en cualquiera de sus formas, sed tomará como comandos la primer expresión que no sea opción de sed como argumento para ejecutar como si fuera script.

Comandos ================================================

A continuación se presenta una lista de comandos que se pueden utilizar para filtrar una entrada con sed, así mismo se incluyen algunos ejemplos para una mayor comprensión.

** Sustitución **

Su función es sustituir una cadena old por una nueva new en cada linea que procese. Su sintaxis

es la siguiente:

s/old/new/

Ejemplo:

sed 's/casa/carro/' contrato.txt Sustituye la cadena 'casa' por 'carro' en contrato.txt

sed 's/^/.-/' arch.txt Agrega la cadena '.-' al inicio de cada linea de arch.txt

sed 's/^/\

/' arch.txt Agrega un salto de linea al final de cada linea de arch.txt

Otro comando que puede ser útil es y, el cual remplaza cada caracter procedente de old con el caracter correspondiente proveniente de new. Aqui no se admiten rangos. Su sintaxis es:

y/old/new/

** Borrado **

Su función es borrar a la salida, las lineas que correspondan al patrón escrito. Su sintaxis es la

/patron/d

Ejemplo:

sed '/calvo/d' arch.txt Elimina las lineas que contienen la cadena 'calvo' en arch.txt

sed '/amor/!d' carta.txt Elimina las lineas que no tengan la palabra amor en carta.txt

sed '3d' forma.txt Elimina la linea 3 del archivo forma.txt

** Impresión **

Su función es imprimir la salida de sed. En realidad, sed imprime automáticamente la entrada filtrada, entonces si se agrega el comando p, cada linea de salida se imprimirá doble. En caso de que se agregue el parámetro -n a sed, pero se quiera imprimir la salida, se agrega el comando p. Su sintaxis es la siguiente:

/patron/p

Ejemplo:

who | sed -n '/root/p' Imprime solamente las sesiones de root

who | sed '/root/p' Imprime dos veces cada sesion abierta de root

who | sed -n '2p' Imprime solamente la segunda sesion que se inició en el sistema

** Abandonar filtrado **

Otro comando útil para imprimir una parte de la entrada es q. Este comando termina inmediatamente las operaciones de sed, en base a la correspondencia del patrón con las líneas que este procesando. Su sintaxis es la siguiente:

/patron/q

Ejemplo:

sed '3q' forma.txt Imprime hasta la linea 3 del archivo forma.txt

sed '/clavo/q' arch.txt Imprime desde la línea 1 de arch.txt hasta encontrar aquella que contiene la palabra 'clavo'.

** Inserción de texto **

Este comando inserta o agrega texto a cada línea que procesa sed. El texto debe estar localizado

en las siguientes lineas que proceden después del caracter '\'. Su sintaxis es la siguiente:

i \ y a\

[ texto a agregar ]

Ejemplo:

sed 'i \

.' oraciones.txt Agrega un punto final a cada linea de oraciones.txt

sed 'a \

' doble.txt Agrega un salto de linea al final de cada linea de doble.txt

** Guardar la entrada filtrada en un archivo **

Este comando permite salvar la entrada filtrada en otro archivo. Su sintaxis es la siguiente:

/patron/w archivo

Ejemplo:

sed '/pat/w patos.txt

/pat/!w otros.txt animales.txt

Guarda las lineas que concuerden con 'pat' en un archivo llamado patos.txt y los que no

concuerden en el archivo otros.txt

sed 's/UNIX/UNIX(TM)/gw u.out' libros.txt > salida.out

Almacena toda la salida en el archivo salida.out, pero las líneas que fueron modificadas, se

almacenan en u.out

Funciones =================================================

** Etiqueta **

Permite identificar una etiqueta label, si se realiza un cambio en la línea actual. Esta es

especificada por ':' y seguida del nombre de la etiqueta. Su sintaxis es como sigue:

: label

** Grupo **

Indica un grupo de comandos, que inicia con un carácter '{' y termina con un '}'.

** Lectura de archivos **

Con el comando r, lee un archivo y agrega todo su contenido al final de cada línea de entrada de

sed. Su sintaxis es:

nr archivo, donde n es el número de línea donde pegar el texto de archivo.

** Listar línea **

El comando es l y su función es hacer visibles todos los caracteres no imprimibles de cada línea de

entrada.

** Linea actual **

Se puede imprimir el número de la línea actual, si se agrega el comando '='. Su sintaxis es:

/patron/=

** Salto **

Permite saltar o ir a la línea donde se encuentra una etiqueta label definida y continuar la ejecución

de sed desde ese comando. Su sintaxis es:

b label

Conclusión sobre los usos de sed. ==========================================

En realidad sed tiene bastante utilidad como la comprobación de condiciones, creación de ciclos y ramificaciones, retención de líneas precedentes y muchos de los comandos de ed. Su uso es

similar al que se ha descrito en este manual, comandos sencillos de edición y no tanto de

secuencias largas o complejas.

Sed es adecuado para manejar entradas arbitrariamente grandes de forma rápida, pero ofrece una

forma bastante reducida de memoria, puesto que al filtrar una siguiente línea, ya no recuerda la

anterior, por lo que no se puede regresar a filtrar la anterior y tampoco proporciona recursos para

manipular números. Solo es un editor de texto.

debugging remoto de scripts Python con winpdb

2010-12-16T11:22:00.000-08:00

Usando el programa winpdb se pueden debuggear scripts en Python de manera mas intuitiva que con el clásico pdb.

Una de las ventajas que tiene winpdb es la posibilidad de debuggear scripts que esten ejecutandose en remoto en algun servidor. De esta manera, se pueden debuggear no solo scripts en servidores de producción, por poner un ejemplo, sino también scripts que utilicen curses para manipular la pantalla.

winpdb se basa en una arquitectura de cliente-servidor que comunica al servidor (el cual ejecuta el script a debuggear en sí) a través de sockets con el cliente (el cual ejecuta la interfaz del debugger).

winpdb cuenta con dos programas para poder hacer el debuggeo:

rpdb2 - que es la interfaz de consola o modo texto, y que puede ser usada como servidor del debugger también.
winpdb - que es la interfaz gráfica

Para debuggear un script en remoto, hay que ejecutar lo siguiente en el servidor:

screen rpdb2 -s -d -r script.py

El cual utiliza el programa 'screen' para tener la salida del script python a debuggear en una pantalla dedicada.

El parámetro -s se usa en conjunto con screen.

El parámetro -d le indica a rpbd2 que se ejecute en modo servidor solamente, esperando a que algún cliente se conecte para poder hacer el debuggeo.

El parámetro -r permite conexiones remotas.

script.py es simplemente el path y nombre del script a debuggear.

Al ejecutar esta línea, el programa rpdb2 solicitará un password que deberá introducir el cliente también, y con eso asegurar la comunicación entre el cliente y el servidor.

Hecho esto, rpdb2 queda en espera de alguna conexión.

En el lado del cliente, se puede ejecutar rpdb2 para debuggear con la consola, o si se prefiere winpdb para hacerlo con una interfaz gráfica:

winpdb -oserverhost -a script.py

El parámetro -o va seguido de la dirección IP o nombre del servidor

El parámetro -a le indica a winpdb que al conectarse al servidor, adjunte el script script.py que se debe estar ya ejecutando en el servidor para poder debuggear con rpdb2.

Hecho esto, se solicitará el password que se indicó en rpdb2 y con eso la interfaz inicializará y conectará con el servidor y cargará el código fuente del script solicitado, con lo que ya puede comenzar a debuggearse...

Links:
winpdb - sitio oficial de winpdb, con el código fuente del programa, para instalarlo, y documentación.

Configurar POI en Spring 3 para generar archivos Excel

2010-12-03T12:17:00.000-08:00

He decidido registrar el proceso de como generar archivos Excel con POI mediante Spring 3 para que no se me olvide (aunque es bastante sencillo). Me sorprendí de terminarlo en tan sólo 3 pasos!

1) Generar un controller que obtiene los valores que se pretenden mostrar en la vista, los agrega al modelmap de MVC que maneja Spring y luego devuelva el nombre de la vista encargada de generar el excel.

@Controller
@RequestMapping("/excel")
public class ExcelController {

    @Autowired
    private Servicio servicio;

    @RequestMapping(value = "/{parametro}", method = RequestMethod.GET)
    public String generarExcelByParametro(
            ModelMap modelMap, HttpServletResponse response,
            @PathVariable("parametro") String nombreVista) {
        modelMap.put("datos", servicio.obtenerDatos(parametro));

        response.setHeader("Content-type", "application/vnd.ms-excel");
        response.setHeader("Content-Disposition","attachment; filename=\"excel.xls\"");
        return "reporteExcel";
    }

}

Observa que el método generarExcelByParametro() del controller responde a una petición http://{servidor:puerto}/{contexto}/excel/{parametro} y realiza algo en un servicio que devuelve cierta información que se espera administrar de lado de la vista (más adelante lo vemos) y lo guarda dentro del ModelMap de spring con el identificador "datos".

Los headers que se agregan al response, son solo para asegurar que cuando se genere el archivo .xls, se identifique como tal y se obligue al usuario a descargarlo.

Finalmente la cadena ("reporteExcel") que se devuelve determina el nombre de la vista que interpretara los datos para generar el documento.

2) Configurar la vista
Es necesario generar un archivo de nombre views.properties o agregar al que ya exista en el classpath del proyecto, algo como lo siguiente:

reporteExcel.(class)=mx.com.empresa.miproyecto.web.view.ExcelView

La linea comienza con el nombre de la vista, que es el nombre de la cadena que se devuelve en el controller; no olviden encerrar el .class entre paréntesis. La clase (junto con el paquete) que se asigna como valor indica la ubicacion de la View (o vista), misma que interpretará los datos y los plasmará sobre el Excel.

3) Generar la View (vista) que interpreta los datos del controller. Se debe generar una clase que herede de org.springframework.web.servlet.view.document.AbstractExcelView e implemente el metodo buildExcelDocument(). En dicho método es donde se debe recuperar los datos que se involucraron en el ModelMap desde el controller.

public class ExcelView extends AbstractExcelView {
    @Override
    protected void buildExcelDocument(
            Map<String, Object> model, HSSFWorkbook book,
            HttpServletRequest request, HttpServletResponse response)
            throws Exception {
        //recuperar datos
        List reporte = (List<Map<String, Object>>) model.get("datos");
        //crear la hoja
        HSSFSheet hoja = book.createSheet("nombre de la hoja");

        //generar un estilo para la celda
        HSSFCellStyle estiloCelda = obtenerEstiloCelda(book);

        //guardar valores en toda la hoja
        HSSFCell celda;
        int row = 0;
        int col;
        for (Map m : (List<Map<String, Object>>) reporte){
            col = 0;
            // guarda valores en una fila de la hoja
            for (Object o : m.keySet()) {
                celda = getCell(hoja, row, col++);
                celda.setCellStyle(estiloCelda);
                setText(celda, null == m.get(o) ? "[nulo]" : m.get(o).toString());
            }
        row++;
        }
}

La información a utilizar, según el controller que hicimos antes, se obtiene del ModelMap con el identificador "datos". Para este caso se está obteniendo una lista de registros devueltos comúnmente por la ejecucion de un jdbcTemplate.queryForList("... mi query sql ...") de Spring.

Es necesario crerar una hoja mediante createSheet() y usar el valor devuelto (HSSFSheet) para agregar contenido, diseño, colores de fondo y bordes, agregar registros o contenido en celdas específicas con coordenadas (fila, columna), rotar texto, fuente, tamaño, forma de texto y clasificación de contenido de la celda, entre otros muchos más.

Por ejemplo puedes utilizar la instancia de la hoja (HSSFSheet) y el metodo autoSizeColumn((short) 1) para configurar una columna (este caso la B) como autoajustable a lo ancho, de acuerdo al texto que contenga. Para modificar el alto de la primera fila, hacer:

        HSSFRow primerRegistro = hoja.createRow(0);
        primerRegistro.setHeight((short) 1200);  //es una altura de 60.00 cuando lo ves desde el Excel

Observa que utilizas dos métodos básicamente: getCell() para obtener una celda (HSSFCell) de una hoja determinada en una ubicación con la combinación fila, columna; y setText() para asignarle un valor de texto a dicha celda.

También puedes crear templates de estilos de celda para luego aplicarlos a un grupo de ellas. En el código siguiente se esta definiendo un tipo de letra (HSSFFont) de ancho normal, con tamaño 8 y un estilo (HSSFCellStyle) con alineación a la izquierda y borde inferior con pequeños puntos consecutivos(BORDER_DOTTED).

    private static HSSFCellStyle obtenerEstiloCelda(HSSFWorkbook book) {
        HSSFFont fuente = book.createFont();
        fuente.setBoldweight(HSSFFont.BOLDWEIGHT_NORMAL);
        fuente.setFontHeightInPoints((short)8);
        HSSFCellStyle estilo = book.createCellStyle();
        estilo.setFont(fuente);
        //alineacion
        estilo.setAlignment(HSSFCellStyle.ALIGN_LEFT);
        estilo.setVerticalAlignment(HSSFCellStyle.VERTICAL_TOP);
        //border
        estilo.setBorderBottom(HSSFCellStyle.BORDER_DOTTED);
        return estilo;
    }

Existen muchas más alternativas para los estilos pero para no volver a escribir lo que ya está publicado en otros lados, debes revisar las ligas siguientes para abundar más sobre el tema:

Aunque puedes realizar un montón de ajustes en el estilo de tu hoja, básicamente, tu hoja la diseñas en la vista (View) que hereda de la AbstractExcelView y Spring hace todo el resto del trabajo. Sencillo no ?

Servidor VNC para sesiones de escritorios remotos

2010-11-30T11:12:00.000-08:00

Introducción
VNC (Virtual Network Computer) es el software a través del cual se puede iniciar sesión en escritorio remoto con GNU/Linux.

Otra opción es el RDP de Windows, sin embargo aquí explicaremos únicamente como configurar el servidor para el caso de VNC.

Lo primero que hay que saber es que VNC funciona para controlar escritorios remotos que utilizan el servidor gráfico X-Window , el default de GNU/Linux hasta ahora. Sin entrar en detalles de cómo funciona X-Window, basta saber que en este tutorial explicaremos dos opciones:

controlar el escritorio X real que se tenga en el escritorio remoto
controlar un escritorio X virtual que se crea a demanda en dicho escritorio remoto

Ambas opciones tienen posibilidades de aplicación.

Por ejemplo, si lo que deseamos es que otras personas vean mi escritorio mientras yo lo manipulo, puedo levantar VNC usando la opción 1 y permitiendo que los demás se conecten sólo en escucha (sin posibilidad de intervenir en mi sesión). Y de esta manera se pueden impartir cursos o hacer demostraciones en vivo.

Si lo que deseamos es acceder a sesión remota del escritorio para poder acceder como si se tratara de estar sentado físicamente frente a la máquina, pero sin estarlo, y que no importe (o no se requiera) manipular directametne la terminal real de X, sino sólo iniciar sesión, puedo levantar VNC usando la opción 2.

Cabe entonces mencionar que en X se tiene siempre asociada una 'pantalla' (display) real con la terminal física. Normalmente se le asigna el número 0 como identificador. A partir de ahí, el programa Xserver permite levantar nuevas 'pantallas' virtuales (displays) no relacionadas con la terminal física. Es decir que si usamos la pantalla #1, al no ser la física, podemos acceder a ella a través de VNC, pero en la pantalla física no se verá nada (pues esta es la 0, no la 1).

Requisitos previos
Los programas en cuestión que necesitamos instalar son los siguientes:

opción 1: x11vnc en el servidor
opción 2: TightVNC , RealVNC, UltraVNC o cualquier otro que permita VNC en el servidor
clientes: cualquier visor de VNC, como krdc, realvnc vncviewer, etc. No entraremos en detalle sobre el uso de los clientes, ya que se trata de algo muy intuitivo, bastará conectarse al servidor VNC una vez que esté levantado en el puerto que se haya configurado para lo mismo. Cabe anotar que los clientes pueden correr en cualquier plataforma independientemente de que el servidor sea GNU/Linux u otro. Por ejemplo, se puede iniciar sesión remota con un cliente en Windows, a pesar de que el servidor sea GNU/Linux. Otra anotación interesante sobre los clientes es que algunos servidores de VNC (por ejemplo TightVNC) permiten levantar el servidor a través de una interfaz en Java para que el escritorio remoto pueda ser accedido a través de un navegador web con soporte para Java, utilizando un applet específico para lo mismo.
configurar XDMCP en el escritorio remoto para permitir el incio de sesión.

También hay que asegurarse de tener instalado en el servidor el programa Xserver, y de preferencia el superservidor xinetd, que permitirá conectarse a pantallas virtuales sin consumir recursos del servidor cuando no se esté utilizando VNC y a la vez permitir a más de una persona conectarse a su propia sesión con VNC sin que el servidor bloquee puertos ni nada por el estilo.

Inicio de sesión remoto

XDMCP es un protocolo que, en resumen, permite el incio de sesión remoto en terminales X de cualquier índole.

Si no configuramos XDMCP, entonces solamente podremos acceder a pantallas que ya tengan la sesión iniciada. Puesto que esto sólo es posible en pantallas físicas, nos veríamos restringidos a la opción #1, sin posibilidad de utilizar la pantalla de inicio de sesión de la pantalla que quisiéramos controlar, por lo que sólo sesiones previamente iniciadas podrían ser controladas. Esto no es ni práctico, ni mucho menos seguro, lo recomendable es que podamos iniciar sesión en modo gráfico en el escritorio remoto a partir de un prompt de nombre de usuario y password por validar.

XDMCP se configura de manera diferente, dependiendo el manejador de pantalla que estemos utilizando. Físicamente, sin importar el tipo de manejador de escritorio que estemos utilizando (GNOME, KDE, XFCE, etc.), se utiliza un manejador de pantalla para poder iniciar sesión en nuestro escritorio remoto, incluso cuando estamos sentados físicamente frente a él. Las opciones más comunes son: gdm, kdm y xdm. (Normlamente GNOME utiliza gdm, pero podría utilizar otro; KDE utiliza kdm pero podría ser otro, y así...)

xdm

Debe abrirse el archivo xdm-config y comentarse la línea con el texto

DisplayManager.requestPort :0

insertando un ! al inicio.

El usuario 'nobody' debería de tener asociada una terminal shell válida para poder iniciar sesión, por lo que hay que ejecutar:

usermod -s /bin/bash nobody

gdm
Debe ejecutarse gdmconfig, encontrar la pestaña llamada 'XDMCP' y habilitar esta opción.

En escritorios como XFCE, que a veces usan también gdm, la opción se encuentra, dentro del menú 'Configuración', en la pantalla 'Ventana de entrada', en la pestaña 'Remota' hasta abajo se encuentra el botón 'Configurar XDMCP' (obviamente hay que empezar por habilitar la pestaña Remota en los permisos de inicio de sesión dentro de esta misma pantalla).

kdm
Debe editarse el archivo kdmrc y habilitar XDMCP en el puerto 177:

[Xdmcp]
Enable=true
Willing=/etc/X11/xdm/Xwilling
Xaccess=/etc/X11/xdm/Xaccess
Port=177

seguridad
En caso de soportarlo, lo recomendable también es configurar quiénes pueden acceder a sesión. Esta configuración depende completamente del manejador de pantalla que se tenga pero no entraremos en detalle en este caso.

Más información aquí.

Opción 1 (x11vnc , control directo de la terminal física remota)
Como dijimos, se trata de manipular remotamente la pantalla 0, la cual X asocia por default a la terminal física de la máquina que llamaremos en adelante 'escritorio remoto'.

En 'escritorio remoto' hay que instalar entonces x11vnc y Xserver.

Hecho eso, se puede lanzar una línea como la siguiente:

x11vnc

Lo cual nos brindará información adicional sobre los parámetros que deberíamos de lanzar para autenticar nuestra sesión, entre otros.

Yo uso normalmente la siguiente línea:

x11vnc -auth /var/lib/gdm/:0.Xauth -display :0 -shared -forever -ncache -rfbport 5901 -rfbauth ./.vnc/passwd_x11vnc

En donde el parámetro -auth asocia el archivo :0.Xauth (que hay que localizar en el 'escritorio remoto' para cada caso particular) y de esa manera si mi escritorio remoto se quedó en la pantalla de login, poder hacer uso de la autenticación y así poder iniciar sesión. Si no se usa este parámetro, se tendría que tener la pantalla 0 ya dentro de sesión en el escritorio remoto para poder hacer uso del acceso remoto.

El parámetro -forever permite escuchar constantemente conexiones aunque estas se terminen, siempre y cuando no se cierre la sesión gráfica en 0

El parámetro -rfbport indica el número de puerto en que estará escuchando el 'escritorio remoto' para aceptar conexiones. 5901 es el puerto por default para VNC. Por cierto, no hay que olvidar abrir este puerto en el firewall del escritorio remoto.

El parámetro -rfbauth apunta a un archvio en el que previamente almacené un password para autenticar el acceso a mi servidor y así evitar que cualquiera que conozca la dirección IP de mi escritorio remoto se pueda conectar a mi terminal gráfica física 0 y por lo tanto ver o intervenir en mis sesiones directamente (este riesgo es MUY REAL, hay que generar el password siempre). Para generar el archivo del password, x11vnc debe ejecutarse con el parámetro -storepassword, por ejemplo:

x11vnc -storepassword /path/al/archivo_de_password

Aquí no entraremos en detalle para levantar x11vnc usando xinetd, pero el sitio oficial de x11vnc da más información. Además, traspolando un poco la información que daremos para la opción #2, se puede lograr levantar un servidor así.

Antes de concluir con x11vnc, hay que aclarar también que para poder inciar sesión remota también es necesario configurar el protocolo XDMCP como se explicó anteriormente...

Opción 2 (vnc, control de pantallas virtuales remotas)

En este caso se manipularán pantallas virtuales no directamente relacionadas con la terminal física del escritorio remoto. La idea será que dichas pantallas se creen a demanda también.

En el escritorio remoto habrá que tener instalado tanto el software que se usará como servidor VNC (tightvnc, ultravnc, realvnc, etc.) y Xserver.

Hecho eso se puede ejecutar la siguiente línea de comandos:

vncserver -query localhost -once -geometry 1024x768 -depth 16 :1

Con lo que se tendrá un servidor VNC en la pantalla virtual #1, y si esta no estuviera disponible, buscaría en la 2, y así sucesivamente.

El parámetro -once indica que sólo permitirá el inicio de sesión una vez, luego de terminar la cual cerrará el servidor. Esta opción es más útil aún usando un superservidor como se explica más adelante.

El parámetro -geometry 1024x768 define la resolución que tendrá la sesión en el escritorio remoto.

El parámetro -depth 16 indica la profundidad de color a obtener en la sesión remota, en este caso a 16 colores.

El parámetro :1 indica el número de pantalla virtual que se desea utilizar.

El parámetro -query localhost indica que se desea iniciar sesión en el escritorio remoto a través de XDMCP.

Para que se autentique a los usuarios, es necesario crear previamente el archivo de passwords con el programa vncpasswd. Por default, vncserver busca en $HOME/.vnc/passwd

Superservidor xinetd

Sin embargo, levantar manualmente un servidor de pantallas virtuales VNC no es la forma más óptima, ya que se tienen estos inconvenientes:

hay que levantar nuevamente el servidor cada vez que se termine de usar
solamente podrá entrar a sesión por VNC una persona, y si se tiene más de un usuario que pudiera iniciar sesión en el escritorio remoto (cada uno a su propia sesión), no se les permitiría.
además si no se está utilizando el servicio VNC en un momento dado, aún así se está consumiendo memoria en el servidor, con el programa a la escucha de posibles conexiones.

La solución implica levantar algo conocido como un superservidor, de los cuales xinetd es el más popular en GNU/Linux. El superservidor permite levantar a demanda instancias de los servidores configurados en él. Esto trae ventajas de menor consumo de memoria, además de permitir levantar instancias múltiples del servidor escuchando un sólo puerto (que atiende el superservidor). Y en cuanto se termine de usar el servidor en cuestión, el superservidor sigue atento para nuevas solicitudes. Un superservidor es útil para servidores que no están en constante uso o que no requieren de alta disponibilidad, podría ser (dependiendo las circunstancias, claro): telnet, ftp, o en nuestro caso vnc.

Una vez instalado xinetd, lo único que debe hacerse es agregar la configuración adecuada para utilizar VNC a través del mismo. Esta configuración se puede escribir en un archivo exclusivo para VNC, pero debe asegurarse de guardarse en donde xinetd lo lea, por lo regular en /etc/xinetd.d

El siguiente es un ejemplo de un servidor VNC levantado a través de xinetd:

service vnc
{
protocol = tcp
socket_type = stream
wait = no
user = user_name
server = /usr/bin/Xvnc
server_args = -inetd -query localhost -once -geometry 1024x768 -depth 16 -rfbauth=/home/user_name/.vnc/passwd
disable = no
}

Antes de utilizarlo, explicaré algunos detalles:

-El servidor que se mandó llamar utiliza el programa 'Xvnc', en vez de 'vncserver'. Leyendo la página del manual de vncserver (man vncserver), se puede constatar que en realidad vncserver es un wrapper que manda llamar en el fondo a Xvnc, por lo que este último programa será el indicado para llamar en las instancias que genere el superservidor.

-Los argumentos incluyen el parámetro -inetd que es necesario para que el servidor VNC sepa que fue mandado llamar desde un superservidor.

-Se incluye el parámetro -rfbauth=/path/passwd , el cual es la ruta al archivo de password a utilizar.

-El nombre de usuario 'user_name' se utilizó en este caso para que el servidor se ejecute a nombre de este usuario. Normalmente se utiliza el usuario 'nobody', pero este debe de tener permisos de lectura al archivo de password, por lo que otra opción implica ejecutar el servidor como otro usuario, con acceso al archivo de password en una ruta particular.

-Si se utiliza TightVNC, las opciones de configuracion no deben incluir el caracter '=', sino que hay que sustituirlos por espacios

Una vez configurado el servicio, hay que reiniciar xinetd:

/etc/init.d/xinetd restart

(o cualquiera que sea la manera de hacerlo en tu distribución en particular).

No hay que olvidar abrir el puerto 5901 (que es el default de VNC, en realidad es el puerto 5900 + N, donde N será el número de pantalla virtual que se utilice) para escuchar las peticiones a conectarse.

Igualmente no olvidar que aunque muchos usuarios se puedan conectar al servidor VNC, sólo una persona a la vez podrá entrar a una sesión en particular. Si hay más de una sesión disponible en el servidor, cada una podrá ser iniciada una vez, pero no pueden entrar a sesión más de una vez por nombre de usuario.

En este link, se da más información y la posibilidad de levantar más de un servidor con xinetd para escuchar en distintos puertos, para tener la posibilidad de conectarse con distintas resoluciones al mismo servidor VNC.

Algunos servidores VNC (como Tight VNC) permiten conectarse también vía http en un navegador web, utilizando un applet de Java. Hay que consultar la documentación de cada caso particular para poder lograr esto. De entrada, lo que normalmente se hace es utilizar el puerto 5800 + N para obtener esta conexión.

DBUnit lo hace facil

2010-08-26T01:56:00.000-07:00

Dado que he trabajado con JUnit y DBUnit y he encontrado en ellos unas buenas herramientas para probar el codigo de las aplicaciones en java, pues me dí a la tarea de investigar un poquito sobre como obtener datasets desde una BD, y como cargarlos para realizar pruebas específicas. Fue entonces cuando me encontré con este artículo de Bill Siggelkow y me dí a la tarea de traducir una parte, también he agregado notas mías, pero pueden encontrar el original en enlace al final del post.

Y dice así:
Si desarrollas aplicaciones que acceden a datos relacionales necesitas verificar el código de tu aplicación trabaje con los datos, como fue diseñado. Cuando usas Hibernate o algún otro framework que implemente JPA, deberías confirmar que tus mapeos dirijan a Hibernate para almacenar y recuperar la información correctamente. Yo implemento este tipo de pruebas usando JUnit. Nadie puede refutar que las pruebas contra una base de datos activa es fundamental - no hay una mejor forma para verificar tus mapeos.

Pero para probar contra la base de datos se requiere que los datos se encuentren en un estado inicial. Puedes cargar la base de datos manualmente antes de correr tu prueba pero eso se vuelve monotono y propenso a errores. DBUnit resuelve este problema. Este puede precargar la base de datos para cada una de tus pruebas, basado en un grupo de datos dentro de un xml (comúnmente llamado dataset). El formato de este dataset es sencillo de entender; aquí hay un ejemplo de tres tablas de una base de datos MySQL. Los nombres de los elementos empatan con los nombres de las tablas y sus atributos con los nombres de sus columnas. Cada elemento implica un registro en esa tabla.

<dataset>
    <cliente id_cliente="778899" id_estatus = "1" id_sucursal="98765"/>
    <banco id_banco="1" nombre="BNMX" descripcion="Banamex" activo="1"
valor="0"/>
    <pago id_cliente = "778899" id_estatus = "1" id_tipo_producto =
"1" id_promotor = "1" id_sucursal = "58" />
</dataset>

Para una base de datos pequeña donde solo necesitas cargar unas pocas tablas con unos pocos registros puedes crear el dataset manualmente. Pero seguramente no querás hacerlo con una base de datos empresarial compleja que contiene cientos de tablas con nombres de columnas complejas. Es más facil si le permites a DbUnit extraer los datos por ti.

Aquí esta un proceso típico que sigues cuando usas DBUnit:

Poblar las tablas de tu base de datos como sea necesario para ejecutar tu prueba.
Extraer los datos desde esas tablas hacia un dataset XML. En el método setUp de tu prueba unitaria, llamar a DBUnit para cargar la base de datos desde los dataset's recientement creados.

Puedes extraer los datos usando una clase como esta:

import java.io.FileOutputStream;
import java.sql.Connection;
import java.sql.DriverManager;

import org.dbunit.database.DatabaseConnection;
import org.dbunit.database.IDatabaseConnection;
import org.dbunit.database.QueryDataSet;
import org.dbunit.dataset.IDataSet;
import org.dbunit.dataset.xml.FlatXmlDataSet;

public class ExtractTestDataSet {
    public static void main(String[] args) throws Exception {
        // conexion a la base de datos
        Class driverClass = Class.forName("com.mysql.jdbc.Driver");
        Connection jdbcConnection = DriverManager.getConnection(
                "jdbc:mysql://localhost/bon_app", "scott", "tiger");
        IDatabaseConnection connection = new DatabaseConnection(jdbcConnection);
        // exportar un dataset parcial
        QueryDataSet partialDataSet = new QueryDataSet(connection);
        partialDataSet.addTable("recipe", "SELECT * FROM recipe where
is_deleted != 'Y'");
        partialDataSet.addTable("recipe_ext_xref");
        FlatXmlDataSet.write(partialDataSet,
                new FileOutputStream("partial-dataset.xml"));
        // exportacion de la base de datos completa!!
        IDataSet fullDataSet = connection.createDataSet();
        FlatXmlDataSet.write(fullDataSet, new
FileOutputStream("full-dataset.xml"));
    }
}

DBUnit puede crear un dataset con todos los datos en tu base de datos configurándole solamente una conección JDBC abierta En la práctica, probablemente querá limitar el dataset a tablas específicas y datos usados por tu prueba unitaria. En el ejemplo anterior se esta creando dos archivos dataset. El primero como partial-dataset.xml, representa solo una porcion de la base de datos. DBUnit pobla el dataset basado en tablas y queries especificados. Si solo indicas el nombre de una tabla, el dataset se llenará de todos los registros y columnas en esa tabla. Especifia una tabla y un query y DBUnit solo extraerá los datos devueltos por el query. Si quieres la base de datos completa en el dataset, simplemente llama el metodo IDatabaseConnection.createDataSet().

En el método setUp() de tu prueba unitaria, usas el dataset como entrada para una operacion DBUnit. DBUnit soporta varias combinaciones de operacion para borrar, insetar y ctualizar la base de datos usando un dataset. Las operaciones más comunes son CLEAN_INSERT (limpia toda la tabla e inserta los registros del dataset) y REFRESH (solo agrega los registros del dataset a la tabla y si estos ya existen, los actualiza - con base en el id de la tabla). CLEAN_INSERT es la opcion a usar si tienes tu propia instancia de base de datos y no necesitas preocuparte por ponerle el pie a alguien más del equipo de desarrollo. Por otro lado, si compartes tu base de datos con el equipo, tu mejor amigo es REFRESH.

En el siguiente fragmento de una prueba unitaria, se está usando CLEAN_INSERT para reinicializar la base de datos antes de cada método de prueba.

protected void setUp() throws Exception {
    setUpDatabase();
}

private void setUpDatabase() throws Exception {
    // Inicializa tu base de datos aquí
    Class driverClass = Class.forName("com.mysql.jdbc.Driver");
    Connection jdbcConnection = DriverManager.getConnection(
"jdbc:mysql://localhost/bon_app", "scott", "tiger");
    IDatabaseConnection connection = new DatabaseConnection(jdbcConnection);

// inicializa tu dataset aquí
    IDataSet dataSet = new FlatXmlDataSet(new File("full-dataset.xml"));
    try {
        DatabaseOperation.CLEAN_INSERT.execute(connection, dataSet);
    } finally {
        connection.close();
    }
}

Esta forma trabaja bien pero es algo molesto que tengas que hacer código a mano y recompilar la clase que extrae cuando sea necesariocambiar como DBUnit crea los dataset. Usando Spring se le puede delegar el trabajo de configurar la clase de extracción de datos y esto salvaría un montón de código hecho a mano. Esto resulta en la siguiente clase:

package com.jadecove.bonappetit.test;
import java.io.FileOutputStream;
import java.sql.Connection;

import java.util.Iterator;
import java.util.List;
import java.util.Map;
import java.util.regex.Matcher;
import java.util.regex.Pattern;
import javax.sql.DataSource;

import org.apache.log4j.Logger;
import org.dbunit.database.DatabaseConfig;
import org.dbunit.database.DatabaseConnection;
import org.dbunit.database.IDatabaseConnection;
import org.dbunit.database.QueryDataSet;
import org.dbunit.dataset.IDataSet;
import org.dbunit.dataset.xml.FlatXmlDataSet;

/**
* Extracts a DBUnit flat XML dataset from a database.
*
* @author Bill Siggelkow
*/
public class DBUnitDataExtractor {
    private DataSource dataSource;
    private String dataSetName = "dbunit-dataset.xml";
    private List queryList;
    private List tableList;
    private Map dbUnitProperties;
    private Map dbUnitFeatures;
    private String schema;

    /**
    * A regular expression that is used to get the table name
    * from a SQL 'select' statement.
    * This  pattern matches a string that starts with any characters,
    * followed by the case-insensitive word 'from',
    * followed by a table name of the form 'foo' or 'schema.foo',
    * followed by any number of remaining characters.
    */
    private static final Pattern TABLE_MATCH_PATTERN = Pattern.compile(".*\s+from\s+(\w+(\.\w+)?).*", Pattern.CASE_INSENSITIVE);
    private static final Logger log = Logger.getLogger(DBUnitDataExtractor.class);

    /**
    * The data source of the database from which the data will be
    extracted. This property
    * is required.
    *
    * @param ds
    */
    public void setDataSource(DataSource ds) {
        dataSource = ds;
    }

    /**
    * Set the schema.
    * @param schema
    */
    public void setSchema(String schema) {
        this.schema = schema;
    }

    /**
    * Name of the XML file that will be created. Defaults to
    <code>dbunit-dataset.xml</code>.
    *
    * @param name file name.
    */
    public void setDataSetName(String name) {
        dataSetName = name;
    }

    /**
    * Performs the extraction. If no tables or queries are specified,
    data from entire database
    * will be extracted. Otherwise, a partial extraction will be performed.
    * @throws Exception
    */
    public void extract() throws Exception {
        Connection conn = null;
        try {
            conn = dataSource.getConnection();
            log.info("Beginning extraction from '"+conn.toString()+"'.");
            IDatabaseConnection connection = new DatabaseConnection(conn, schema);
            configConnection((DatabaseConnection) connection);
            if (tableList != null || queryList != null) {
                // partial database export
                QueryDataSet partialDataSet = new QueryDataSet(connection);
                addTables(partialDataSet);
                addQueries(partialDataSet);
                FlatXmlDataSet.write(partialDataSet, new FileOutputStream(dataSetName));
            } else {
                // full database export
                IDataSet fullDataSet = connection.createDataSet();
                FlatXmlDataSet.write(fullDataSet, new
                FileOutputStream(dataSetName));
            }
        }
        finally {
            if (conn != null) conn.close();
        }
        log.info("Completed extraction to '"+dataSetName+"'.");
    }

    /**
    * List of table names to extract data from.
    *
    * @param list of table names.
    */
    public void setTableList(List list) {
        tableList = list;
    }

    /**
    * List of SQL queries (i.e. 'select' statements) that will be used executed to retrieve
    * the data to be extracted. If the table being queried is also specified in the <code>tableList</code>
    * property, the query will be ignored and all rows will be extracted from that table.
    *
    * @param list of SQL queries.
    */
    public void setQueryList(List list) {
        queryList = list;
    }

    public void setDbUnitFeatures(Map dbUnitFeatures) {
        this.dbUnitFeatures = dbUnitFeatures;
    }

    public void setDbUnitProperties(Map dbUnitProperties) {
        this.dbUnitProperties = dbUnitProperties;
    }

    private void configConnection(DatabaseConnection conn) {
        DatabaseConfig config = conn.getConfig();
        if (dbUnitProperties != null) {
            for (Iterator k=dbUnitProperties.entrySet().iterator(); k.hasNext(); ) {
                Map.Entry entry = (Map.Entry) k.next();
                String name = (String) entry.getKey();
                Object value = entry.getValue();
                config.setProperty(name, value);
            }
        }
        if (dbUnitFeatures != null) {
            for (Iterator k=dbUnitFeatures.entrySet().iterator(); k.hasNext(); ) {
                Map.Entry entry = (Map.Entry) k.next();
                String name = (String) entry.getKey();
                boolean value = Boolean.valueOf((String)entry.getValue()).booleanValue();
                config.setFeature(name, value);
            }
        }
    }

    private void addTables(QueryDataSet dataSet) {
        if (tableList == null) return;
        for (Iterator k = tableList.iterator(); k.hasNext(); ) {
            String table = (String) k.next();
            dataSet.addTable(table);
        }
    }

    private void addQueries(QueryDataSet dataSet) {
        if (queryList == null) return;
        for (Iterator k = queryList.iterator(); k.hasNext(); ) {
            String query = (String) k.next();
            Matcher m = TABLE_MATCH_PATTERN.matcher(query);
            if (!m.matches()) {
                log.warn("Unable to parse query. Ignoring '" + query +"'.");
            }
            else {
                String table = m.group(1);
                // only add if the table has not been added
                if (tableList != null && tableList.contains(table)) {
                    log.warn("Table '"+table+"' already added. Ignoring '" + query + "'.");
                } else {
                    dataSet.addTable(table, query);
                }
            }
        }
    }
}

Esta clase sirve como una envoltura compatible con Spring sobre el proceso de extracción de DBUnit, aunque no tenga dependencia con Spring (eso es lo bonito de Spring). Aquí esta como puedes configurar el extractor en un archivo de beans de Spring.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd"><beans>
    <bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
        <property name="driverClassName"><value>com.mysql.jdbc.Driver</value></property>
        <property name="url"><value>jdbc:mysql://localhost/bon_app</value></property>
        <property name="username"><value>scott</value></property>
        <property name="password"><value>tiger</value></property>
    </bean>

    <bean id="dbUnitDataExtractor" class="com.jadecove.bonappetit.test.DBUnitDataExtractor">
        <property name="dataSource" ref="dataSource"/>
        <property name="dataSetName" value="dbunit-dataset.xml"/>
        <property name="tableList">
            <list>
                <value>recipe</value>
                <value>recipe_ext_xref</value>
            </list>
        </property>
        <property name="queryList">
            <list>
                <value>select * from bon_app_ext.person where first_name = 'Bill'</value>
            </list>
        </property>
    </bean>
</beans>

Ahora puedes extraer datasets de DBUnit recuperando un extractor configurado vía Spring y llamando al método extract(). La única propiedad requerida es la fuente de datos. Haciendolo así puedes obtener la base de datos completa, pero también puedes listar tablas y queries específicos. Además, la configuración de Spring te permite agregar otros elementos y propiedades que configuren a DBUnit de diferentes maneras, revisa la API de DBUnit para saber qué más cosas puedes usar al respecto.

Cuando estas usando queries, DBUnit requiere que se especifique ambos, el nombre de la tabla y el query Para hacer una configuración más sencilla, este extractor usa una expresión regular que determina el nombre de la tabla.

Este extractor se ha usado con una base de datos empresarial compleja local MySQL, pero a través de la configuración de la conexión, esquema y características de DBUnit puedes extraer los datos desde la mayoría de bases de datos. En mi actual trabajo de consultoría, yo uso este extractor para obtener datos desde algunas bases de datos complejtas DB2 corriendo en un AS-400 de IBM.

Este ejercicio no solo ayudó a hacer la vida más fácil con DBUnit, esto me ayudó a entender que tan fácil es delegar estas tareas mundanas a Spring.

Fuente:
http://www.oreillynet.com/onjava/blog/2005/10/dbunit_made_easy.html

Configurar JasperReports en Spring 3.0

2010-08-25T12:59:00.000-07:00

Cada vez es más sencillo realizar las configuraciones en Spring. A pesar de que la configuración se puede seguir usando de diferentes maneras, en la documentación de referencia de spring 3 indica lo siguiente de forma general:

Agregar dependencias a tu proyecto
Configurar el ViewResolver
Crear el template con iReports
Configurar las vistas
Crear el controller

Ahora vamos a los detalles.

1. Las dependencias que nos dice debemos tener son las siguientes:

Obviamente el Jasper

        <dependency>
            <groupId>jasperreports</groupId>
            <artifactId>jasperreports</artifactId>
            <version>3.5.3</version>
        </dependency>

• BeanShell (esta no la ocupe)

• Commons BeanUtils (esta no la ocupe)

• Commons Collections (esta es requerida)

        <dependency>
            <groupId>commons-collections</groupId>
            <artifactId>commons-collections</artifactId>
            <version>3.2.1</version>
        </dependency>

• Commons Digester (esta no la ocupe)

• Commons Logging (esta es para logear, si ya usas otra, puedes omitirla)

• iText (esta es por si generas PDF pero yo no la ocupe)

• POI (esta es para generar archivox XLS)

        <dependency>
            <groupId>org.apache.poi</groupId>
            <artifactId>poi</artifactId>
            <version>3.2-FINAL</version>
        </dependency>

2. Configurar el ViewResolver via un properties

Antes ya lo había hecho mediante la clase de spring XmlViewResolver para configurar las vistas en un archivo xml (views.xml) pero me pareció más sencillo mediante un archivo properties y por eso difundo esta alternativa.

<bean id="viewResolver" class="org.springframework.web.servlet.view.ResourceBundleViewResolver">
<property name="basename" value="views"/>
</bean>

Se esta configurando una instancia de ResourceBundleViewResolver que busca por los mapeos de las vistas en un archivo properties con el nombre indicado por la propiedad basename, en este caso views.properties. Donde colocarlo? en el classpath de la aplicación.

El contenido del archivo views.properties se explica en el punto 4.

3. Crear el Template con iReports (yo trabajé con la version 3.5.3)

Una cosa que se debe tomar en cuenta es que se debe usar la misma version de iReports que la que se esta usando en el jar como dependencia.

Descarga la aplicacion iReports desde la pagina. Luego instalala y cuando la abras basta con que crees un proyecto en blanco. Este se guarda como un archivo .jrxml que básicamente es un xml plano.

Puedes encontrar un buen manual de uso de iReports aqui.

Cuando se compila un archivo jrxml, se genera otro con el mismo nombre .jasper, el cual es necesario indicar en la configuración de spring para que se genere el reporte en el formato deseado.

4. Configurar las vistas en el archivo properties.

El framework de spring contiene 5 diferentes implementaciones para crear reportes con Jasper, cuatro de ellas corresponden a formatos específios (csv, pdf, html y xls) y una que permite determinar una de las anteriores en tiempo de ejecución (JasperReportsMultiFormatView).

Para generar un reporte en pdf, por ejemplo, vamos usar el siguiente contenido en nuestro archivo views.properties:

reciboPago.(class)=org.springframework.web.servlet.view.jasperreports.JasperReportsPdfView
reciboPago.url=/WEB-INF/jasperTemplates/recibo.jasper
reciboPago.reportDataKey=reciboKey

El nombre de la vista es "reciboPago", su propiedad class define la clase de jasper que la mapea, en este caso es la clase que genera PDFs. Es importante que esta propiedad esté configurada como .(class) y no .class debido a que spring busca este valor vía la propiedad y no usando el acostumbrado getter/setter. De esta manera se entiende que si no usamos los paréntesis, spring lo interpreta como el hecho que debe usar el getter/setter de dicha propiedad para acceder a su valor.

La propiedad url se utiliza para definir la ruta de acceso al archivo compilado por el programa iReports, en este caso se esta colocando dentro de la carpeta WEB-INF de la aplicación.

Finalmente reportDataKey define el nombre llave para obtener de un mapa el POJO o DTO que contiene cada valor a mostrar en el reporte. En este caso, se le esta diciendo a spring que su fuente de datos se encuentra en la llave "reciboKey" del mapa a recibir (ver punto 5, sobre el controller).

5. Crear el controller.

Es sumamente sencillo generar un controller en spring mediante las anotaciones:

@Controller
@RequestMapping("/pago")
public class PagoController {
    @RequestMapping(value="/recibo", method=RequestMethod.GET)
    public String generarReciboPago(ModelMap modelMap, HttpServletResponse response) {
        List<ReciboDTO> lista = new ArrayList<ReciboDTO>(1);
        ReciboPagoJasperDTO dto = new ReciboDTO();
        dto.setMonto("6789.0");
        dto.setNombre("Pedro Romero");
        lista.add(dto);
        response.setHeader("Content-type", "application/pdf");
        response.setHeader("Content-Disposition","attachment; filename=\"recibo.pdf\"");
        JRBeanCollectionDataSource jrbean = new JRBeanCollectionDataSource(lista, false);
        modelMap.put("reciboKey", jrbean);
        return("reciboPago");
    }
}

@Controller define a la clase como un controller y @RequestMapping define una uri desde la cual se puede acceder a nuestro controller cuando nuesta aplicación ya está montada en un server. Si la aplicacion levanta en un contexto "proyecto" y el servidor levanta en un puerto local 8080, podriamos acceder a nuestro controller anterior como: "http://localhost:8080/proyecto/pago/recibo", aunque esto es asunto de otro tema, basta con observar como se concatenan los valores del contexto de la aplicación, y de las anotaciones @RequestMapping de clase y método usado.

En este caso ReciboDTO es el pojo usado para portar los valores que alimentaran el reporte, se inserta en una instancia de JRBeanCollectionDataSource y luego se agrega al mapa del modelo con el key: reciboKey (observa que es el mismo metodo que usamos en el properties.

Finalmente se devuelve una cadena que indica el nombre de la vista configurada en el properties, la cual esta mapeada a la clase jasper: JasperReportsPdfView.

Notas importantes:

Spring nos provee de la capacidad de agregar elementos dentro de una Collection, dado que internamente Spring los envuelve dentro de un objeto JRBeanCollecionDataSource (implementa interface JRDataSource), también nos da la capacidad de agregar mas beans al modelo en diferentes llaves del mapa, ejemplo:

modelMap.put("reciboKey", jrbean);
modelMap.put("myKey1", jrbean1);
modelMap.put("personal2", jrbean2);

El punto está en que si la vista no esta apuntando a uno de estas llaves en particular (mediante la propiedad de la vista: reportDataKey), usará la primera instancia de JRDataSource que encuentre.

Servidor de correos personal con postfix - Spambayes

2010-08-24T11:38:00.001-07:00

Éste es el último post de 'Servidor de correos personal con postfix'. Ya configurado el mismo (MTA, MDA, MUA) y recuperando automáticamente correos con Fetchmail, sólo queda velar por la seguridad del servidor...

Se llama spam o correo basura a los mensajes no solicitados, no deseados o de remitente desconocido, habitualmente de tipo publicitario, enviados en grandes cantidades (incluso masivas) que perjudican de alguna o varias maneras al receptor.

El spam se puede convertir en una incidencia de seguridad por varias razones:

ocupa espacio en las bandejas de entrada de los receptores. En los casos de cuentas con tamaño limitado esto es un problema.
en sistemas vulnerables, el spam suele llegar también acompañado de scripts perniciosos, a ejecutar en el sistema receptor, o un link engañoso para infectar la máquina cliente.
también puede incluir información engañosa con la cual realizar un robo de información confidencial, engañando al usuario incauto

Claro está, la mejor política de seguridad en estos casos es ser prudente y no dar click y descargar todo lo que llegue a la bandeja de entrada del correo.

Sin embargo, los servidores de correo también cuentan con protección extra ante esta problemática. En nuestro caso, vamos a configurar Spambayes como detector de spam. Existen muchos otros programas que realizan funciones similares, el más famoso es Spamassasin. Sin embargo en este tutorial nos enfocaremos en Spambayes.

Instalación
Spambayes se puede descargar desde su sitio oficial, o puede instalarse con la distribución. En Debian el paquete se llama spambayes.

Configuración

Spambayes es una serie de scripts en Python que utilizan algoritmos de probabilidad para clasificar el correo, si es spam (correo no deseado), ham (correo seguro) o inseguro (no se sabe si es o no spam). Debe entrenarse constantemente la red bayesiana en la que se basa el software para refinar cada vez más su comportamiento.

En la sección del MDA (Procmail) ya creamos los subdirectorios necesarios para que funcione Spambayes, así que continuaremos con la configuración. Como parte de la configuración, es necesario configurar Spambayes, pero también Procmail para que sepa dónde colocar los correos identificados, y además mutt para agregar unas cuantas utilidades que pueden servir para tratar con los distintos tipos de mensajes.

1) Spambayes

El subdirectorio ~/Mail contendrá nuestro correo seguro.
El subdirectorio ~/.CaughtSpam contendrá el correo que Procmail defina como Spam de acuerdo a lo que Spambayes le indique.
El subdirectorio ~/.Unsure contendrá correo que Spambayes no sepa clasificar.
Para propósitos de entrenamiento, en ~/Mail/.MissedHam y ~/Mail/.MissedSpam iremos colocando correos que lleguen a las bandejas equivocadas, de forma que a la siguiente ronda de entrenamiento de Spambayes, sepa en adelante como clasificar dichos correos.

El script de entrenamiento es el siguiente: ~/Mail/train_spambayes

#!/bin/sh
# Script to copy mail missed spam and ham into correct folders
# and run sb_mboxtrain.py to train spambayes
# Training will be done only on missed spam and ham

# Files we saved or bounced may be in the new directory
# We want them in cur for training
mv /home/usuario/Mail/.MissedSpam/new/* \
 /home/usuario/Mail/.MissedSpam/cur 2>/dev/null
mv /home/usuario/Mail/.MissedHam/new/* \
 /home/usuario/Mail/.MissedHam/cur 2>/dev/null
/usr/bin/sb_mboxtrain.py -d /home/usuario/.hammie.db \
 -g /home/usuario/Mail/.MissedHam \
 -s /home/usuario/Mail/.MissedSpam

Obviamente, hay que editarlo según la cuenta de usuario y directorios usados en el servidor. Este script debe ser ejecutable:

$ chmod +x ~/Mail/train_spambayes

Además hay que crear la base de datos en donde Spambayes se entrenará:

$ /usr/bin/sb_filter.py -d $HOME/.hammie.db -n

lo cual creará el archivo .hammie.db

Por último, será útil que el servidor se dedique automáticamente a entrenar la red bayesiana cada cierto tiempo sin intervención del usuario, para lo que creamos un cronjob con

$ crontab -e

y colocamos el cronjob:

21 3 * * * ~/Mail/train_spambayes

que entrenará a las 3:21am de todos los días.

2) Procmail

Ahora hay que decirle a Procmail que, dependiendo lo que diga la base de datos con la red bayesiana entrenada, clasifique los correos entrantes en los subdirectorios que creamos previamente. Editar .procmailrc para que quede así (editarlo para que coincida con los directorios y usuario en el servidor):

SHELL=/bin/sh
MAILDIR=$HOME/Mail
DEFAULT=$HOME/Mail/
CAUGHT_SPAM=$MAILDIR/.CaughtSpam/
UNSURE=$MAILDIR/.Unsure/
  
#Spambayes process
:0fw:hamlock
| /usr/bin/sb_filter.py -d /home/usuario/.hammie.db

:0
* ^X-Spambayes-Classification: spam
${CAUGHT_SPAM}

:0
* ^X-Spambayes-Classification: unsure
${UNSURE}

# Catches everything else.
# Anything left over goes into the DEFAULT folder
:0:
${DEFAULT}

Lo que hicimos fue decirle a Procmail que con el script sb_filter.py clasifique el correo, y lo mande a los directorios de CaughtSpam, Unsure o el Default (~/Mail).

3) mutt

Por último, si observamos la bandeja de entrada con mutt, es probable que encontremos correo que deseemos clasificar como Spam. La opción manual sería mover manualmente estos correos a los directorios creados, a través de los comandos de mutt.

Sin embargo, esto no es funcional, por lo que editaremos el archivo .muttrc para agregar un poco de automatización que facilite este proceso.Editarlo para que quede así:

set editor="emacs"
set folder = /home/usuario/Mail
set signature="~/.signature"
my_hdr From: Nombre Usuario
# Don't ask to move read message
set move=no

# Header control   h displays header when in pager
# I want to only see the unignored by default
ignore *                                        # weed out all headers
unignored date from: to cc subject organization  # now show me these...

# Setting these macros is going to save us all of that time I was
#  talking about.  Now instead of having to type all of those
#  characters to move the mail around we will can just tag the messages
#  and, for the instance of spam in your inbox, hit 'S'.
  
# Move mail to correct directories
macro   index   S       ";s~/Mail/.MissedSpam\r\r$\r"
macro   pager   S       ";s~/Mail/.MissedSpam\r\r$\r"
macro   index   H       ";C~/Mail/.MissedHam\r\r;s~/Mail\r\r$\r"
macro   pager   H       ";C~/Mail/.MissedHam\r\r;s~/Mail\r\r$\r"
macro   index   M       ";s~/Mail/\r"
macro   pager   M       ";s~/Mail/\r"

# This is how we are going to move around to the different
#  mailboxes.  Hitting 'alt-1' will take us to our inbox
#  'alt-2' and we are looking at the mail Spambayes classified
#  as spam.  etc.
#  The extra mailboxes I have in here are for mailing lists I am on.
#  I will show the procmail recipe that automatically puts
#  the mailing list mail into its correct mailbox further down.
  
# Move to mailboxes quickly
macro   index   1  "c~/Maildir\r"
macro   pager   1  "c~/Maildir\r"
macro   index   2  "c~/Maildir/.CaughtSpam\r"
macro   pager   2  "c~/Maildir/.CaughtSpam\r"
macro   index   3  "c~/Maildir/.Unsure\r"
macro   pager   3  "c~/Maildir/.Unsure\r"

# Training Maildirs for Spam and Ham
macro   index   8  "c~/Maildir/.MissedSpam\r"
macro   pager   8  "c~/Maildir/.MissedSpam\r"
macro   index   9  "c~/Maildir/.MissedHam\r"
macro   pager   9  "c~/Maildir/.MissedHam\r"

# Setting these colors makes it easy to tell which emails
#  Spambayes has missed.
# Turn spam red and unsure green
color index red default "~h '^X-Spambayes-Classification: spam'"
color index green default "~h '^X-Spambayes-Classification: unsure'"
# Turn gmail mail brightblue
#  (My regular expression is not correct here.  I think that it
#   is looking anywhere in the header for my gmail address
#   instead of what I wanted..  Just in the 'To:'.
#   It still works for the most part)
color index brightblue default "~h '(^)*my_name@gmail.com'

# Lets set more colors to make things look beautiful.  Judging by
#  my title for this section I must have had bad feelings towards
#  colors when I added this.
#Color crap
color index brightwhite default ~N       # color for new messages
color status black yellow
color attachment brightyellow default    # file attachments
color search brightred default           # search matches
color quoted brightyellow default        # quoted text in replies
color quoted1 magenta default            # quoted text in replies
color body cyan default "((ftp|http|https)://|news:)[^ >)\"\t]+"   # URLs
color body cyan default "[-a-z_0-9.+]+@[-a-z_0-9.]+"               # email

Con esto conseguimos que mutt nos proporcione lo siguiente:

Si estamos ante un mensaje que debió clasificarse como Spam y no lo fue (en la bandeja de entrada o en Unsure), tecleando 'S' se mueve a los directorios correctos (CaughtSpam y MissedSpam) en espera del siguiente entrenamiento.
Si estamos ante un mensaje que debió clasificarse como Ham y no lo fue (en la bandeja de Spam o en Unsure), tecleando 'H' se mueve a los directorios correcots (bandeja de entrada y MissedHam) en espera del siguiente entrenamiento.
Podemos seleccionar varios mensajes a la vez con el comando 't'.
Esc + 1 nos lleva directamente a la bandeja de entrada.
Esc + 2 al spam
Esc + 3 a Unsure
Esc + 8 a MissedSpam
Esc + 9 a MissedHam
Además, dependiendo el tipo de correo, mutt utilizará colores (si la consola los soporta) para mostrar los distintos tipos de mensajes.

Spambayes es una herramienta bastante poderosa, que también permite entrenar para clasificar correos con base en otros criterios, por ejemplo si estuviéramos suscritos a un mailing list, colocar los correos de dicha lista de correos en un directorio particular; o si recibiéramos correos de ofertas de trabajo para colocar todos ellos en otro subdirectorio, etc.

Notas Finales
Con esto damos por terminado el tutorial para levantar un servidor de correos personal utilizando Postfix.

Aún quedan detalles por afinar, que podrían investigarse. Si algún día tengo el tiempo, tal vez haga tutoriales para los mismos:

Levantar un servidor de correos que pueda usar en una organización, a través de una LAN o internet, es cuestión que debe configurarse en Postfix. La documentación del sitio oficial de este programa ofrece varios escenarios para lograr distintas configuraciones deseadas.
Levantar servidores POP e IMAP, con Courier por ejemplo, para poder leer los correos que lleguen a la cuenta en el servidor a través de internet, con Squirrelmail, con un dispositivo móvil, con un cliente convencional en otra máquina, o con Fetchmail en otra máquina cliente.
Ampliar el funcionamiento de Spambayes para que clasifique correos con base en criterios como el uso de mailing lists o aquellos que pertenezcan a mis búsquedas de empleo, por ejemplo.

Espero hayas disfrutado siguiendo este tutorial, como yo haciéndolo. Y sobre todo, levantando tu propio servidor de correos. A mi me llevó meses enterarme bien de cómo funciona todo esto, y lograr que funcionara correctamente. Ojalá esta pequeña guía sirva de ayuda para el que se aventure en un camino similar...

Servidor de correos personal con postfix - Fetchmail

2010-08-24T11:38:00.000-07:00

Con este post continuamos con el 'Servidor de correos personal con postfix'. Una vez configurados el MTA, el MDA y el MUA, quedan detalles por afinar...

Fetchmail es un programa para recuperar correos desde servidores remotos. En realidad no es más que un cliente para los protocolos POP, IMAP, entre otros, que en lugar de desplegar los mensajes de correo (como cualquier cliente convencional de estos protocolos) los descarga para que sean recibidos en la máquina especificada y leídos posteriormente.

Es útil para conexiones de internet intermitentes (que no siempre están en línea), o para mantener una bandeja de entrada sincronizada con un servicio de correo remoto, como será el caso de este tutorial.

Obra del renombrado hacker Eric S. Raymond, Fetchmail es incluso el ejemplo clásico utilizado en su escrito 'La Catedral y el Bazar' para ilustrar cómo el proceso de desarrollo open source es un éxito, y no un caso aislado como se pensaba hasta el momento del kernel Linux. Este escrito fue de hecho la chispa que encendió el furor por el open source en el mundo empresarial, con lo que Netscape liberó el código fuente de su navegador (del que Mozilla Firefox es su heredero), y demás aventuras y desventuras del mundo del open source y el software libre desde entonces (1998)...

Aquí lo vamos a utilizar para recuperar los correos de una cuenta de Gmail (aunque podría ser cualquier otra, ¡o varias! siempre y cuando acepten los protocolos POP, IMAP o similares) cada cierto tiempo.

Instalación
Fetchmail se puede descargar desde su sitio oficial. O como siempre, puede instalarse desde la distribución de GNU/Linux que se tenga. En el caso de Debian el paquete es fetchmail.

Si se desea también se puede instalar el paquete fetchmailconf que es un script en Python, modo gráfico, para configurar fácilmente el programa.

Configuración
Aunque se utilice fetchmailconf, aquí describiremos el tras bambalinas de la configuración de Fetchmail, para entender cómo funciona.

Todo se hace en archivos RC, que pueden ser por usuario (~/.fetchmailrc) o de todo el sistema (/etc/fetchmailrc).

El archivo deberá contener las siguientes líneas:

set postmaster "postmaster"
set bouncemail
set no spambounce
set properties ""
set daemon 600

poll pop.gmail.com with proto POP3 port 995
     user 'gmailuser@gmail.com' there with ssl with
     password 'password' is 'usuarioservidor' here options
     keep

Obviamente, hay que editar la información pertinente para la cuenta de Gmail, el password y el nombre de usuario del sistema.

La línea daemon establece que fetchmail quedará ejecutándose en segundo plano, y que revisará por nuevos correos en la o las cuentas especificadas cada 600 segundos (10 minutos).

Se pueden tener tantas líneas poll como se desee, una por cuenta de correo que se desee sincronizar.

Más información se encuentra en la documentación de Fetchmail.

Uso
Bastará habilitar el script de inicio del servicio de Fetchmail en /etc/init.d para comenzar a ejecutarlo.

¡Listo! el servidor de correo personal ya está tomando forma. Cada 600 segundos (o el tiempo que se hubiera especifidado), Fetchmail debería de revisar la bandeja de la cuenta establecida, y en caso de encontrar nuevos correos, descargarlos. De hecho en el archivo de log de Postfix (/var/log/mail.info) debería de observarse actividad, cada 600 segundos cuando se despierte Fetchmail y se vuelva a dormir, además de cuando llegue a descargar correos.

Por último, vamos a enfocarnos en la seguridad, en el caso particular de este tutorial, a protegernos del spam...

Servidor de correos personal con postfix - MUA

2010-08-24T11:37:00.002-07:00

Continuamos con los posts dedicados a configurar un 'Servidor de correo personal con postfix'.

Previamente ya configuramos el MTA, Mail Transfer Agent y el MDA, Mail Delivery Agent.

Ahora vamos por el MUA, Mail User Agent, el cliente para leer y enviar correos. Normalmente esta parte es la que la gente toma como si fuera todo el sistema de correo, pero como ya hemos podido ver se trata de toda una infraestructura de sistemas.

En este tutorial vamos a configurar mutt como cliente de correo. Se trata de un cliente de consola muy sencillo pero muy completo a la vez. La razón es que su configuración es sencilla para los propósitos de este tutorial. Además, su sencillez permite entender un poco más cómo funciona el correo electrónico, que es de lo que se trata aquí.

Si lo que se pretende es utilizar algún otro software como cliente de email, habrá que hacer un poco de investigación para, por ejemplo, acceder al buzón desde Thunderbird, Evolution, Outlook, etc. Sin embargo, el proceso no debe de ser complicado.

En algún tutorial posterior, hablaremos de los protocolos POP e IMAP, que permitirán ver el correo de nuestro servidor personal desde cualquier cliente conectado a internet, desde clientes web (como Squirrelmail) hasta el uso de cualquier cliente que soporte estos protocolos (como en un dispositivo móvil), pasando también, claro, por los clientes convencionales ya mencionados, pero conectándose vía internet al servidor.

Instalación
mutt se instala en Debian con el paquete mutt. También puede descargarse desde su sitio oficial.

Configuración
Lo primero es establecer una variable de entorno para que mutt sepa en donde buscar el email a leer:

$ export MAIL='~/Mail'

obviamente, el nombre del subdirectorio cambia de acuerdo a lo configurado en Postfix. Esta línea no basta con ejecutarla y ya, debería de colocarse en algún script, como ~/.bashrc para que se ejecute cada vez que se inicia una nueva sesión de consola, de lo contrario sólo durará mientras dure la sesión actual.

Otra manera de configurarlo es através de un archivo de configuración por usuario: ~/.muttrc
que debería de incluir esta línea:

set folder = /home/jstitch/Mail

Si somos usuarios adictos a la consola, seguramente tendremos un editor de preferencia... En mi caso uso Emacs. El editor de preferencia se configura con la siguiente línea:

set editor=emacs

Esto es importante: como todos los buenos programas que siguen la filosofía Unix, mutt se especializa en una sola cosa: es un MUA, un cliente de correo. ¡Ni siquiera cuenta con su propio editor de texto! De esta forma delega la responsabilidad de redactar un correo al editor que se defina, o al que esté definido por defecto en el sistema. Con esto además, el usuario será libre de elegir su propio editor, para que se sienta más a gusto. En un cliente de correo convencional por lo general se cuenta con el editor que proporcione el cliente, ¡que poca libertad de elección!

Otras configuraciones interesantes para mutt (¡y hay muchas más! basta ver la documentación en el sitio oficial...)

set signature="~/.signature"

establece el archivo que contiene la firma predefinida para los correos enviados. Habrá que crear dicho archivo y ponerle algún contenido. Como todos los verdaderos buenos clientes de correo, mutt agrega un par de guiones '--' antes de la firma para que quien lea los correos sepa que se trata de la firma, y no más del cuerpo del correo.

my_hdr From: Javier Novoa C.

establece el header From que llevarán los correos a enviar con mutt

Además, mutt puede utilizar con el archivo ~/.muttprintrc que permite definir instrucciones para imprimir los correos.

Uso
mutt se ejecuta en consola. Para lanzarlo hay que teclear

mutt

aparecerá una pantalla ocupando toda la consola, pues mutt utiliza ncurses.

Los comandos que acepta mutt son básicamente letras para realizar acciones.

m permite enviar un mail, solicitará el destino, el asunto y luego abrirá el editor para redactar el mensaje. Basta guardarlo en donde lo haya solicitado mutt y salir para que se tenga el email redactado. Luego con Y se enviará el correo.

La pantalla está casi totalmente ocupada por la bandeja de entrada en ~/Mail (o donde sea que se haya configurado). Si hay correos, estos aparecerán aquí. Con las flechas se puede navegar para seleccionar un mensaje, y con INTRO para verlo.

D permite borrar el mensaje seleccionado

q permite salir

? proporciona la ayuda, más completa que esta, del programa.

Notas finales
Y ahora es tiempo de terminar de configurar el MTA, como se había dicho en el post correspondiente. Aún faltaba el detalle de permitir que Gmail enviara correos a nombre del servidor, sin usar el remitente con la dirección de Gmail.

Ya se explicó cómo configurar Gmail para esto, pero faltaba validar el proceso.
Si todo se realizó correctamente, tuvo que haber llegado a la bandeja de entrada un correo de parte de Gmail para validar. Habrá que acceder a una URL para terminar la validación, o copiar un código de verificación y usarlo en la misma configuración de Gmail para terminar.

Hecho esto, la dirección de correo especificada, usuario@dominio, deberá de aparecer en la lista de orígenes válidos de Gmail, y en adelante los correos enviados desde el servidor deberían de llegar a sus destinos como proviniendo del servidor, no de Gmail (aún cuando Gmail se siga usando como relay para poder enviar dichos correos).

Y listo, con esto ya se tiene un sistema de correo funcional para enviar y recibir correos. Aún vamos a configurar un par de programas que resultarán muy útiles para terminar este tutorial.

Empecemos con Fetchmail...

Servidor de correo personal con postfix - MDA

2010-08-24T11:37:00.001-07:00

Continuamos con los posts dedicados a configurar un 'Servidor de correo personal con postfix'.

Previamente ya configuramos el MTA, Mail Transfer Agent.

Toca el turno del MDA, Mail Delivery Agent, el cual cumple las funciones de un 'cartero' al que la central de correos (el MTA) le entrega el correo a ser entregado en los buzones correctos.

En la configuración del MTA se especificó que se usaría el programa Procmail para realizar las labores de entrega, y es el software que vamos a instalar y configurar a continuación.

Procmail puede descargarse desde su sitio oficial, o instalarse con las utilidades de la distribución de GNU/Linux en uso. Para Debian, el paquete se llama procmail.

La configuración no se lleva mucho. En realidad implica crear unos subdirectorios, un archivo de configuración y el de logging. Y además, mucha de esta configuración es en parte un preparar terreno para los siguientes programas que vamos a configurar.

Subdirectorios para recibir el correo

En primer lugar, nos aseguramos de que exista el subdirectorio $HOME/Mail (o como le hayamos puesto en la configuración de Postfix).

Posteriormente, hay que crear unos subdirectorios aquí, para que el cliente de correo (mutt) sepa si el correo es nuevo, o si ya fue leído, y para tener un directorio de trabajo temporal:

$ mkdir -p ~/Mail/{new, cur, tmp}

Hecho eso, vamos a preparar el terreno para Spambayes, que utilizará algunos subdirectorios para almacenar el correo dependiendo el tipo de correo que llegue (seguro, spam o inseguro):

$ mkdir -p ~/Mail/{.MissedSpam, .MissedHam, .CaughtSpam, .Unsure}
$ mkdir -p ~/Mail/.MissedSpam/{new, cur, tmp}
$ mkdir -p ~/Mail/.MissedHam/{new, cur, tmp}
$ mkdir -p ~/Mail/.CaughtSpam/{new, cur, tmp}
$ mkdir -p ~/Mail/.Unsure/{new, cur, tmp}

Archivo de configuración

Lo siguiente es crear el archivo ~/.procmailrc para configurar Procmail. Nótese que este archivo es personal, por cuenta de correo, pues cada uno tiene una cuenta de correo personal. Sin embargo, debe de ser posible definir alguna configuración global, siempre cuidando que se apunte a los directorios apropiados para cada usuario y su cuenta de correo, evitando problemas de privacidad.

SHELL=/bin/sh
MAILDIR=$HOME/Mail/
DEFAULT=$HOME/Mail/
VERBOSE=on
LOGFILE=/var/log/procmail

:0:
${DEFAULT}

Lo que estamos diciendo es, simplemente, definir el directorio en el que reside el correo para el usuario. Nótese que para MAILDIR y DEFAULT el nombre del subdirectorio termina con / . Si no terminara así, Procmail asume que se trata de un archivo, y entonces busca colocar los correos todos dentro de un mismo archivo (al estilo del viejo comando mail). Sin embargo, con la notación de la / al final, se logra que Procmail deposite los correos en el subdirectorio indicado, con los subdirectorios cur, new y tmp previamente creados.

El último par de líneas le indican a Procmail que deposite todos los correos que lleguen en el subdirectorio marcado como DEFAULT. Posteriormente cuando configuremos Spambayes haremos una modificación aquí, para que Procmail sepa diferenciar entre spam y correo seguro (utilizando los subdirectorios que ya creamos aquí mismo).

Archivo de registro (logging)

La línea LOGFILE del archivo .procmailrc define el archivo de logging. Hay que crear previamente este archivo, y en caso de ser un archivo de sistema, cuidar que los permisos sean los adecuados para que el proceso de Procmail escriba en ellos, de lo contrario el log de Postfix indicará un error de que Procmail no pudo escribir sobre el archivo de log, situación que debe corregirse.

Prueba
Hecho esto ya podríamos probar la recepción de correos, aunque sin MUA todavía, sería difícil y complicado revisar el correo de esta manera:

Desde alguna dirección de prueba, enviarnos un correo a nuestra dirección de correo del servidor, nombreusuario@dominio .

Si todo quedó bien configurado, Postfix debería de recibir el correo, entregárselo a Procmail y este depositarlo en el directorio ~/Mail/new

Breve nota cultural
Todo el correo electrónico y los protocolos para el mismo se basan en archivos de texto plano, por lo que aunque el correo incluyera attachments o código HTML, podría abrirse en cualquier editor de texto.

¿Cómo le hacen los clientes para desplegar el correo cuando existen archivos adjuntos o código HTML?

Todo esto tiene que ver con los protocolos definidos por la IETF (Internet Engineering Task Force) para el correo electrónico, en algunos documentos RFC. Desde mi punto de vista son muy interesantes y accesibles (aunque en inglés):

Por ejemplo, el correo electrónico per se original se define en el RFC 2822
El uso de archivos adjuntos en realidad se logra gracias al uso de MIME: RFCs 2045 a 2049
El uso de código HTML es parte de la definición del correo electrónico: RFC2822
Otros RFC de interés:
Protocolo SMTP: RFC 2821
Protocolo original de email, que duró casi 20 años: RFC 822

Dicho esto, continuemos con el cliente de correo, el MUA.

Servidor de correo personal con postfix - MTA

2010-08-24T11:37:00.000-07:00

Esta es la parte 1 de una serie de posts que vienen de 'Servidor de correo personal con postfix'.

Para configurar el servidor, vamos a asumir que, teniendo una dirección IP dinámica, se cuenta con un nombre de dominio dinámico, por ejemplo como el que ofrece DynDNS.

Recordar que el MTA, Mail Transfer Agent es el encargado de mandar los mensajes de correo que salgan del servidor, así como de recibir en primer instancia los mismos para entregárselos al MDA que los debe dejar en los buzones correctos.

Como MTA utilizaremos Postfix, un MTA bastante popular hoy en día en servidores GNU/Linux.
Cabe decir que si no se tiene MTA, el comando mail nativo de GNU/Linux permite enviar emails únicamente a los usuarios de la misma máquina que funge como servidor. Fuera de eso no se puede enviar ningún tipo de correo (ni en la misma LAN ni por internet a otros dominios de correo): se necesita configurar el MTA (además de que para usar solamente mail este tutorial pierde todo su sentido...)

Instalación
El primer paso será instalar Postfix.
Se puede descargar el código fuente del sitio oficial, o se puede instalar la versión que venga en la distribución GNU/Linux que se esté utilizando.

En el caso de Debian Lenny, se debe instalar el paquete llamado postfix

En esta distribución, esto instala por default también libsasl2-2, paquete necesario para la autenticación con gmail que se pretende instalar.

En otras palabras, la instalación requiere de instalar Postfix con soporte para SASL.

Además, para los certificados públicos de autenticación, se requerirá instalar OpenSSL (paquete openssl), que incluya los certificados Thawte y Equifax. Estos se encuentran en el paquete ca-certificates.

Configuración
El siguiente paso es configurar el software.

Postfix se configura en los archivos del directorio /etc/postfix (o al menos ahí es por default en Debian)

main.cf

Este archivo contiene las configuraciones principales de Postfix.
Las configuraciones principales son:

#poner aqui el nombre de tu dominio
myorigin = nombredominio.homelinux.net

#autenticación para Gmail
smtp_use_tls=yes
smtp_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

#mas abajo explicamos como generar el archivo cacert.pem
smtp_tls_CAfile = /etc/postfix/cacert.pem

#SASL para autenticación con Gmail
smtp_sasl_auth_enable = yes

#mas abajo explicamos sobre el archivo passwd
smtp_sasl_password_maps = hash:/etc/postfix/sasl/passwd

smtp_sasl_security_options = noanonymous

#nombre del dominio, con que coincida con myorigin basta
mydomain = $myorigin

#el nombre del host seria el nombre de la maquina servidor
#que tenga tu servidor cuando instalaste GNU/Linux y el
#nombre de tu dominio
myhostname = nombremaquinaservidor.$mydomain

#con que nombres se identifica tu destino de correo local
mydestination = $mydomain, $myhostname, localhost.$mydomain, localhost

#quienes pueden enviar correos usando este servidor. es
#MUY importante ajustar esta opcion a lo que se quiera. Yo
#lo tengo asi (valor 'host') para solo enviar desde mi
#maquina servidor. El valor 'subnet' (default) permite que
#maquinas en la misma subred del servidor envien correos
#desde el server. El valor 'class' permite que el server
#envie correos desde cualquier máquina en la misma clase
#de red (A,B,C) en que se esté - con una máquina con IP
#dinámica proporcionada por un ISP provocaría que todas
#las máquinas de la subred del ISP envíen correos desde el
#servidor, MUCHO CUIDADO CON ESTO!

mynetworks_style = host

#si se quiere que otras maquinas puedan enviar correos
#desde este servidor, tambien se puede establecer la
#opcion mynetworks a un rango de IPs (en notación CIDR).
#MUCHO CUIDADO con esto, no dejarlo abierto a todo el
#internet, o los spammers abusarán de tu servidor para
#enviar correos desde aquí. Esto además seguro que
#provocará la cancelación de tu servicio con tu ISP...

#este es importante: con el se le dice a postfix que se
#conecte al relay de gmail para enviar correos
relayhost = [smtp.gmail.com]:587

#que tipo de mensajes loggeara postfix. Yo lo deje asi por
#hacer pruebas, pero no tiene que ser tan detallado
notify_classes = 2bounce, delay, policy, protocol, resource, software

#desde que interfaces de red de tu maquina se puede enviar
#correos...
inet_interfaces = all

#en donde estaran los alias para usar en las direcciones
#de correo usuario@dominio (se explica mas adelante)
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases

#postfix debe saber como acceder al MDA. En este caso
#usamos procmail...
mailbox_command = procmail -a "$EXTENSION"

#otras opciones...
mailbox_size_limit = 0
recipient_delimiter = +
html_directory = /usr/share/doc/postfix/html

#con esta opcion le decimos a Postfix que queremos que los
#mails se reciban en un directorio Mail dentro del
#directorio $HOME del usuario... podriamos especificar un
#archivo estilo /var/mail (sin / al final) para que
#coloque todos los emails en un solo archivo. Pero para
#configurar correcta y facilmente procmail y sobre todo
#spambayes, y para tener mejor control, va a ir todo en un
#directorio especificado aqui...
home_mailbox = Mail/

sasl/passwd

En este archivo se colocará la autenticación al relay (Gmail) que usará nuestro servidor:

[smtp.gmail.com]:587    unacuenta@gmail.com:unacontraseña

Es importante proteger este archivo correctamente, cambiando sus permisos:

$ chmod 600 /etc/postfix/sasl/passwd

Por último, hay que convertir el archivo a un formato adecuado para Postfix, para lo cual existe la utilidad postmap:

$ postmap /etc/postfix/sasl/passwd

cacert.pem

Para autenticarse correctamente con Gmail, además del usuario y password, es importante utilizar un certificado público de seguridad válido. Según la fuente en que me basé, son necesarios los certificados de Thawte y/o Equifax, que se colocan en este archivo de la siguiente manera:

$ cat /etc/ssl/certs/Thawte_Premium_Server_CA.pem >> /etc/postfix/cacert.pem

$ cat /etc/ssl/certs/Equifax_Secure_CA.pem >> /etc/postfix/cacert.pem

Obviamente, es importante localizar los archivos origen *.pem en la instalación que se tenga.

/etc/aliases

Este archivo contiene los alias que Postfix reconocerá para sus usuarios especiales, de forma que sepa a qué buzón real redireccionar los mensajes que vayan a estos usuarios... En este archivo colocar entonces:

root: nombreusuario
spam: nombreusuario
ham:  nombreusuario

El primer alias es para los correos que se dirijan a la cuenta root del sistema. Los otros dos se usarán para spambayes. Podría haber otros alias también, como postmaster, entre otros. Lo mejor por ahora es no moverlos y dejarlos tal como estén.

Por último hay que dejar el archivo de alias en un formato que Postfix pueda usar:

$ postalias aliases

firewall

Y para terminar, no hay que olvidar abrir los puertos pertinentes para que Postfix se pueda comunicar con otros servidores de correo. En particular, el puerto a abrir es el TCP 25, el puerto por default del protocolo SMTP.

Aquí cabe hacer una aclaración. Mi ISP es Prodigy Infinitum, y luego de unos quebraderos de cabeza, me di cuenta utilizando nmap que el puerto 25 lo podía tener abierto en mi servidor, pero visto desde afuera parecía como si estuviera cerrado (con lo que podría tener un servidor de correo para mi LAN, pero no más). Investigando supe que Telmex, la compañía que lleva el servicio de Prodigy Infinitum en México, cierra por defecto a sus usuarios de domicilio particular el puerto 25, para evitar abusos y spam y demás. Lo que tuve que hacer (quien sabe si tu lo tengas que hacer también, dependerá de tus condiciones) fue interactuar con ellos, así que tuve que salirme de mi segura consola dentro de mi servidor, llamar por teléfono a Telmex y pedir que me abrieran el puerto 25. Según lo que estipula la medida es posible hacer esto para que se abra el puerto 25. Aclaré que sería para propósitos de 'mi trabajo' y de uso particular exclusivamente. Prometiendo no solamente no mandar spam ni abusar del servicio, sino también configurar correctamente mi máquina (jamás dije que era un servidor, no fueran a sospechar equivocadamente que haría otra cosa) para que nadie abusara del servicio (recuerda la configuración my_networks_style y my_networks en main.cf). Y está claro que no abuso del servicio... el sistema de correo electrónico es muy quisquilloso (y con razón), y es capaz de detectar la fuente de spam fácilmente, etiquetar a los servidores que son fuente del mismo, y si se reporta esto a Telmex, bien podría cerrarme el puerto, o cancelarme el servicio! incluso si no soy yo la fuente del spam, bastará que lo configure mal para provocar esto...

Gmail

Como parte de la configuración del servidor, puesto que se va a usar Gmail como el relay para enviar correos, es necesario configurar este servicio para poder obtener un servidor completo. A lo que me refiero con esto es que, ya configurado Postfix, el servidor, en teoría, ya puede enviar correos (cosa que se probará un poco más adelante), pero aún así los correos irían con el remitente de la cuenta de Gmail usada como relay. Lo ideal sería que aparecieran los correos como si vinieran del servidor (con el nombre de usuario y dominio del mismo), no de Gmail.

Para ello, se tiene que acceder a la cuenta de Gmail, acceder a Configuración y ahí a la pestaña de Cuentas e Importación. Agregar la cuenta del servidor y realizar el proceso de verificación, que consiste en introducir un código de verificación que debe llegar al correo indicado... ups, aún falta configurar el correo entrante para hacer esto. Volveremos a ello hasta el final, pero más valía anotarlo aquí para saber que aún es parte de la configuración del MTA y que queda pendiente a que podamos recibir correos...

Uso del MTA

Postfix ya puede usarse, y de hecho vamos a probarlo en breve.

Por ahora resumiremos los comandos de Postfix más importantes.

En primera instancia, una vez configurado todo, debe reiniciarse el servicio de Postfix, lo cual puede hacerse con

$ /etc/init.d/postfix restart

(o donde quiera que residan los scripts que dan inicio a los servicios del sistema). Pero en vez de ello, Postfix también cuenta con una opción que permite reinciar y cargar las configuraciones de nueva cuenta, sin necesidad de reiniciar el servicio del sistema:

$ postfix reload

Si existen correos en cola de espera para ser enviados, puede pedírsele a Postfix que los envíe, vaciando la cola, con:

$ postfix flush

Para ver la mencionada cola de salida de correos se utiliza el comando

$ mailq

Así mismo, es importante saber en donde se almacenan los logs del sistema. Postfix genera por default tres archivos de históricos en /var/log:

mail.error : con los errores que hubiera encontrado
mail.warn : con las advertencias que hubieran surgido
mail.info : con el resto de información de logging que se hubiera presentado

Prueba del MTA
Para probar Postfix, podemos hacer uso, por ahora, del comando mail de GNU/Linux.

Previamente debemos crear el subdirectorio $HOME/Mail (o donde quiera que lo hayamos configurado en el archivo main.cf de Postfix).

Hecho eso usamos:

$ mail direcciondestino@dominio.com

Con direcciondestino alguna cuenta de correo de prueba fuera del servidor.

Luego ponemos el subject, INTRO, y escribimos el correo. Al terminar tecleamos ^D (Ctrl + D) y nada en el campo Cc: y el correo debería de llegar a la dirección especificada.

Hay que monitorear los logs para checar y corregir cualquier problema que pudiera surgir.

Claro está, si no se ha configurado Gmail, el correo parecerá venir de parte de la cuenta de Gmail.

Otra forma de probar el servidor es mediante una sesión en Telnet, sabiendo previamente como funciona el protocolo SMTP...

Y obviamente, aún queda configurar la recepción de correos, para poder recibir respuesta...

Continuamos entonces con el MDA...

Servidor de correo personal con postfix

2010-08-24T11:36:00.000-07:00

En mi opinión un sistema de correo electrónico es de los que pueden llegar a tornarse más complicados de configurar. Al contrario de otros tipos de servidores que sólo requieren configurar un programa, y los puertos apropiados en el firewall, un sistema de correo requiere configurar varias cosas en diversos lugares.

Ésto último es debido a que un sistema de correo está en realidad compuesto no por uno sino por varios programas o sistemas que interactúan entre sí, completando y complementando sus funciones para dar lugar al sistema de correo electrónico como lo conocemos hoy: eficiente, robusto, sencillo si se sabe comprender...

Esta división de un sistema en pequeños subsistemas que cumplen funciones específicas es en realidad producto de la filosofía en sistemas como Unix de hacer las cosas bien y una sola vez. Así, por ejemplo el sistema que entrega el correo electrónico se dedica única y exclusivamente a eso, especializándose en ello y con eso no embotando su propio código fuente con funcionalidades para las que existen otros programas especializados, como el sistema que se encarga de obtener el correo a leer, o el que lo envía...

Un sistema de correo puede, en términos generales, dividirse en 3 partes principales, a saber, de afuera hacia adentro:

El MUA, Mail User Agent. Es el que se encarga de mostrar el correo en su bandeja al usuario. En otras palabras, el programa utilizado para leer el correo electrónico. Por ejemplo mutt, Mozilla Thunderbird, Evolution, MS Outlook, etc. También puede ser un cliente web, por ejemplo Squirrelmail. El análogo con el correo postal es que el MUA es la persona que recibe y lee sus cartas.

El MDA, Mail Delivery Agent. Es el que se encarga de repartir el correo a las distintas bandejas o cuentas que existan. Normalmente ya no se 've' este programa, pero está ahí ejecutando su labor conforme se lo solicita el último componente. Un ejemplo de este tipo de programas es Procmail. Un análogo con la realidad del correo postal, sería que el MDA desempeña la labor del cartero que toma las cartas de la oficina de correos y las lleva a los buzones de los usuarios correctos.

El MTA, Mail Transfer Agent. Es el núcleo de un sistema de correo electrónico. Se encarga de, por un lado, tomar los mensajes de las bandejas de salida de los usuarios y enviarlos a los destinatarios, utilizando por ejemplo el protocolo SMTP. Por otro lado, se encarga de recibir los correos entrantes del exterior (o los que vengan del propio sistema) y decidir qué hacer con ellos, en particular entregarlos al MDA para que los deposite en las bandejas adecuadas. Ejemplos de este tipo de programas son Sendmail y Postfix. El análogo con el sistema de correo postal es que el MTA es como la oficina de correos local, que recibe las cartas a ser enviadas por parte de los usuarios y que se comunica con otras oficinas para enviar los correos a los destinos adecuados.

Existen además otros componentes que se relacionan en algún punto del sistema. Por ejemplo, hay programas dedicados a leer constantemente las entradas de correo de servidores externos para así solicitar su llegada. Por ejemplo, Fetchmail. Otro ejemplo son los detectores de spam, tan importantes para evitar saturar las bandejas de entrada de los usuarios con correo basura o incluso peligroso. Por ejemplo, Spamassasin o Spambayes.

También existen otros protocolos que se relacionan con el correo, como POP e IMAP que permiten obtener el correo electrónico desde un servidor para leerlo en otros lugares (algo como lo que se logra configurando gmail para ser leido en Thunderbird o en un dispositivo móvil, y de hecho es en lo que se basa Fetchmail). Para levantar un servidor usando estos protocolos existen otros programas también. Por ejemplo Courier.

El siguiente diagrama muestra de manera muy general como se conformaría un sistema de correo personal como el que vamos a armar en este tutorial:

Para el presente tutorial, vamos a configurar entonces el sistema de correo con el siguiente software:

sobre GNU/Linux, distribución Debian Lenny (en realidad con un poco de investigación se puede instalar en cualquier otra distribución)
MTA: Postfix, conectado via una cuenta de gmail para poder conectarnos desde una IP dinámica
MDA: Procmail
MUA: mutt (cliente de correo en consola, modo texto, sencillo pero útil para este ejemplo, ¡y para leer rápidamente correo común también!)
Fetchmail para leer constantemente una cuenta de gmail y obtener así los correos entrantes
Spambayes para detección de spam
por ahora no vamos a configurar Courier para utilizar los protocolos POP e IMAP, lo dejamos para otro tutorial

Con esto lograremos un servidor de correo en nuestra máquina con IP dinámica, para poder enviar y recibir correos, con una dirección de correo personal (con todo y dominio personal si contamos con un servicio como el que da DynDNS). Los correos enviados desde el sistema parecerán venir de parte de la cuenta de Gmail, requisito necesario ya que los ISPs que dan IPs dinámicas no permite enviar correos así nada más, justamente para evitar abusos. Así mismo, será posible recibir correos en nuestra dirección con domino personal (de nuevo, siempre y cuando contemos con un servicio como el que da DynDNS).

Cabe la pregunta de por qué usar una cuenta de Gmail para el envío real de los correos. La razón es que la mayoría de los servidores de correo actuales están configurados para evitar la recepción de correos que vengan de dominios que mapeen con direcciones IPs definidas como dinámicas. Por ello, se necesita hacer relay con un servidor 'válido' para dichos servidores para evitar que los correos sean rechazados. Si contáramos con una dirección IP estática, es probable que no necesitemos usar Gmail como relay, pero como este tutorial está basado en esa supocisión, lo dejaremos como parte del diseño del sistema...

Para fines prácticos, puesto que este sería un post muy largo si lo dejamos todo en una sola entrada, vamos a subdividirlo en partes...

MTA
MDA
MUA
Fetchmail
Spambayes y algunas notas finales

Como referencia, el presente tutorial lo base en: http://www.hypexr.org/linux_mail_server.php
y en http://albertomolina.wordpress.com/2009/01/04/configurar-postfix-a-traves-de-un-relay-host-autenticado-gmail/

Comencemos con el MTA...

Compilando FFmpeg para convertir formatos de archivos de medios

2010-04-27T10:54:00.000-07:00

FFmpeg es una suite de programas para manipulación de medios. Su sitio oficial es http://ffmpeg.org/

La mayoria de las distribuciones Linux ya incluyen los paquetes para poder utilizar FFmpeg, sin embargo a veces es necesario recompilar el programa para que soporte algunos codecs que no vienen por default en el programa que incluye la distribucion.

El codigo fuente de FFmpeg se baja del sitio oficial. Se puede bajar la ultima version estable o sincronizar con el repositorio SVN o GIT para tener la version de desarrollo mas reciente.

Una vez con el codigo fuente, se aplica la clásica serie de pasos:

configure

make

make install

(este último al menos, requiere de permisos de superusuario)

Ahora bien, para que FFmpeg soporte otros formatos, se deben habilitar en el configure.
Por ejemplo:

--enable-libopencore-amrnb   permite soporte para videos 3GP
--enable-libvorbis   permite soporte para Vorbis
--enable-libmp3lame   permite soporte para audio MP3
--enable-libxvid   permite soporte para AVI
--enable-libfaac   permite soporte para audio AAC

Una vez compilado e instalado, ffmpeg se utiliza para convertir formatos.
Por ejemplo,

de FLV a 3GP:

ffmpeg -i origen.flv -s qcif -vcodec h263 -acodec aac -ac 1 -ar 8000 -r 25 -ab 32k -y destino.3gp

de MOV a FLV

ffmpeg -i origen.mov -ar 22050 -ab 128k -b 400k -s 320x240 -aspect 4:3 -f flv destino.flv

Notese que los parametros que definen las caracteristicas del video (bitrate, etc.) deberian cambiar segun el video origen y el resultado deseado en el destino.

¿Eres un arquitecto de software?

2010-02-27T00:07:00.000-08:00

Tomado del original (en inglés) en infoq.com.

La linea que divide el desarrollo de software y su arquitectura es engañosa. Algunos dirán que esta no existe y que la arquitectura es simplemente una extensión del proceso de diseño hecho por los desarrolladores. Otros harán de esto un enorme abismo que solo puede ser crusado por desarrolladores avanzados que creen que debes resumir los componentes fundamentales en lugar de detenerte en esos detalles molestos de implementación. Como siempre, hay un balance pragmático en algún lado a mitad del camino, lo cual hace surgir una pregunta interesante sobre como moverte de un lado a otro.

Algunos de los factores clave que a menudo se utilizan para diferenciar la arquitectura del software de su diseño y su desarrollo incluyen un aumento de la escala, un aumento en el nivel de abstracción y un aumento en la importancia de la toma de decisones correctas en el diseño.
La arquitectura del software es acerca de tener visiones holísticas y teniendo una vista general para entender como el sistema trabaja como un todo. Mientras esto puede ayudar a difrenciar el desarrollo de la arquitectura de software, no necesariamente permite entender como alguien cambia de actividades de desarrollo a las de arquitectura. Tampoco ayuda a identificar quién hará un buen trabajo de arquitectura, ¿como harás para contratar a la gente correcta o sabrás si tu eres un arquitecto de software?

La experiencia es una buena referencia pero necesitas profundizar más

Llegar a ser un arquitecto de software no es algo que simplemente pase de la noche a la mañana o con un ascenso. Es una función, no un rango. Es un proceso evolutivo donde gradualmente ganarás la experiencia y confianza que necesitas para ejecutar tu función.

Hay un número de cualidades que puedes buscar en un arquitecto de software y su experiencia pasada es a menudo un buen puntaje para calificar su habilidad en el desempeño de su papel. Aunque la función de un arquitecto de software es muy variado, se necesita profundizar para entender el nivel de participación, la influencia, el liderazgo y la responsabilidad que ha sido demostrada a través de un número de ámbitos diferentes. Hablando ampliamente, la arquitectura de software en la mayoría de los proyectos puede ser dividida en dos fases; la arquitectura es definida y luego es liberada.

Definición de la arquitectura del software

El proceso de definición de la arquitectura parece bastante simple. Todo lo que tienes que hacer es identificar cuáles son los requerimientos y diseñar un sistema que los satisfaga. Pero en realidad no es tan simple y el papel de arquitectura de software puede varia ampliamente dependiendo de que tan comprometido estas y que tan seriamente visualizas tu papel. Como el siguiente diagrama muestra, la parte de la definición de la arquitectura puede ser dividida en un número de elementos diferentes.

1. Manejo de requerimientos no-funcionales: Los proyectos de software a menudo quedan atrapados con los usuarios que preguntan sobre las características que desean, pero rara vez se les pregunta que requerimientos no-funcionales (o cualidades del sistema) necesitan. Algunas veces los actores dirán que "el sistema debe ser rápido", pero eso es muy subjetivo. Los requerimientos no-funcionales necesitan ser específicos, medibles, alcanzables y capaces de ser probados si vamos a cumplirlos. La mayoría de los requerimientos no-funcionales son técnicos por naturaleza y a menudo tienen una alta influencia sobre la arquitectura del sofware. Entender los requerimientos no-funcionales es una parte crucial, pero hay una diferencia entre asumir cuáles son los requerimeintos y llevarlos a cabo. Después de todo, ¿Cuántos sistemas has visto que genuinamente necesiten ser operacionales 24x7?

2. Definición de la arquitectura: Con los requerimientos no-funcionales capturados, el siguiente paso es empezar a pensar sobre como vas a solucionar los problemas indicados por los actores y definir la arquitectura. Se puede decir que cada sistema tiene una arquitectura, pero no que cada sistema tiene una arquitectura definida. Y ese realmente es el punto aquí. El proceso de la definición de la arquitectura te permite pensar sobre como vas a tomar los requerimientos junto con las restricciones impuestas y resolver el problema. La definición de la arquitectura es sobre introducir estructura, directrices, principios y ligerazgo a los aspectos técnicos del proyecto de sofware. Definir la arquitectura es tu trabajo como arquitecto pero hay una gran diferencia entre diseñar un sistema desde cero y extender uno ya existente.

3. Selección de la tecnología: La selección de la tecnología es típicamente un ejercicio divertido pero tiene su lista justa de retos cuando te fijas en el costo, licenciamiento, relación con proveedores, estrategia de tecnología, compatibilidad, interoperabilidad, soporte, desarrollo, politicas de actualización, entornos de usuario final y aún mas. La suma de estos factores puede a menudo hacer una tarea simple y convertirla en una completa pesadilla. Y ahí está la pregunta de si las tecnologías en realidad funcionan. La seleccion de tecnologías es todo sobre manejar riesgos; reducir riesgos donde existe alta complejidad o incertidumbre e introducir riesgos donde hay beneficios que obtener. Las decisiones de tecnología se necesitan hacer tomando en cuenta todos los factores, y todas las decisiones deben ser revisadas y vueltas a evaluar. Esto incluye los principales bloques de construcción para un proyecto de software hasta las librerias y frameworks que están siendo introducidos durante el desarrollo. Si estás definiendo una arquitectura, también necesitas estar seguro que las elecciones que estan siendo tomadas son las correctas. Otra vez hay una gran diferencia entre evaluar una tecnología para un nuevo sistema y agregar una tecnología a un sistema que ya existe.

4. Evaluación de la arquitectura: Si estas diseñando software, necesitas preguntarte a tí mismo si tu arquitectura funcionará. Para mí, una arquitectura funciona si esta satisface los requerimientos no funcionales, provee los fundamentos necesarios para el resto del codigo y provee una plataforma suficiente para resolver los problemas de negocio subyacentes. Uno de los más grandes problemas con el software es que es complejo y abstracto, lo cual hace difícil visualizar las características en tiempo de ejecución desde diagramas UML o el código mismo. Tenemos un número diferente de pruebas de todo el ciclo de vida de desarrollo del software que nos da la confianza de que el sistema que estamos liberando funcionará cuando sea mostrado. Entonces ¿por qué no hacemos lo mismo para nuestras arquitecturas? si puedes probar tu arquitectura, entonces puedes probar que esta funciona. Y si puedes hacer eso tan pronto como sea posible, puedes reducir el total de riesgos de que el proyecto falle mas que simplemente esperar por lo mejor.

5. Colaboración de la arquitectua: Es inusual para un sistema que viva aislado y existe un par de personas que necesitan entender esto. Esto va desde el equipo de desarrollo inmediato que necesitan entender la arquitectura hasta los actores que tienen un interes como seguridad, base de datos, operaciones, mantenimineto, soporte y más puntos de vista. Para que un proyecto de sofware sea exitoso, necesitan colaborar muy de cerca con los encargados de sistemas para asegurar que la arquitectura se integrara satisfactoriamente con su entorno. Desafortunadamente, la colaboracion en la arquitectura en el equipo de desarrollo rara vez ocurre, por no hablar de los actores externos.

Liberación de la arquitectura del software

También es la misma historia con la entrega de la arquitectura, donde el papel de la arquitectura del software puede variar dependiendo del nivel de compromiso a través de los elementos que contribuyen a un proyecto exitoso.

1. Apropiarse del panorama completo: Con el fin de llevar la arquitectura hacia una conclusión exitosa, es importante que alguien tenga el panorama completo y que venda la visión a lo largo del ciclo de vida del desarrollo de software, que evolucione a lo largo del proyecto si es necesario y que tome la responsabilidad de asegurarse que será entregado correctamente. Si has definido una arquitectura, hace sentido permanecer continuamente comprometido y evolucionarla más que solamente dejarla en manos de un "equipo de implementación".

2. Liderazgo: Apropiarse del panorama completo es un especto técnico del liderazgo, pero hay otras cosas que necesitamos que esten hechas durante la fase de liberación de un proyecto. Estas incluyen tomar responsabilidades, proveer orientación técnica, tomar decisiones técnicas y tener la autoridad para tomarl dichas decisiones. Como el arquitecto, necesitas tener el liderazgo técnico para asegurar que todo esté caminando perfecto y que el equipo esté siendo dirigido en la dirección correcta y continuamente. La posición del arquitecto es inherentemente sobre liderazgo y aunque esto suene obvio, muchos equipos que realizan proyectos no tienen el liderazgo técnico que necesitan, con arquitectos asumiendo que una liberación exitosa no es necesariamente su problema.

3. Entrenar y guiar: El entrenamiento y la guianza es una actividad que se suele pasar por alto en la mayoría de proyectos de desarrollo, con muchos miembros en el equipo sin el soporte que requieren. Mientras el líder técnico intenta dirigir el proyecto como un todo, hay ocasiones en que ciertas personas necesitan asistencia. Además de esto, entrenar y guiar provee una forma de mejorar las habilidades de la gente y ayudarlas a mejorar sus propias carreras profesionales. Esto es algo que recae directamente como un mandato para el arquitecto, pero claramente hay una gran diferencia entre entrenar a tu equipo en arquitectura/diseño y ayudarlos con sus problemas de codificación.

4. Asegurar la calidad: Incluso con la mejor arquitectura y liderazgo en el mundo, una liberación pobre puede causar que un proyecto de la vuelta del éxito al fracaso. Asegurar la calidad es una parte amplia de la función de un arquitecto, pero esto es mas que solo hacer revisiones de código. Por ejemplo, necesitas una linea de referencia como defensa para asegurarte, y esto significa la introducción de estándares y prácticas de trabajo. Desde una persepectiva de desarrollo de software, estas pudieran incluir estándares de codificación, principios de diseño y herramientas de análisis de código fuente a través de una contínua integración, pruebas unitarias automatizadas y herramientas de cobertura de código. Se puede decir que la mayoría de los proyectos no aseguran la calidad lo suficiente, por tanto necesitan imaginarse que es lo importante y garantizarlo suficientemente. Para mí, las partes importantes de un proyecto son todas aquellas significativas arquitectónicamente, con lógica de negocios crítica, complejas y altamente visibles. Solo necesitas ser pragmático y darte cuenta que no puedes necesariamente asegurar todo, de hacer algo más que no hacer nada.

5. Diseño, desarrollo y pruebas: La última cosa que recae sobre la función de un arquitecto es el diseño, el desarrollo y las pruebas. Ser un arquitecto práctico no significa necesariamente que te tienes que involucrar en el día a día con las tareas de codificar, pero si implica que estes contínuamente involucrado en el proyecto, ayudando activamente a darle forma y a liberarlo. Dicho esto, ¿porque las actividades diarias de codificar no son parte de la función del arquitecto? La mayoría de los arquitectos tienen bastante experiencia, entonces tiene sentido mantener esas habilidades actualizadas. Además, el arquitecto puede experimentar el mismo dolor que todos los demás en el equipo, que a su vez ayuda a entender mejor como es vista su arquitectura desde la perspectiva de los desarrolladores. Muchas compañías tienen políticas que previenen a los arquitectos de escribir código porque sus arquitectos son "tan valiosos como para ejecutar este trabajo cómodo".
Claramente es una actitud incorrecta ... ¿por qué dejar que tus arquitectos pongan todo su esfuerzo en definir la arquitectura si no vas a dejar que contribuyan a su liberación exitosa? Por su puesto que hay situaciones donde no es práctico que se involucren a nivel código. Por ejemplo, un proyecto grande generalmente significa un panorama más amplio que cuidar y puede haber ocasiones donde simplemente no tengas el tiempo. Pero generalmente hablando, un arquitecto que codifica es más efectivo y más feliz que un arquitecto que solo mira desde un extremo.

¿Eres un arquitecto de software?

A menos de que veas la linea entre el desarrollo de software y arquitectura como mítico o un amplio abismo, los elementos arriba resaltan que los niveles de experiencia de la gente con la función de arquitectura de software varía considerablemente dependiendo de que tan comprometidos están y que tan seriamente ven su papel. La mayoría de los desarrolladores no despiertan en un Lunes por la mañana y se declaran a sí mismos ser arquitectos de software. Ciertamente no y mi camino en la arquitectura de software fue en gran medida un proceso evolutivo. Habiendo dicho este pensamiento, hay una alta probabilidad de que los propios desarrolladores ya estén tomando en cuenta las partes que conforman la arquitectura de software, independientemente de su título laboral.

Hay una gran diferencia entre contribuir a la arquitectura de un sistema y ser el responsable de definirla tu mismo; con una continuidad de habilidades, conocimiento y experiencia necesaria a través de las diferentes áreas que forman la función de un arquitecto. Cruzar la línea entre el desarrollador y el arquitecto es tu decisión, pero entender tu propio nivel de experiencia es el primer paso en la jornada.

SimonBrown | Codificando la arquitectura (ingles) |
Arquitectura de sofware para desarrolladores (ingles)

Instalando most como pager en Linux

2010-02-18T14:32:00.000-08:00

Casi todos estamos familiarizados con los paginadores más famosos en GNU/Linux, con los cuales un texto largo en consola puede verse tranquilamente pantalla a pantalla...

Puede ser que usemos el clásico more(1), o que por otro lado utilicemos less(1).

¿Tenemos más opciones? La respuesta es sí...

more debe su nombre (que significa 'más') a la pequeña línea al final de cada pantalla con la indicación de que, presionando cualquier tecla, podemos ver más del texto que estamos visualizando.

less, por su parte, pretende ser un complemento a more, ya que este último no permite 'navegar' hacia arriba y abajo del texto visualizado, mientras que less si lo permite. Su nombre es en realidad una broma, pues 'less es más que more' (less is more than more). less significa, literalmente, 'menos'.

Por su parte, most es otro paginador para sistemas GNU/Linux. No suele ser parte de alguna distribución en particular, pero presenta características que lo hacen aún más útil que less. Además de la navegación vertical, también se permite la navegación horizontal (evitando que las líneas de más de 80 caracteres de longitud se regresen al inicio, confundiendo al lector). Igualmente, permite búsquedas, entre otras características. En este sentido, 'most es lo que un paginador debe de ser' (most is what a pager must be). most significa 'mas que cualquiera', y must significa 'debe de'.

Para instalar most, debe bajarse el código de su sitio oficial:

http://www.jedsoft.org/most

Se puede bajar la última versión en un archivo tar.gz, o por su lado hacer un checkout del repositorio del código, para tener la última versión con Subversion:

svn co http://opensvn.csie.org/jedsoft/most/trunk most

Una vez con el código fuente, hay que seguir los clásicos pasos de instalación en software GNU:

./configure

make

make install

El proceso puede llegar a marcar algún error si no se cuenta con todas las librerías necesarias. El caso es que normalmente suelen requerirse las librerías de S-Lang, las cuales normalmente sí están incluidas en las distribuciones Linux (hay que tomar en cuenta que se debe instalar el paquete de desarrollo de S-Lang, para instalar las cabeceras de código necesarias). Si no, en jedsoft.org también se puede conseguir esta librería.

Hecho esto, most ya puede utilizarse para paginar textos con:

most archivo

(Nótese la salida con colores y todo lo demás).

Si lo que se desea es que most sea el paginador por defecto, hay que sobreescribir la variable de entorno PAGER.

export PAGER=most

Haciendo esto en .bashrc o en el archivo de incio de sesión apropiado, se puede hacer este cambio permanente.

Con esto, cabe aclarar, ahora incluso las páginas del manual man que se consulten utilizarán most para desplegarse, pues man utiliza el PAGER para mostrar las páginas solicitadas. Nótese también que la salida de man utilizando most está bastante más estilizada que con less...

Construye tu propio servidor LAMP

2010-02-11T19:14:00.000-08:00

Vamos a instalar varios servidores que en conjunto se suelen conocer como LAMP (Linux-Apache-MySQL-PHP), básicamente necesitamos Apache para poder montar nuestras paginas web, php para poder programarlas y mysql para almacenar nuestros datos pero como ya deben saber para que funciona cada una, voy a enfocarme más a la instalación propiamente sobre un linux ubuntu 9.10.

Instalar Apache2 y configurar PHP5
Debemos descargar los paquetes desde el repositorio de ubuntu usando apt-get de la siguiente forma:

sudo apt-get install apache2 php5 libapache2-mod-php5

El comando sudo te permitirá ejecutar los comandos como administrador, esto es muy común en ubuntu, la única diferencia de hacerlo sin el comando sudo es que te pedirá tu contraseña y listo, te mostrará algo como la siguiente imagen. Debes responder 'Y' a la pregunta y empezará a descargar primero los paquetes, luego a instalarlos automáticamente.

Prepara tu café porque se va a descargar como de 7 a 10MB.

El paquete apache2 instalara el servidor web, php5 instalará el core para interpretar los scripts php y el utlimo: libapache2-mod-php5 configurará a php como módulo del servidor web. Si quisieras usar la version 4 de php, debes indicar en el comando anterior los siguientes paquetes: php4 y libapache2-mod-php4.

Por default, el archivo de configuración de apache se ubicará en /etc/apache2/apache2.conf y la ruta donde debemos ubicar nuestras páginas es en /var/www que a su vez se mapea a http://localhost.

Para poder manipular nuestro servidor web apache2 recientemente instalado podemos utilizar el siguiente comando con las instrucciones start, stop, restart y status, por ejemplo, para conocer el estatus haremos:

/etc/init.d/apache2 status
* apache is running (pid 2575)

Para probar que efectivamente este corriendo, podemos ir a nuestro browser y la página: http://localhost, si todo corrió como se era esperado veremos un resultado como la siguiente imagen. Recuerda que si piensas utilizar esta forma para parar, iniciar o reiniciar los servicios, debes utilizar sudo.

Para comprobar que se esta ejecutando correctamente el modulo php sobre apache, podemos hacer un script de prueba php. Ejecuta:

sudo nano /var/www/test.php

(abrirá el editor de textos llamado nano y copia el siguiente texto)

<?php phpinfo(); ?>

Luego aprieta CTL+X para salir y luego Y para indicar que se guarde el archivo y finalmente ENTER para confirmar el nombre del archivo (debe ser test.php)
Para comprobar que se haya escrito el archivo, ejecuta lo siguiente para ver su contenido:
sudo cat test.php
Si aparece la linea de phpinfo() ahora si puedes probar en http://localhost/test.php y verás algo como en la imagen abajo.

Instalar MySQL 5
Instalemos ahora el motor de base de datos MySQL, para ello, ejecutemos el siguiente comando:

sudo apt-get install mysql-server mysql-client php5-mysql

Igual que antes, solicitará nuestra contraseña, respondemos con 'Y' a la pregunta "Do you want to continue [Y/n]?" e instalará el paquete mysql-server para el servidor de base de datos, mysql-client para el cliente tipo consola que más adelante ocuparemos y php5-mysql para configurar el core de php con el fin de que pueda consultar los datos a una base de datos mysql. Si escogimos instalar la version 4 de php, debes instalar php4-mysql en lugar del anterior.

Ahora sí tómate tu café porque se van a descargar como 59MB.

El archivo de configuracion de mysql por defecto se encuentra en /etc/mysql/my.cnf. Aunque en mi caso particular; luego de descargar los paquetes e instalar el servidor de mysql; me pidió en la consola que cambiara el password para root, por defecto el servidor se instala con el usuario root sin contraseña, no obstante esto se puede cambiar (y es recomendable hacerlo a la brevedad) haciendo lo siguiente:

>mysql -u root
mysql> use mysql (para usar la base de datos mysql)
mysql> update user set password=password('aqui escribe tu nuevo password') WHERE user='root';
mysql> flush privileges

La instrucción final es para que aplique nuestros cambios. Por último, se puede indicar al servidor que se levante, se pare o reinicie, mediante start, stop o restart, respectivamente y de la misma manera que se hacía con apache:

sudo /etc/init.d/mysql status

* Instalar un gestor web para mysql: phpmyadmin

Esto es opcional, pues solo se trata de un cliente web para mysql, puedes usar en su lugar cualquier aplicación de escritorio para conectarse al servidor como por ejemplo: Navicat . phpMyAdmin es una aplicación web muy utilizada, fácil de configurar y sencilla de usar para administrar nuestras bases de datos en mysql. Se pueden administrar privilegios, usuarios y bases de datos con tan solo unos clics. Se le pueden instalar temas para cambiar su vista, existe bastante documentación (aunque en inglés), sin embargo hay un libro en español y ha ganado diversos premios como mejor herramienta para desarrolladores y administración de sistemas, por mencionar un par. Antes de instalarlo, puedes probarlo aquí.

Si te has decidido a instalarlo, ejecuta lo siguiente:

sudo apt-get install phpmyadmin

Se va a descargar otros 5MB, tu eliges si vas por otro cafe o mejor por un te.

Luego de la instalación, intentará configurarlo, pedirá la contraseña de la cuenta de root de mysql que anteriormente dimos de alta y también preguntará si quieres configurar mediante dbconfig-common, a lo cual respondemos con Yes. Si lo queremos hacer a mano, también podemos decir que No para saltarnos este paso y listo.

Los archivos de configuracion se ubicarán por defecto en /etc/phpmyadmin pero para poder usarlo con el servidor apache que acabamos de instalar debemos editar /etc/apache/apache2.conf y agregar la siguiente linea:

Include /etc/phpmyadmin/apache.conf

luego reiniciemos el servidor apache para que tome en cuenta los cambios.

sudo /etc/init.d/apache restart

Una vez que se reinicie y si todo corrió perfecto, podemos ir a http://localhost/phpmyadmin, nos pedirá los datos del usuario root y contraseña de mysql que recientemente cambiamos mediante el cliente mysql de consola.

Otras alternativa con XAMPP para linux:
Resulta que al terminar este blog me encontré con XAMPP para linux y parece muy prometedor, lo he visto corriendo en windows pero en linux no parece existir mucha diferencia, salvo que al momento de este post, la versión mas actual es 0.9.5 y tiene algunas fallas en seguridad, por lo que solo te recomiendo instalarlo en un entorno de red controlado, normalmente local para pruebas. Aquí hay unas ligas para que le hechen un ojo y me parece todavía mucho más sencillo de instalar con esta herramienta.

Instrucciones de instalación (son 4 pasos nadamás)
Revisa los screenshots y date cuenta que es muy amigable.

Referencias:

Otros enlaces relacionados:

Uso del comando awk en linux

2010-02-05T18:51:00.000-08:00

Algunas de las limitaciones del comando sed se remedian por medio del comando awk, pues aunque se parece mucho a sed, los detalles se basan más en el lenguaje de programación C que un solo editor de textos. Uso:

awk 'programa' archivos
Sin embargo, la constitución del programa es distinta:
patron { acción }
patrón { acción }
patrón { acción }
... (mas patrones y acciones)

A semejanza del comando sed, awk tampoco modifica los archivos de entrada, solamente la salida que imprime. El comando awk lee la entrada de un archivo un renglón a la vez, para el cual compara con cada patrón en orden, de esta manera, para cada patrón que concuerde se efectúa la acción correspondiente.

Los patrones son expresiones regulares como en el comando egrep o condiciones complicadas como en el lenguaje C. Por ejemplo:

awk '/expresión regular/' { print }' archivos
awk '/expresión regular/' archivos

Esta instrucción consiste en imprimir aquellas líneas que concuerden con la expresión regular, si se omite una acción, se imprime, por lo que ambas líneas muestran el mismo resultado. En caso de omitir el patrón, la parte de la acción se ejecuta a cada línea de entrada.

También es posible, al igual que sed, indicar el programa a awk en forma de archivo como sigue:

awk -f archprog archivos

A diferencia del shell, en awk, sólo los campos empiezan con un $, las variables no tienen adornos, por ejemplo, awk reconoce los campos $1, $2 y así sucesivamente hasta $NF, donde NF es una variable igual al total de campos. En el ejemplo de abajo, NF es igual a 5, pero $1 representa a cada usuario en sesión, por línea procesada.

# who
root pts/0 Dec 25 10:30
margo pts/1 Dec 25 13:37
wendy pts/2 Dec 25 16:36

De manera que podemos imprimir solo la hora en que entró en sesión cada usuario:
# who | awk '{ print $1,$5 }'
root pts/0 Dec 25 10:30
margo pts/1 Dec 25 13:37
wendy pts/2 Dec 25 16:36

Awk supone que el espacio en blanco (ya sea un número de espacios o de tabuladores) separa los campos, a excepción del que se encuentra al principio. Los espacios al principio de línea se consideran elementos del primer campo. Pero el separador puede cambiarse por cualquier otro caracter por medio de la opción -Fc, donde c es el caracter que usará awk como separador. Por ejemplo:

#sed 3q /etc/passwd | awk -F: '{ print $1 }'
root
bin
daemon

Awk es más fácil de utilizar que sed en operaciones como la anterior pero es mas lento al iniciar y ejecutar cuando existe mucho texto a la entrada.

Impresión
Además de reconocer los campos $1, $2, etc. awk reconoce $0 como el conjunto de campos que se encuentran en la línea, es decir, la línea entera sin cambios. También la variable NR que indica el número de línea actual y NF el número de campos por cada línea. A la salida, cuando se imprimen varios campos, el separador por defecto que se utiliza es un espacio en blanco; sin embargo, este puede cambiar a través de otra proposición llamada printf que controla por completo la salida. Ejemplo:

awk '{ printf "%4d %s\n", NR, $0 }'

La instrucción anterior debería imprimir el número de línea dentro de un campo con 4 espacios. Los caracteres %4d especifican un entero decimal dentro de un campo de cuatro dígitos de ancho, mientras que %s especifica una cadena y por último \n representa una linea nueva al final de cada renglón, por lo que cada línea de entrada procesada se imprimirá en un renglón nuevo, de lo contrario se sobreescribiría cada línea.

También se puede redireccionar la salida de print o printf hacia archivos e interconexiones, pero debe estar acompañada de '>' y un nombre de archivo entre comillas simples; de igual manera, con '>>' se anexa en vez de sobreescribir en el archivo indicado entre comillas. Para las interconexiones se utiliza el símbolo pipe '|'.

Patrones
Para preguntar si hay una similitud con un patrón, se hace uso, básicamente, de una sentencia de control (if en lenguaje C), esta permite hacer uso de operadores de comparación y concordancia para identificar un patrón dentro de una linea, además de otras funciones predefinidas como length() que obtiene la longitud de una cadena situada entre sus parétesis.

Por ejemplo, para una concordancia se utiliza el signo '~', pero requiere que la expresión regular se encuentre encerrada entre diagonales. También a un patrón puede anteponérsele el símbolo '!' para negarlo. Ejemplo:

!($2 == "x") Pregunta en c/línea si el campo 2 es una 'x'
length($2) == 0 Pregunta si la longitud del campo 2 es cero
$2 !~ /./ Pregunta si el campo 2 no concuerda con una texto que contenga cualquier caracter
$2 ~ /user/ Pregunta si el campo 2 concuerda con el patron 'user'

También se puede enviar a la salida, algunos comentarios más informativos que expresen cuando existió un error o simplemente notificar que algo sucedió, por ejemplo, para indicar que un renglón es demasiado largo:

awk 'length($0) > 60 { print "Linea", NR, "muy larga:", substr ($0,1,60) }'

Esta acción impide que se impriman líneas mayores a 60 caracteres, en lugar de eso, imprime un mensaje notificando que la línea es muy larga y también incluye la función substr que produce que solo se imprima la subcadena del caracter 1 al 60 de la actual que representa $0, es decir, aquella que es muy larga. Si se hubiera omitido el 60, el cual marca el final de la subcadena, se imprimiría toda la línea.

Usos de las secciones BEGIN y END
AWK facilita los patrones especiales BEGIN y END, los cuales se refieren a las acciones a ejecutar antes de leer el primer renglón de entrada y después de leer el último. Generalmente son empleados para inicializar variables, imprimir encabezados o posicionar separadores de campo por medio de la variable FS:

awk 'BEGIN { FS = ":" }
> $2 == "" ' /etc/passwd
ò
awk 'END { print NR }' /etc/passwd

Operaciones
La verdadera fuerza de awk se entra en su capacidad de hacer cálculos sobre los datos de entrada. Se facilita el conteo, sumar y promediar, entre otras. Por ejemplo, para sumar columnas de números:

{ s= s + $1 }
END { print s }

Este programa debería encontrarse en un archivo (prog.txt) y en otro se debería encontrar una serie de números en la primer columna (num.txt). Al final, la instrucción desde el shell sería:

awk -f prog.txt num.txt

Lo mejor de todo es que respeta los números decimales, a diferencia de las operaciones que se realizan directamente sobre el shell. AWK ofrece los mismos operadores aritméticos que el lenguaje C, de manera que en el ejemplo anterior s = s + $1 será lo mismo que s += $1. Todos los operadores aritméticos y lógicos se muestran a continuación por orden creciente de precedencia:

= += -= *= /= %= Asignación
|| Comparación OR
&& Comparación AND
! Negación
> >= < <= == != ~ !~ Operadores relacionales
nothing Concatenación de cadenas
+ - más, menos
* / % multiplicar, dividir, residuo
++ -- incrementar, decrementar (prefijo ó posfijo)

Funciones predefinidas
Existen un conjunto de funciones predefinidas en awk, las cuales se listan a continuación y pueden ser utilizadas de una manera muy simple.

cos (expr) Obtiene el coseno de expr
exp (expr) Obtiene el exponencial, es decir e^expr
getline () Lee la siguiente linea de entrada, devuelve 0 si es fin de archivo y 1 si no.
index (s1, s2) Devuelve la posición de la cadena s2 en s1, pero 0 si no la encuentra
int (expr) Realiza un cast como en lenguaje C para que expr sea considerado entero
length (s) Obtiene la longitud de la cadena s
log (expr) Obtiene el logaritmo de expr
sin (expr) Obtiene el seno de expr
split (s, a, c) Divide s en elementos del arreglo a, utilizando el separador c
sprintf (fmt, ...) Da formato a ... según la espedificación fmt
substr (s, m, n) Substrae una cadena dentro de otra s, iniciando en m y terminando en n

Variables y arreglos
Las variables se definen al utilizarse, se inicializan a cero por defecto pero no se declaran previamente. Las variables en awk también guardan tanto números como cadenas de caracteres, la diferencia depende del contexto a tratar. En termino generales, una expresión aritmético como s+=$1 permitirá almacenar un valor numérico en s, mientras que otro contexto cmo s="abc", almacenará una cadena en la misma variable.

En casos ambiguos como x>y se utiliza el valor de cadena a menos que los operandos sean totalmente numéricos. Las variables de cadenas se inicializan a la cadena vacía. En awk existen también, variables predefinidas que utiliza el comando para su funcionamiento general, estas se listan a continuación:

FILENAME Nombre del archivo de entrada actual
FS Caracter separador de campo
NF Numero de campos en cada registro o línea
NR Numero de línea actual
OFMT Formato de salida para números (%g por defecto, según printf())
OFS Cadena separadora de campo de salida (defecto: espacio)
ORS Cadena separadora de línea (defecto: nueva línea)
RS Caracter separador de línea de entrada (defecto: nueva línea)

Los arreglos, mientras tanto, son parecidos al lenguaje C y otros lenguajes de programación. Como las variables, no necesitan ser declarados; el tamaño de un arreglo está limitado por la memoria de la máquina. Por ello, si un archivo muy extenso se está transfiriendo a un arreglo, probablemente se agotaría la memoria rápidamente.
De la misma manera en que el procesamiento normal de la entrada divide cada renglón de entrada en campos, es posible efectuar la misma operación para la separación de campos y almacenar el resultado en un arreglo, por medio de la función split (s, arr, sep), donde s representa la cadena original, arr el arreglo donde se almacenará cada campo, sep el separador de campos, el cual es opcional, pues el defecto es el espacio. Por último, el valor que devuelve la función split es el total de elementos almacenados en arr. Ejemplo:
arr[1] = "lola"
arr[2] = "beltran"
ó
s = "lola beltrán"
n = split ( s, arr )
#sed 1q /etc/passwd | awk '{split ($0,a,":"); print a[1]}'
root
wdonet
luis
maotse

También existen los arreglos asociativos, puesto que uno de los problemas ordinarios consiste en acumular un conjunto de valores para un conjunto de nombres. Esto es, que en lugar de índices numéricos, también se pueden utilizar cadenas aleatorias. Ejemplo:
honor[susana] = 10
honor[felipe] = 9.8
honor[marco] = 9.5
honor [patricia] = 9.2
AWKofrece una manera adecuada de manipular este tipo de arreglos, por medio de una variación del for, que se puede ver en el apartado de control de flujo. La realización de la memoria asociativa se vale de un esquema de hashing para garantizar que el acceso a cualquier elemento tarde el mismo tiempo aproximado que las demás y que por lo menos, el tiempo no depende de cuántos elementos contenga el areglo. La memoria asociativa es eficiente en tareas como contar todas las palabras de una entrada.

CadenasLa diferencia entre sed y awk, es que sed se utiliza mayormente para editar o filtrar algún texto de entrada, es decir, es un sistema simple de entrada-proceso-salida; mientras que awk se utiliza en tareas que de verdad requieren programación. Es por eso que hace uso de sentencias de control de flujo. En awk no hay operadores explícitos de concatenación de cadenas; éstas se concatenan cuando están contiguas.

Shell
Como ya se vió anteriormente y al igual que la creación de scripts de shell, en awk se pueden identificar los campos de una entrada (salida de algún comando del shell actual), por medio del número de campo, precedido por '$', es decir, para el campo uno, será $1, para el segundo, $2 y así sucesivamente. Sin embargo, en el caso de que se deseen pasar parámetros del shell a un programa awk, se puede realizar por medio de un uso correcto de las comillas.

Por ejemplo, suponiendo que field es un programa de awk que consiste en imprimir solo una columna de cada registro, para ello, se le necesita indicar con un parámetro, el número de columna. El comando tecleado en el shell, es de la siguiente forma:
# who | field 1
Para pasar el argumento como 1 al comando awk, se hace lo siguiente:
'{ print $' $1 ' }'
De esta manera el $1 que se refiere al parámetro del shell, se mantiene fuera de las comillas simples y se remplaza su valor correcto. Otra forma es:
# awk "{ print \$$1 }"

El problema no estriba en llevar el control de si uno está dentro o no de las comillas, sino en el hecho de que, en su redacción actual, tales programas no pueden leer más que su entrada estándar; no hay manera de pasarles el parámetro n y una lista arbitrariamente larga de nombres de archivo. Esto requiere programación con shell.

Control de flujo
Awk permite controlar el flujo de la programación para tratar una entrada, básicamente son los mismos ciclos de cualquier lenguaje de programación, pero se asemeja mas al lenguaje C, como en muchas otras cosas. A continuación se presenta cada sentencia:
Sentencia IF-ELSE
if (condición)
    proposición 1
else
    proposición 2
Sentencia FOR
for (expresión1; condición; expresión2)
    proposición
Sentencia FOR para arreglos asociativos
for (var in array)
    proposición
Sentencia WHILE-DO
expresión 1
while (condición){
    proposición
    expresión 2
}
Por ejemplo1: awk ' BEGIN { NR = 1 }
Por ejemplo2:
while ( NR != 5 ){
    if ( i == NF )
        print "Se llegó al límite"
    else
        print i, $0
    NR+=1
}' $*
Este pequeño programa de awk, lee las primeras 5 líneas de una entrada dada, y cuando llega a la fila o línea 5, indica que se ha llegado al límite.
awk ' { line[ NR ] = $0}
END { for (i = NR; i> 0; i--) print [ i ] } ' $*
Ahora, este programa de awk, imprime las líneas de una entrada en orden inverso.

Usos de awk
El uso común de patrones se refiere a la validación de datos, puesto que la mayoría de ellas consiste en buscar los renglones que cumplen o no con un criterio en específico. Awk tiene la convención de que los comentarios inician después de un '#' y toma el resto de la línea como comentario.

Los usos de awk sonsisten en programas de una o dos líneas que actúan como filtros dentro de una interconexión mayor. De estar manera, la mayoría de problemas se resuelve aplicando un solo filtro para cada interconexión, es decir, subdividiendo el problema mayor. Sin embargo, el concepto resulta restricto.

La salida producida por los programas escritos en UNIX, está en un formato reconocido como entrada por otros programas. Los archivos filtrables contienen líneas de texto sin encabezados decorativos, terminadores, ni líneas en blanco,. Cada renglón es un objeto de interés, de ahí que programas como wc y grep puedan contar elementos interesantes o buscarlos por nombre. Al momento de que se cuenta con mas imformación para cada objeto, el archivo permanece en su formato pero ahora agregando la división por columnas con campos separados mediante blancos o tabuladores, de esa manera programas como awk pueden seleccionar, procesar o rearreglar la información de manera sencilla.

Cada filtro escribe sobre su salida estándar el resultado de procesar los archivos dados como argumentos o la entrada estándar si no se dan argumentos. Estos especifican la entrada pero nunca la salida, de esta manera, la salida de un comando puede introducirse en una interconexión. Los argumentos opcionales preceden a cualquier nombre de archivo y por último, los mensajes de error se escriben sobre el error estándar, por lo que no desaparecen a lo largo de las interconexiones. Los comandos individuales, difícilmente, pueden hacer uso de tan sencilla estructura.

Ciclo de vida en JSF

2010-01-29T17:56:00.000-08:00

JSF (Java Server Faces) es un framework de desarrollo basado en el patrón MVC (Modelo Vista Control), su intención es estandarizar el desarrollo de aplicaciones web similar al estilo de Swing o Delphi, donde la interfaz se realiza mediante componentes y basada en eventos, esto permite que sea bastante flexible y sencillo, especialmente para quienes ya están acostumbrados a los componentes y eventos. No obstante aún no tiene la experiencia de otros frameworks y es importante entender como trabaja.

Algunos conceptos que debemos tener en mente son:
Managed Bean (o Backing Bean) . Es un pojo que se asocia con los componentes de la interfaz de usuario (UIComponent), dentro de sus funciones está

Almacenar referencias a los componentes de la vista y ponerlos a la disposición del controller (durante el ciclo de vida JSF).
Proveer de las propiedades necesarias para la vista, como el comportamiento de la pantalla, la información que se presenta e inclusive hasta algunos elementos del diseño gráfico.
Exponer los métodos que pueden ser usados por los componentes para comunicar al servidor de la iteracción con el usuario.

Binding, es el acceso programático a los componentes de la vista, mismos que heredan del árbol jerárquico de componentes con la raíz UIviewroot.

Convertidores, son parte de la vista y es un proceso que transforma una cadena del lado de la vista a un tipo de dato Java en el lado del servidor y así mismo de regreso.

Validaciones, son usadas para validar los datos de los componentes de acuerdo al uso de la vista o las reglas de negocio.

Method expressions, son usados para comunicar eventos de la vista al modelo de presentación como ActionEvent, ValueChangeEvent, PhaseEvente. Soportan invocaciones arbitrarias a métodos públicos del managed bean.

Ahora describiremos las 6 fases del ciclo de vida en JSF.

1. Restaurar vista :: Restore View

En esta etapa se crea la vista con la información desde cero o la ya existente en los componentes si fue redireccionada desde otro control de jsf.

Si no encuentra datos enviados por método POST, se salta directamente a la etapa de producir respuesta.

2. Aplicar valores a petición :: Apply Request Values

Se invocan los convertidores definidos, si falla alguno, se marca el componente UIComponent como erróneo con setValid(true) y se agrega un mensaje al contexto de faces con addMessage(), luego se va directamente a producir respuesta.

La funcionalidad del convertidor es transformar el dato String de la forma a uno de tipo Java y viceversa, también mantiene el dato String para seguirlo presentando en pantalla en la etapa de producir respuesta.

Finalmente se guardan los valores enviados por la forma como cadenas dentro del componente (setters del UIComponent). Cadena es lo único que pueden devolver la forma java: HttpServletRequest.getParameter().

Se puede usar el atributo immediate para saltar el proceso de conversión y validación de datos. Generalmente es usado para botones como Cancelar.

3. Procesar validaciones :: Process Validation

Se llama a los validadores de cada componente: validate(), con la regla de profundidad primero, se usan los valores enviados por la fase de aplicación de valores, si alguna validación falla, se marca el componente como erróneo con setValid(true) y se agrega un mensaje con addMessage() , después salta directamente a la fase producir respuesta.

Aunque se pueden ejecutar validaciones de todo tipo, se recomienda que en esta fase se manejen solo aquellas que dicten el uso de la vista.

4. Actualizar modelo :: Update Model

Actualiza los beans (mediante los setters del ManagedBean) del modelo asociados al componente. Esta asociación es generalmente usada con el atributo value del componente jsf.

5. Invocar la aplicación :: Invoke Application

Se ejecutan los eventos encolados y pendientes (actionEvent).

En esta fase se ejecuta la lógica de negocio y es recomendable implementar aquí las validaciones del modelo de domino o procesos de negocio necesarios.

Como resultado de estas validaciones y/o procesos de negocio, se manipula la navegación entre las pantallas.

6. Producir respuesta (final) :: Render Response

Se genera la respuesta HTML, cada componente pregunta al modelo de presentación para recuperar los datos que necesita mostrar (getters del UIComponent).

Utiliza un kit de rendereo (o renderkit) que puede ser modificado para presentar la respuesta en xml, por ejemplo para un browser tipo wap.

Este ciclo de fases se repite continuamente en cada petición que se hace al servidor. Si se realizan peticiones parciales como en ICEfaces, también se produce el mismo ciclo con leves modificaciones para evitar ejecutar las conversiones y validaciones en campos que aún no han sido llenados por ejemplo.

En resumen podríamos decir que por cada petición al servidor, las fases producen los siguientes pasos sobre los datos de las formas enviadas: convertir valores de la forma, validarlos, se generan eventos de cambio de valor (valueChangeListener), ejecuta setters en modelo de dominio (ManagedBean) y setters en modelo de presentación (UIComponent).

Notas finales:

Cuando se usa el atributo immediate y la directiva renderResponse con programación pero se quiere guardar cualquier dato alterado en la forma, entonces se necesita usar ValueChangeEvent para actualizar manualmente el modelo de dominio.
ResponseComplete es una directiva similar al renderResponse, la diferencia radica en que el primero obliga a terminar el ciclo de vida del JSF y puede ser usado en procesos de lado del cliente para eventos AJAX, pero no se desea actualizar completamente la vista o intentar obtener datos binarios desde la vista.

Referencias:

Steven L. Murray | Iván Zaera Avellón |

Especificaciones JSR127 | JSR252 | JSR276

Mashups con Presto

2010-01-26T23:28:00.001-08:00

Después del curso de Presto, hice unas pequeñas anotaciones que me interesó compartir (antes que se queden como borrador en mi correo por una eternidad).

Un portlet es una sección en la pagina web que permite ejecutar transacciones de forma separada, como una mini-aplicación independiente. De esta manera si se conjunta varios para visualizarlos como uno solo, se le llama Orquestación.

Con Presto, la orquestación la realiza 'Mashup engine' y para enlazar los servicios graficamente se hace con 'Mashup Composer'. Ambos son parte de los servicios que proporciona Presto.

Presto utiliza Mashlets, Mashups y Servicios, usando el Jackbe Universal Mashup Protocol (JUMP) y para producir salidas en formato xml o json. Los servicios se registran en 'Service Explorer'.

EMML es un lenguaje de programación que utiliza Presto para crear mashups. Algunos tags que utiliza son los que siguen.

<mashup> - inicia el xml para crear un mashup
<foreach> - para generar un ciclo
<display> - para desplegar el contenido de una variable
<constructor> - permite construir la estructura raíz de la salida
<operation> - define una operación a ejecutar
<annotate> - permite agregar elementos a un xml
<invoke> - permite invoca servicios publicados por Presto
<directinvoke> - sirve para invocar servicios que no son de Presto
<merge> - se usa para hacer una mezcla de los valores de dos o mas variables
<filter> - permite filtrar contenido

Presto también usa estos conectores para invocar servicios de Presto desde Excel, JS, Java y Csharp, entre otros.

Glosario

xpath es una forma de recorrer la estructura xml
xquery es equivalente a SQL pero para datos que vienen en formato XML.

Ejemplos en la red.

Mashups no empresariales Yahoo Pipes , netvibes ,
Mashups empresariales Presto

Publicar Mashup por linea de comandos

2010-01-22T19:10:00.000-08:00

Por si necesitan instalar mashups mediante la linea de comandos (sin necesidad del Eclipse y el plugin de Presto) debes hacer lo siguiente:

En la carpeta \Presto2.7.0\mashupclient\bin dejar el archivo emml (o en tu caso tener identificada la ruta del emml)
Abrir una línea de comandos
Ir a la ruta \Presto2.7.0\mashupclient\bin
Ejecutar la siguiente línea:

emmlpub -f mashup-script-filename -u user-name -p password [-desc description -t tag [...] -app application [...] -P provider -url presto-url]

por ejemplo

emmlpub -f c:/miaplicacion/mashup/fgdasfad.emml -u admin -p adminadmin -url http://localhost:7070/presto/edge/api

Obviamente en la URL debe ser la del server en donde vas a publicar el servicio.

Instalando e iniciandose con Symfony 1.4

2010-01-20T20:38:00.000-08:00

Symfony es un framework para desarrollar aplicaciones web de manera rápida bajo PHP.

Actualmente se encuentra en su versión 1.4, y a la fecha es uno de los frameworks más populares para desarrollar con PHP (junto con CakePHP y el Zend Framework...)

El sitio web de Symfony presume su framework como uno de los más rápidos, no sólo para desarrollar, sino también para aprender. Según ellos, siguiendo sus tutoriales en un programa sencillo de aprendizaje, se podría decir que se toman exactamente 2 días (48 horas) en aprender Symfony. En realidad se podría llevar un poco más, dependiendo el tiempo libre que se tenga (además de que hay que dormir, comer y demás...)

La instalación, configuración y levantamiento de un primer proyecto en Symfony es, en realidad, sencillo:

Requisitos previos
Un entorno LAMP podría ser suficiente (GNU/Linux / Apache / MySQL / PHP), o WAMP si se prefiere. En vez de MySQL, Symfony también puede trabajar, gracias a Doctrine, su ORM por defecto, con PostgreSQL, SQLite entre otros.

El script localizado en:

http://sf-to.org/1.4/check.php

Permite verificar si las características de la máquina corresponden con las necesarias para instalar y utilizar Symfony. Se baja el script y se ejecuta en el equipo con:

php check_configuration.php

Instalación
Lo primero es descargar Symfony. En http://www.symfony-project.org/installation se encuentra una pequeña guía para bajar la versión que se desee instalar.

Una vez con el paquete, debe descomprimirse (con tar -xzvf archivo.tar.gz) El directorio en donde se descomprime el paquete será el lugar en donde los proyectos de Symfony consultarán para los archivos que comparten dichos proyectos. El directorio en donde queda descomprimido Symfony se puede renombrar a symfony para simplificar.

Hecha la instalación, se puede verificar que todo está en orden con:

php ruta_donde_se_descomprimio_symfony/symfony/data/bin/symfony -V

lo cual debe mostrar la versión instalada de Symfony.

Si no se le pasan parámetros a symfony, se muestran todos los comandos disponibles para Symfony.

Creación de un proyecto
Ubicados ya en el lugar en donde se desea crear el proyecto Symfony, se escribe:

php ruta_donde_se_descomprimio_symfony/symfony/data/bin/symfony generate:project NOMBRE_PROYECTO

Lo cual creará dentro del directorio actual la estructura de un proyecto Symfony, que incluye varios directorios, utilizados por el framework para acceder a los recursos: la aplicación, el MVC, la base de datos, etc.

También se crea un acceso directo a symfony, para no tener que teclear toda la ruta donde se descomprimió el framework.

Configuración de la Base de Datos
La conexión a la Base de Datos se configura con un simple comando de Symfony:

php symfony configure:database "mysql:host=localhost;dbname=nombrebd" usuario password

Por default, Symfony utiliza Doctrine como ORM. Aunque también se puede utilizar Propel.

Creación de una aplicación
En Symfony, los proyectos se componen de aplicaciones (que a su vez se componen de módulos, y estos de tareas -o tasks-).

La aplicación principal, el portal por así decirlo, se llama frontend (mientras que la aplicación de administración se llama backend). La creación de una aplicación es un proceso sencillo:

php symfony generate:app frontend

Esto creará, dentro del directorio del proyecto, en el subdirectorio apps, un subdirectorio llamado frontend, con la estructura que el framework utiliza para sus aplicaciones.

Otras configuraciones
Hay algo que debe tenerse en cuenta también, y es que los subdirectorios cache y log del proyecto deben poder ser vistos y escritos por cualquier usuario del sistema. En GNU/Linux:

chmod 777 cache/ log/

Configuración del servidor web
Para poder acceder al proyecto, ya sea en desarrollo o en producción, el servidor web debe configurarse para que se pueda ver dicho proyecto. Una forma sencilla, pero poco elegante, es crear el proyecto directamente en el directorio en donde el servidor web publica, por ejemplo /var/www. Sin embargo, la mejor manera es utilizando VirtualHosts:

NameVirtualHost 127.0.0.1:8080
Listen 127.0.0.1:8080
<VirtualHost 127.0.0.1:8080>
  DocumentRoot "ruta_al_proyecto/web"
  DirectoryIndex index.php
  <Directory "ruta_al_proyecto/web">

    AllowOverride All
    Allow from All

  </Directory>

  Alias /sf ruta_donde_se_descomprimio_symfony/symfony/data/web/sf

  <Directory "ruta_donde_se_descomprimio_symfony/symfony/data/web/sf">
    AllowOverride All
    Allow from All

  </Directory>
</VirtualHost>

Con lo cual, se podrá acceder a la aplicación en http://localhost:8080. Obviamente, se puede configurar otro puerto, y los directorios deben apuntar a donde se encuentre en realidad el proyecto. Nótese el segundo alias, el que dice /sf, este apunta a donde se instaló Symfony. Esto se debe a que todo proyecto espera encontrar en su ruta /sf todo aquello que Symfony pone a disposición de todos los proyectos. En vez de descromprimir Symfony intacto proyecto por proyecto, un Alias simplifica esta labor.

Y precisamente, lo único que queda es probar.

Accediendo a:
http://localhost:8080/index.php/

Se debe de poder ver la pantalla de bienvenida por default que Symfony le pone a todos sus proyectos.

En:

http://localhost:8080/frontend_dev.php/

se accede a la misma aplicación pero en la versión de desarrollo. Podrán notarse (si se configuró correctamente el VirtualHost), que aparecen en la parte superior derecha los iconos para diversa información útil a un desarrollador.

Symfony tiene muchas características interesantes. Es un framework que puede dar mucho de sí mismo, sólo es cosa de ponerse a aprenderlo, en un proceso que de por sí no es complicado. Una buena guía se puede encontrar en el tutorial Jobeet, para aprender Symfony en 48 horas...

Nota: este tutorial, salió prácticamente intacto de lo que establece la guía Getting started del sitio de Symfony.

Instalar Trac para administrar proyectos

2009-12-30T13:55:00.000-08:00

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

Instalación rápida

Este modo de instalación requiere de Python (versiones 2.3 a 2.6) así como easy_install:

easy_install Trac

El cual instala Trac con SQLite y Genshi como framework de vista.

Requerimientos previos

Si se hace una instalación rápida, se instalaría Trac utilizando SQLite. En cuanto a este tipo de instalación, sólo es necesario tener instalado Python (versiones 2.3 a 2.6, la versión 3 aún no es soportada) y easy_install

Si se prefiere utilizar otro manejador de base de datos, entonces también es necesario tener los paquetes adecuados y los módulos para conectarse a los mismos con Python.

Igualmente, si se desea instalar el soporte con un repositorio SVN, es necesario tener instalado Subversion, así como los bindings SWIG para Python (ojo! PySVN no funciona para Trac).

Para publicar Trac en web, se necesita un servidor web. Puede ser cualquier servidor que soporte ya sea CGI, FastCGI o AJP, o en todo caso, Apache con el módulo mod_swgi o con mod_python (esta última es la opción con la que yo lo he llegado a instalar).

Instalación

Utilizando las setuptools, la instalación es sencilla:

easy_install http://svn.edgewall.org/repos/trac/tags/trac-0.11

Aunque también se puede hacer desde el directorio superior del código fuente:

python ./setup.py install

Configuración

Una vez instalado, hay que configurar dos cosas: el directorio en donde se almacenará la información del proyecto que se desea administrar, y el servidor web.

Para comenzar, se debe dar de alta el proyecto en donde quedará almacenado el sitio con la información del proyecto:

trac-admin /path/al/proyecto initenv

trac-admin pedirá información para inicializar el proyecto, como el path hacia el repositorio SVN (el cual es el tipo de repositorio por defecto), la conexión a la base de datos para usar (por defecto utiliza una base de datos con SQLite).

Para probar el repositorio, se puede levantar provisionalmente un servidor web integrado para ver que todo funcione correctamente:

tracd --port 8000 /path/to/myproject

Con lo que, accediendo en el navegador a http://localhost:8000/ se puede ir hacia todos los proyectos administrados por trac.

Configurando el servidor web
Trac se puede configurar para funcionar en modo CGI, mod_python de Apache, o FastCGI, e incluso en forma experimental en mod_wsgi de Apache. A continuación explico la forma de configurar con mod_python, que es la forma en que yo lo levanté en mi servidor...

1. Para empezar se debe asegurar que mod_python esté instalado en Apache. Una vez instalado, debe asegurarse de que Apache cargue el módulo mod_python al arrancar (cambiar el path a mod_python.so dependiendo la configuración de cada máquina):

LoadModule python_module modules/mod_python.so

Una forma de probar que mod_python esté correctamente configurado es agregar lo siguiente a la configuración de Apache (y que debe borrarse una vez hecha la prueba... es como el phpinfo() de PHP):

< Location /mpinfo >
   SetHandler mod_python
   PythonInterpreter main_interpreter
   PythonHandler mod_python.testhandler
< / Location >

Y acceder a http://localhost/mpinfo

2. La configuración básica de Apache para utilizar trac con mod_python es (cambiando la ubicación del proyecto trac y la url deseada según la máquina):

< Location /projects/myproject >
   SetHandler mod_python
   PythonInterpreter main_interpreter
   PythonHandler trac.web.modpython_frontend 
   PythonOption TracEnv /var/trac/myproject
   PythonOption TracUriRoot /projects/myproject
< / Location >

La opción TracUriRoot puede o no ser necesaria, deberá probarse con o sin ella...

Otras opciones:

    # Un solo proyecto
    PythonOption TracEnv /var/trac/myproject
    # Varios proyectos
    PythonOption TracEnvParentDir /var/trac/myprojects
    # Para un indice de multiples proyectos
    PythonOption TracEnvIndexTemplate /srv/www/htdocs/trac/project_list_template.html
    # Para obtener la fecha en el orden deseado
    PythonOption TracLocale en_GB.UTF8

Los eggs de Python (como los de Genshi) normalmente se descomprimen en un directorio en el cual Apache no puede escribir, esta opción se puede usar para apuntar a un directorio en el que Apache sí pueda escribir:

PythonOption PYTHON_EGG_CACHE /var/trac/myprojects/egg-cache

3. La autenticación es necesaria para configurar el acceso al area de administración de trac. En Apache:

< Location /projects/myproject/login >
  AuthType Basic
  AuthName "myproject"
  AuthUserFile /var/trac/myproject/.htpasswd
  Require valid-user
< / Location >

4. Más opciones, se pueden ver en http://trac.edgewall.org/wiki/TracModPython

Más configuraciones

Otras opciones y configuraciones se pueden configurar en trac.ini, el archivo de configuración que se encuentra en el directorio conf del proyecto. Por ejemplo, se puede definir un logotipo para el proyecto, entre otras cosas.

El resto consiste en utilizar trac para poder administrar los proyectos: editando el wiki, utilizando el administrador de issues, etc.

Toda esta información se encuentra de hecho en el sitio oficial del proyecto trac: http://trac.edgewall.org/wiki/TracInstall

40 años de UNIX

2009-11-26T20:00:00.000-08:00

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

2009-11-04T16:06:00.000-08:00

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

2. Configuración para cada lenguaje (Brushes):
Debes de incluir tantos "brushes" como vayas a necesitar. En este caso Java:

<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushJava.js' type='text/javascript'/>

mas brushes ... y la lista sigue creciendo

<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushJScript.js' type='text/javascript'/>
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushBash.js' type='text/javascript'/>
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushSql.js' type='text/javascript'/>
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushXml.js' type='text/javascript'/>
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushCss.js'
type='text/javascript'/>

3. Finalmente, activarlo.

<script type='text/javascript'>
SyntaxHighlighter.config.bloggerMode = true;
SyntaxHighlighter.all();
</script>

4. En tus publicaciones debes colocar tu código dentro del tag

Ejemplo: (tambien puedes usar como class: js, bash, shell, java, css, sql, ...)



<pre class="brush:xml; highlight:[3,7,8]">
<xml:mi codigo="aqui"/>
</pre>
El atributo class define el lenguaje y highlight las lineas que quierassobresaltar en tu código.Notas:Toma en cuenta que al estar apuntando a http://alexgorbatchev.com,  si este sitio se cae o no responde, puedes no ver tu código tan bonito como lo quieres.
Pero si tienes un sitio personal, puedes descargar los scripts y  usarlos sin el conveniente anterior.
Usa dentro de tu codigo, preferentemente &gt; y &lt;, en vez de > y <, respectivamente. 
Referencias:http://alexgorbatchev.com/

El Zen de Python

2009-10-19T17:13:00.000-07:00

    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

2009-09-27T20:26:00.000-07:00

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.

Requerimientos previos
Para poder usar TurboGears se necesita tener lo siguiente:

-Python a partir de la versión 2.4 (por ahora la versión 3 no es compatible)

-Las setuptools (peak.telecommunity.com/dist/ez_setup.py)

-Drivers adecuados para las bases de datos que se utilizarán. SQLAlchemy soporta gran número de controladores de BD, como SQLite, MySQL, PostgreSQL, etc. El lector deberá encargarse de instalar los drivers adecuados para Python según sus necesidades.

-Otras dependencias, por ejemplo los headers de Python que se pueden encontrar en las utilidades de instalación de la distribución Linux que se esté usando, o la win32API para Windows.

-Virtualenv, una utilidad que permite establecer un ambiente de desarrollo y producción local a cierto directorio, con el que TurboGears evita problemas de dependencias y demás. Se pueden usar las Setuptools para esto:

easy_install virtualenv

Instalación del ambiente
La manera más sencilla es utilizar el script que se encuentra en:

http://www.turbogears.org/2.0/downloads/current/tg2-bootstrap.py

Y después ejecutarlo con:

python tg2-bootstrap.py --no-site-packages tg2env

Donde tg2env es la ruta a un directorio previamente creado y en donde se almacenará el ambiente virtual de desarrollo y/o producción.

Para continuar, antes debe activarse el ambiente virtual. En tg2env (o cualquier nombre que se le haya dado) se encuentra el script bin/activate (o activate.bat para Windows). Solo hay que ejecutarlo, directamente en Windows, o en Linux con:

source bin/activate

El prompt de la consola cambiará a algo como

(tg2env) $prompt_por_default_de_la_consola

Al terminar de trabajar con TurboGears se debe desactivar el ambiente con

deactivate

En Windows debe ejecutarse bin/deactivate.bat

Instalación de TurboGears
Con virtualenv activado, sólo queda instalar TurboGears:

easy_install -i http://www.turbogears.org/2.0/downloads/current/index tg.devtools

La manera de probar que todo esté bien es ejecutando el script paster; Paste es un programa Python que permite publicar un servidor HTTP ligero y que TurboGears adapta y utiliza para varias tareas (aunque, claro está, habrá que investigar todavía la manera de publicar en otro servidor web, como Apache con mod_python):

paster --help

debe mostrar la ayuda del script, y con la misma al final un par de comandos nuevos para TurboGears.

Creación de un nuevo proyecto
Utilizando paster, se puede crear y configurar un proyecto de TurboGears de manera sencilla y rápida:

paster quickstart

A dicho script habrá que proporcionarle el nombre común del proyecto, el nombre Python del mismo y si se desea activar autenticación. Con eso basta para crear el proyecto en el directorio tg2env/nombre_comun_del_proyecto

Se debe ejecutar entonces:

cd tg2env/nombre_comun

python setup.py develop

Se puede editar el archivo nombre_comun/nombre_python/websetup.py para editar datos iniciales de la BD, como de la autenticación.

Si se hace ésto o si se activó la autenticación aún sin haberla editado, hay que ejecutar:

paster setup-app development.ini

El archivo development.ini contiene las configuraciones del proyecto, por ejemplo:

-el puerto en que se publicará la aplicación (por defecto el 8080)
-la dirección IP a la que se publicará (por defecto localhost, si se coloca 0.0.0.0 se publicará a toda la red)
-la conexión a la base de datos (por defecto un archivo de SQLite)

Para deployar el proyecto hay que ejecutar:

paster serve development.ini

Con paster serve se pueden usar también otros parámetros, por ejemplo:

--reload para que el servidor detecte automáticamente cambios en los archivos del proyecto

--daemon para ejecutar el servidor como demonio en segundo plano (por defecto en el archivo paster.log se almacenará el registro que vaya pintando el servidor conforme se utilice)

--stop-daemon para detener el servidor si está activo en segundo plano

--status da el estado del servidor en caso de estar en segundo plano

--help da la ayuda completa del script

Más información
El sitio de TurboGears contiene documentación, tutoriales y mucha más información.

Los sitios particulares de cada plataforma en que se basa TurboGears también serán esenciales para una completa documentación (Python, SQLAlchemy, Genshi, Pylons).

El sitio de PythonPaste también será útil.

Como siempre, Google es un buen compañero, o el buscador de preferencia en todo caso.

---
Javier Novoa C.
http://invernalia.homelinux.net
(Posted using BlogPress from my iPodTouch)

Levantando una sencilla VPN con OpenVPN parte 3

2009-09-22T15:36:00.001-07:00

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:

Se genera el certificado (conocido también como 'llave pública'), así como las llaves privadas tanto para el servidor como para cada cliente.
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.

Si estás utilizando algun servidor estilo Unix, entonces ve al subdirectorio easy-rsa, que se
encuentra en donde esté instalado OpenVPN. Por ejemplo:

/usr/share/doc/packages/openvpn
Si estás utilizando Windows, el subdirectorio easy-rsa podría estar en:

\Program Files\OpenVPN\

El primer paso consistirá en inicializar los scripts (eliminando cualquier configuración previa que se tuviera antes):


init-config

Después, debe editarse el archivo vars (o vars.bat en Windows) para establecer los parámetros KEY_COUNTRY, KEY_PROVINCE, KEY_CITY, KEY_ORG y KEY_EMAIL (estos son parámetros propios de OpenSSL, se puede averiguar más sobre ellos googleando un poco sobre este software).

En seguida, se debe inicializar la infraestructura de llaves públicas, ejecutando los siguientes scripts:


vars
clean-all
build-ca
El último de dichos scripts (build-ca), construye el certificate authority (CA) y la llave,
al invocar el comando openssl. Conforme lo solicite, debe introducirse a dicho script la
información necesaria para terminar de construir los archivos que se están generando.

Posteriormente, se generan el certificado y la llave privada del servidor:


build-key-server server
El Common Name a utilizar debería ser 'server'.

En seguida, se generan los certificados y llaves de cada cliente:


build-key cliente1
build-key cliente2
...
build-key clienteN
El Common Name sería 'clienteX', donde X es el número del cliente a configurar.

Por último se generan los parámetros Diff Hellman para el servidor OpenVPN:


build-dh

Y ya como paso final, de los archivos generados, hay que llevarlos a las computadoras adecuadas:

ca.crt - en el servidor y en todos los clientes
ca.key - para firmar más certificados (en donde quiera que se vaya a realizar esta operacion)
(keep secret!)
dh{n}.pem - en el servidor
server.crt - en el servidor
server.key - en el servidor (keep secret!)
clientX.crt - en el cliente X
clientX.key - en el cliente X (keep secret!)


Archivos de configuracion
De manera similar a los scripts que OpenVPN tiene para facilitar la configuración de la
infraestructura de llave pública, también se incluyen archivos de configuración de ejemplo,
para facilitar esta segunda, y última parte, de la configuración de la VPN.

En sistemas tipo Unix, estos pueden encontrarse, tal vez, en

/usr/share/doc/packages/openvpn
En Windows, puede buscarse en

\Program Files\OpenVPN\sample-config

server
En cuanto al servidor, lo esencial es configurar el número de puerto y protocolo a utilizar
(por defecto, se tiene el puerto UDP 1194)

Así mismo, debe especificarse la localización de los archivos

ca.crt, server.crt, server.key y dh.pem
Igualmente, debe configurarse el rango de direcciones IP que podran tomar los clientes de la
VPN, según el diseño previamente establecido

Puede establecerse que los clientes de la VPN puedan verse entre sí o solamente vean al
servidor, con la directiva client-client

clientes
Lo mismo que en el servidor, debe especificarse la ubicacion de los archivos

ca.crt, clientX.crt y clientX.key
En la directiva remote se establece la dirección IP del servidor, que será contactado para
unirse a la VPN

Debe verificarse que la configuración de cada cliente sea consistente con lo que se estableció
en el servidor. Por ejemplo, el protocolo y puerto deben ser el mismo


Arranque
Para arrancar la VPN, comenzando por el servidor, se ejecuta lo siguiente:

openvpn [localizacion del archivo de configuracion]
Si todo es correcto, ejecutando ifconfig (o el programa para averiguar las direcciones IP
disponibles que se tenga) se debe observar que existe una nueva dirección IP, correspondiente
a la VPN, para un dispositivo tun o tap (dependiendo cómo se hubiera configurado la VPN, el
más común es tun)

Una manera sencilla de probar la VPN es, una vez levantados el servidor y algun cliente, hacer
un ping entre ellos, con lo que ambas máquinas deben de verse:

ping IP_VPN
si algo saliera mal, primero hay que verificar que no haya problemas de firewall, con el puerto
y protocolo establecidos en la configuración, por ejemplo.


Arranque automático
En el caso de Linux, la distribución debería de haber dejado instalado el script
/etc/init.d/openvpn, el cual se encarga de buscar todos los archivos .conf que se
encuentrenen /etc/openvpn, por lo que hay que colocar ahí los archivos de configuración
recientemente editados, para que OpenVPN se inicie en automático correctamente.

En Windows, al instalar OpenVPN se debe configurar el software como un servicio.
OpenVPN buscará los archivos de configuración que se encuentren en
\Program Files\OpenVPN\config, para el inicio automático.


Resumen
En resumen, la instalación /configuración /arranque de OpenVPN consiste de:

Generar los archivos de certificados y llaves necesarios para servidor y clientes (se pueden utilizar los scripts que OpenVPN ya incluye), llevando cada archivo a su ubicación final según lo que se dijo anteriormente

Generar el archivo de configuración, ya sea para el servidor o el cliente, tomando en cuenta el tipo de VPN (tun o tap), la ip del servidor (en caso de configurar un cliente), el rango de ips que tendrán las máquinas pertenecientes a la VPN (en caso de configurar el servidor), el puerto y protocolo de comunicación (por defecto UDP 1194), la ubicación de los archivos de seguridad generados en el paso anterior, si se desea que haya comunicación entre clientes (en caso de configurar el servidor), y verificar la consistencia de las configuraciones entre los clientes y el servidor, además de cualquier otra cosa que se desee configurar en dichos archivos

Para un arranque automático, colocar los archivos de configuración en los directorios adecuados, dependiendo el sistema y la distribución del mismo (consultar los manuales y google para más información, en caso de que lo dicho aquí no sea genérico para todos los casos)

Al arrancar OpenVPN, validar esto mismo observando que existe una nueva dirección IP para la máquina en cuestión, y ésta dirección debe caer forzosamente en el rango establecido al configurar el servidor

Una vez con dos o más máquinas configuradas correctamente, validar esto mismo, observando que todas las máquinas pueden 'verse' entre sí (o sólo cada cliente con el servidor, dependiendo las configuraciones de este último) vía la dirección IP asignada para la VPN de cada una



Referencias
OpenVPN, como buen software open source, está muy bien documentado, tanto en la
instalación del propio software como en línea, en su sitio oficial (www.openvpn.net)

Precisamente en éste último sitio, se encuentra un HOWTO bastante completo, en el cual me
basé totalmente para generar esta pequeña serie de posts (y por si quedan dudas, también me
basé en el mismo tutorial para generar una VPN que utilizo yo mismo entre mi máquina que
funciona como servidor y las máquinas de mi trabajo, la de mi esposa, mi hermano y mi mamá,
para el caso de que les pueda proporcionar yo mismo ayuda vía remota desde donde quiera que
me encuentre).
Dicho HOWTO se puede leer en línea en:
http://www.openvpn.net/index.php/open-source/documentation/howto.html


Ver la parte 1
Ver la parte 2

Configurar la capa de servicios como transaccionales con spring aop

2009-09-18T15:56:00.000-07:00

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.

1.- Manejador de transacciones (TransactionManager)
Como nuestro manejador de transacciones requiere de una fuente de datos vamos a configurarla con un driver de mysql de la siguiente forma de momento pues no abundaremos en la configuracion del datasource:

<bean id="basicDataSource" class="org.apache.commons.dbcp.BasicDataSource">
<property name="driverClassName" value="com.mysql.jdbc.Driver"/>
<property name="url" value="jdbc:mysql://localhost/miBaseDatos"/>
<property name="username" value="user_sa"/>
<property name="password" value="mipass_sa"/>
</bean>

Luego necesitamos escoger una estrategia de transaccionalidad que implemente la interface de spring org.springframework.transaction.PlatformTransactionManager, y dado que usaremos MySQL en este caso, escogemos: DataSourceTransactionManager

<bean id="txManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
<property name="dataSource" ref="basicDataSource"/>
</bean>

2.- Advice
Lo que sigue es configurar el advice o la forma en que se va a manejar la transaccionalidad, para ello necesitamos agregar el esquema y el esquema location de transaccion a nuestro tag del archivo de configuración de contexto de Spring:

xmlns:tx="http://www.springframework.org/schema/tx"
xsi:schemaLocation="http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.5.xsd"

Luego necesitamos usar el esquema tx:advice para crear nuestro advice y hacer referencia a nuestro bean con el manejador de transacciones (txManager), indicamos con tx:attributes la semántica que define en qué métodos (tx:method) van a ser considerados para iniciar/propagar una transacción y configurar el tipo de transacción.

<tx:advice id="txAdvice" transaction-manager="txManager">
<tx:attributes>
<!-- todos los metodos que inicien con get van a ser de solo lectura -->
<tx:method name="get*" read-only="true"/>
<!-- todos los metodos que inicien con guardar van a ejecutar rollback si se lanza alguna error de estos tipos-->
<tx:method name="guardar*" rollback-for="java.sql.SQLException, x.y.MiInfraestructuraException"/>
<!-- cualquier otro metodo usara la configuracion por defecto de una transaccion-->
<tx:method name="*"/>
</tx:attributes>
</tx:advice>

Ojo: si tu bean manejador de transacciones ya se llama "transactionManager", puedes omitir la propiedad transaction-manager de tx:advice.

Es importante mencionar que por definición, Spring realiza rollback si encuentra que fue lanzada una Exception que herede de RuntimeException (osea no checadas) y las que listemos mediante la propiedad rollback-for. Esta propiedad nos ayuda a identificar las excepciones de negocio propias que deben provocar un rollback en la base de datos.

3.- Advisor y Pointcut
Finalmente vamos a asegurarnos que el comportamiento que acabamos de definir para nuestras transacciones sea ejecutado para cualquier operación definida mediante un aop:pointcut, para eso usamos un advisor. Agregamos el esquema y el esquema location de aop nuestro tag del archivo de configuración de contexto de Spring:

xmlns:aop="http://www.springframework.org/schema/aop"
xsi:schemaLocation="http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.5.xsd"

El aop:pointcut define con una expresión de aspectJ (execution) que el comportamiento transaccional sea ejecutado, para este caso, en todas las operaciones con un valor de retorno void y que reciban cualquier numero/tipo de argumentos, de nuestras clases que terminen en Service y se encuentren en el paquete x.y.service.

Con un aop:advisor simplemente relacionamos el pointcut con el advice previamente definido.

<aop:config>
<aop:pointcut id="operacionesDeServicios" expression="execution(* x.y.service.*Service.*(..))"/>
<aop:advisor advice-ref="txAdvice" pointcut-ref="operacionesDeServicios"/>
</aop:config>

Nota1:
La sintaxis para el comando AspectJ execution es como sigue. Puedes usar ' * ' para indicar "todos", o bien '..' (dos puntos seguidos) para indicar "este paquete o uno más interno", o bien, "más argumentos" si el caso del método:

execution([valorRetornoDelMetodo] [paquete].[clase].[nombreMetodo]([listaArgumentos]))

Ejemplo: Todos los métodos que empiecen con guardar que devuelvan void y reciban por lo menos un long que pertenezcan a las clases que terminen con Dao y sean del paquete x.y.daos o subpaquetes

execution (void x.y.daos..*Dao.guardar*(long..))

Para entender un poco mas sobre las expresiones de aspectJ ve la referencia de aop-aspectj.

Nota 2: Para no confundirnos con los esquemas, la definición del tag puede quedar como sigue:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:aop="http://www.springframework.org/schema/aop"
xmlns:tx="http://www.springframework.org/schema/tx"
xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.5.xsd
http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.5.xsd">
<!-- todos los demas beans que vimos-->
</beans>

Referencias:

Programacion orientada a aspectos con Spring (inglés)
Manejo de Transacciones (inglés)
Getting Started with AspectJ

Maven-Spring-Aspectos con @Configurable y Weaving

2009-09-09T07:15:00.001-07:00

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.

Cualquier bean que es anotado con @Configurable será inyectado con sus propiedades utilizando aspectos. Entonces necesitamos que las cosas estén preparadas para que este aspecto se ejecute.

Lo primero - el contexto de Spring.
Necesitas los siguiente en el contexto de tu aplicación:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:context="http://www.springframework.org/schema/context"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-2.5.xsd">

<context:component-scan base-package="tu.paquete.raiz"/>
<context:spring-configured/>
<!-- mas beans  ... -->
</beans>

Recuerda agregar el context namespace a la declaracion de esquemas en tu archivo de contexto.
Ahora la configuracion de Maven
Necesitarás usar aspectj-maven-plugin desde el proyecto codehaus MOJO.

<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>aspectj-maven-plugin</artifactId>
<configuration>
<complianceLevel>1.5</complianceLevel>
<aspectLibraries>
<aspectLibrary>
<groupId>org.springframework</groupId>
<artifactId>spring-aspects</artifactId>
</aspectLibrary>
</aspectLibraries>
</configuration>
<executions>
<execution>
<goals>
<goal>compile</goal>
</goals>
</execution>
</executions>
</plugin>

Estos jars de la lista de librerias de aspectos deberían contener aspectos pre-compilados (en este caso las de Spring) y estos aspectos serán enlazados en tiempo de compilación contra el tiempo de compilación del código.
Lo que sigue esta traducido del documento original pero ya no existen los enlaces:

Hay un ejemplo disponible en mercurial

hg clone https://svn.chrissearle.net/mercurial/examples

Luego mira en el aspectj/directorio ctw.
Si no tienes mercurial entonces puedes navegar en : https://svn.chrissearle.net/mercurial/examples/file/tip/aspectj/ctw/
Traducido de: chrissearle.org jueves 22 de Mayo 2008 por chris
Más referencias:

Levantando una sencilla VPN con OpenVPN parte 2

2009-08-14T15:20:00.000-07:00

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.
De hecho, cualquiera que tenga una computadora dentro de una red privada (incluso en el hogar), podrá observar que la dirección IP que por lo común se le asigna cae en estos rangos:

Dir. inicial--------Dir. final----------CIDR
..10.0.0.0......10.255.255.255.....10.0.0.0/8
.172.16.0.0....172.31.255.255.....172.16.0.0/12
.192.168.0.0..192.168.255.255...192.168.0.0/16

La otra consideración importante a tomar en cuenta al momento de elegir las direcciones IP que se les asignará a las máquinas que pertenezcan a la red virtual viene del hecho de asegurar que para ninguna de las máquinas se producirán choques o conflictos, debido a que la dirección IP que se le asigne a cierta máquina, coincida con la dirección IP de alguna otra máquina dentro de alguna otra red a la que pertenezca o que la subred a la que pertenezca genere este mismo conflicto. Es decir, y por ejemplo:

supongamos que una máquina (que llamaremos A) que pertenecerá a la VPN quedará con dirección IP asignada de 192.168.1.10 (y otras máquinas de la VPN podrían quedar con IPs similares: B tendría IP 192.168.1.70, C tendría IP 192.168.1.43, etc.). Sin embargo, el problema vendría si A pertenece a su vez a una LAN en donde el rango de direcciones válidas queda dentro de la subred 192.168.1/24 (es decir, de 192.168.1.0 a 192.168.1.255). ¿Qué provocará esto? Por un lado, podría provocar que la dirección 192.168.1.10 ya estuviera asignada a alguna otra máquina de la LAN a la que pertenece nuestra desdichada máquina A. Pero peor aún, provocará que el sistema de ruteo y redireccionamiento de la LAN piense que todo el tráfico generado por y para 192.168.1.10 deberá quedarse dentro de la LAN misma, y no que pertenezca a una red diferente.

¿Qué hacer en estos casos? Bueno, la mejor solución es planear por adelantado. ¿Qué rangos posibles de subred van a tener las máquinas que pertenecerán a la VPN? Sabiendo esto, entonces habrá que tomar la decisión de diseño, de que la dirección de subred de toda la VPN quede en un rango que no ocasione ningún conflicto para nadie.

De acuerdo al ejemplo anterior, si se eligiera que la VPN quedara con direcciones dentro de la subred 192.168.20/24, con esto el problema para nuestra máquina conflictiva se vería resuelto: ahora A tendría dos direcciones IP: una dentro de la subred 192.168.20/24 (la de la VPN) y otra dentro de la subred 192.168.1/24 (la de la LAN a la que pertenece).

Servicios y puertos
El siguiente punto a considerar es que OpenVPN debe estar ejecutándose en la máquina que pertenecerá a la red (obviamente, por supuesto). La mejor opción es que se ejecute como un servicio que se levante por sí solo cada vez que se reinicie la máquina, de esta forma nos evitamos el tener que levantarlo nosotros mismos cada vez que recordemos que debemos pertenecer a la red virtual (o que alguien nos lo recuerde).

Además, al tratarse del servidor hay que definir el puerto sobre el que se conectarán las demás máquinas para establecer la VPN. Por lo general, ya que es la opción por defecto, se utiliza el puerto UDP 1194. Sin embargo, esto no es una regla, sino una recomendación. Se puede elegir otro número de puerto (desocupado por supuesto), y si se desea incluso, también otro protocolo de conexión, es decir en lugar de UDP se puede elegir TCP. (¡y no hay que olvidar abrir dicho puerto en el firewall del servidor una vez que se tenga todo listo para comenzar!)

Generación de llaves
Puesto que OpenVPN genera una VPN segura, se necesita alguna manera de garantizar dicha seguridad. Hay que tomar en cuenta que la información que se transmita entre las máquinas de la red virtual va a viajar através de internet y de máquinas desconocidas en lugares que podrían resultar muy variados. Esto conlleva un riesgo de seguridad: cualquiera con tiempo, ganas y habilidad podría interceptar la comunicación entre dos máquinas de la red que, de otra manera, se supone deberían ser datos privados, como en una LAN cualquiera.

Para garantizar la seguridad de la comunicación entre las máquinas de la red virtual se utiliza encriptación de llave pública, un método de encriptación de la información que, además de resultar muy popular hoy en día, resulta de los más seguros también (no hay que olvidar que, según la sabia filosofía del código abierto y el software libre, un protocolo entre más abierto y conocido sea por todos, más seguro es). En palabras breves, la encriptación de llave pública consiste en lo siguiente:

Supongamos que dos máquinas se quieren comunicar seguramente. En un lado de la comunicación se encripta la información a enviar utilizando algo llamado su llave privada, y de esa manera la información viaja por internet. Algo encriptado con llave privada es dificilísimo, sino es que imposible, de desencriptar en un tiempo que puede llegar a las décadas o más (incluso para las máquinas más potentes). Esto genera un pequeño problema: ¿cómo desencriptar la información rápidamente en el lado receptor? Una solución es utilizar la misma llave privada, pero esto ocasiona el problema de que ambas partes deben conocer dicha llave privada, y para que ambas conozcan la llave privada, entonces de alguna manera un lado debe hacer del conocimiento del otro lado dicha llave privada. Y como sea que lo veamos, esta transmisión de la llave privada puede ser igualmente insegura.

De esta forma, los algoritmos de llave pública implican que, en lugar de encriptar la información del transmisor con su llave privada, se encripte con la llave pública, una llave que puede ser conocida por quien sea, podría incluso transmitirse por TV o publicarse en un blog como estos, pero la forma de desencriptar la información, sólo se logra si el receptor cuenta con una llave privada generada de manera adecuada. Esta manera adecuada de obtener la llave privada correcta es a través de un certificado de seguridad. Y bueno, aún contando con la llave pública, las máquinas más potentes todavía tardarían décadas o más que eso en desencriptar la información, pues no cuentan con las llaves privadas adecuadas.

La manera de implementar todo esto en OpenVPN es utilizando SSL. Obviamente, se pueden conseguir (a un precio no tan accesible) los certificados de seguridad generados por compañías especializadas, pero si no se tienen los medios, en una instalación estándar de OpenVPN, se incluyen también algunos scripts hechos precisamente para permitir la generación de llaves privadas y certificados de seguridad para el servidor y las máquinas cliente que formarán parte de la red virtual, a través de SSL.

Ver la parte 1
Ver la parte 3

Levantando una sencilla VPN con OpenVPN

2009-08-06T16:04:00.000-07:00

¿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.

¿Qué necesito?

Una máquina que funcione como 'servidor' de la VPN (puedes consultar mi tutorial sobre cómo levantar un servidor desde Linux en 3 pasos) [NOTA: no es necesario que el servidor sea Linux]
Máquinas que pertenecerán a la VPN, los llamados 'clientes'
Software para levantar la VPN. En este caso utilizaremos openVPN
Obviamente, conexiones a internet. Solamente el servidor necesita ser 'visto' por las demás máquinas, mientras que para los clientes, basta con que puedan acceder a internet, aunque no sean 'vistos' por los demás (pues pueden estar detrás de un router que les asigne una IP vía NAT por ejemplo)
Configurar openVPN tanto en el servidor como en los clientes

Para los puntos 1, 2 y 4, voy a asumir que ya tienes lista esa parte, y me enfocaré únicamente en los puntos 3 y 5.

OpenVPN
OpenVPN es una plataforma que permite configurar redes a nivel amplio, sin necesidad de invertir en las instalaciones que una WAN (Wide Area Network) utilizaría. Al contrario, aprovechando la infraestructura que ya existe de Internet (la red de redes), se configura de manera segura y estable una red de 'area amplia'.

OpenVPN puede obtenerse en su sitio oficial, openvpn.net. Existen versiones para distintos sistemas operativos, entre ellos Linux y Windows. Hablando de Linux, cabe mencionar que numerosas distribuciones lo incluyen también dentro de sus repositorios, por lo que puede instalarse también a través de las utilidades de la propia distribución.

En cuanto a Linux, si se decide instalar OpenVPN sin usar las utilidades de instalacion de la distribución, se puede instalar utilizando RPM (para distribuciones que lo soporten, como RedHat, Fedora, Suse, etc.), o por otro lado se puede instalar compilando el código fuente. Igualmente, para sistemas estilo Debian, existen repositorios que permiten instalar OpenVPN vía apt. En Windows, un instalador se encarga del proceso.

Cabe mencionar que, para que una máquina pueda funcionar como servidor de una red con OpenVPN, debe abrirse el firewall. Por defecto se utiliza el puerto UDP 1194, pero también se puede configurar algún otro (otro número o incluso TCP en lugar de UDP).

Ver la parte 2
Ver la parte 3

ORM : Mapeo Objeto - Relacional

2009-08-03T10:09:00.000-07:00

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:

Las personas, con datos como su nombre completo, edad, género
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)
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:

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.
Un objeto telefono, con una propiedad cadena para el número telefónico.
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:

Una propiedad lista de objetos telefono
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

2009-08-03T08:13:00.001-07:00

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

2009-07-23T11:16:00.001-07:00

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

Para mayor apoyo sobre el uso del EAF, se puede utilizar la ayuda de Eclipse (y sino, la ayuda en línea), ahí vienen descritos muchos comandos que se pueden usar en un form behavior (fb), pero describo algunos:

LJF("pantalla") - permite cargar una pantalla, como parámetro se envía el nombre del archivo .js sin la extensión y después se llama a su constructor de la misma forma, en este ejemplo sería: pantalla();

Otra lista de comandos

SE - Source Element
AE - Attach Element
PX - Prefix
CN - Class Name
SAO - Select Add Option
GOT - Got Option Text
SI - Select Index - selecciona un índice del arreglo.
PM - Te ayuda a redireccionarte a una url.
WSM - Para abrir otra pantalla
GI - Get element by Id - Devuelve la referencia por el id
WO - Para acceer a objetos (widget) de la ventana padre

Puedes ayudarte del plugin Firebug si usas Firefox o de la funcionalidad 'inspect element' de chrome para navegar por los objetos y elementos html. En firebug, puedes usar la consola para ejecutar comandos como:

console.log(x) - para sacar una traza del valor de x
eval(x) - sacar el resultado de interpretar x
JKB.widget.manager.getWidget("id") - devuelve un objeto
for (var x in objeto) { console.log(x) } - para mostrar los elementos de un objeto

Algunas notas aclaratorias:

Diferencias entre <div> y <span> , si no se indican posiciones, div es relativo vertical, span es relativo horizontal.
En estilos CSS, se usa '.estilo1' para cuando se asigna de la forma: class="", ej. <div class="estilo1"/>; y '#estilo2' se usa cuando se asigna como id="", ej. <div id="estilo2"/>
WSDL - Describe los servicios web.
SOAP - Protocolo que usan los servicios web, nada que ver con SOA .
Web clipping - Permite extraer la información no estructurada y transformarla en datos estructurados

Otras referencias:
Conceptos varios | Servidor Presto | Conectores Mashup | Demostraciones
Mejores Practicas con AJAX (PDF en inglés)
The Business Value of AJAX (PDF)

Metodología de desarrollo XP

2009-07-21T08:22:00.001-07:00

Ciclo de la metodología

Planificación. Escuchar las necesidades del Cliente, hacerlo parte del equipo, pero explicar lo que es fácil de obtener y lo que no
Diseño. Es importante usar patrones de diseño.
Desarrollo. Hacer que el propio código comunique lo que está haciendo.
Pruebas. Realizar pruebas unitarias, puedes usar frameworks muy conocidos como JUnit y DBUnit.

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

2009-07-14T13:03:00.000-07:00

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:

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.
Configurar y levantar el servidor. Después hay que configurar la máquina que será el servidor. Por un lado se deben de instalar y configurar los servicios que se desean ofrecer: HTTP (web), FTP (servidor de archivos), SSH (conexión remota), SVN (versionador), etc. Por otro lado, también hay que configurar el servidor para que los puertos con los que se comunicará el servidor con el mundo exterior queden abiertos. Esto implica que esos puertos del servidor, y no otros, sean visibles en el exterior, lo que significa configurar la seguridad del servidor a través de un firewall.
Recordar mi dirección IP. Aunque con los dos primeros pasos ya se puede tener un servidor conectado a Internet, hay que tomar en cuenta dos factores: que un número de dirección IP es difícil de recordar (ya sea por ti, o por las personas a las que les informes de tu servidor, o a cualquier persona que, navegando por internet, se tope con el mismo y utilice los servicios que ofrezca), y que posiblemente tengas contratado un servicio de internet con asignación dinámica de IP (lo cual significa que en algún momento (como cuando se va la energía eléctrica) tu servidor cambiará de dirección IP, y esto vuelve complicado el proceso de conocer a qué dirección conectarse en realidad: si al dejar tu casa olvidas consultar cual es la dirección IP actual de tu servidor, acceder a él será en la práctica algo imposible, a pesar de que se encuentre visible al exterior en todo momento). Hay varias maneras de resolver esto. Una, si cuentas con los medios económicos adecuados, contrata un servicio de internet que te permita además tener una dirección IP fija. Pero el caso es que no siempre se puede tener esto, además aún queda el problema de que el número de dirección IP es difícil de recordar. Presentaré aquí una opción que puede resultar conveniente y barata a través de un servicio de DNS dinámico.

Por último, antes de describir cómo llevar a cabo estos 3 pasos, vale la pena mencionar unos cuantos programas de utilidad que conviene tengas instalados y conozcas su uso. Casi todos se pueden ejecutar desde una consola cualquiera en Linux, aunque algunos requieren permisos de superusuario (que dicho está de más, es el modo con el que se necesitan instalar y configurar los servicios que el servidor ofrecerá). Para los que ya los conocen, pueden saltarse libremente esta sección. Nota: estos programas también tienen sus equivalentes para otras plataformas, si vas a utilizarlos para monitorear tu servidor desde el exterior, investiga dichas equivalencias para el sistema desde el cual te vayas a conectar a tu servidor.

-ifconfig, informa de la dirección IP y otra información útil de la máquina actual, dando información para cada interfaz de conexión de red que tenga el sistema. Por ejemplo, se da información para la interfaz Ethernet, la Wireless, etc. Su uso más sencillo es:

ifconfig

-ping, permite 'llamar' a cierta dirección IP o servidor para saber si está respondiendo. Su uso más sencillo es:

ping dirIP

ping nombreSevidor

Cuando se tenga suficiente, se puede presionar Ctrl-C y ping informa de la estadística que se haya obtenido al comunicarse con cierto servidor.

-traceroute, permite conocer la ruta que siguen los paquetes de información para llegar desde la localidad en que es invocado hasta el servidor solicitado. Su uso más común es:

traceroute dirIP

traceroute nombreServidor

El resultado es una serie de ruteadores por los que la información viaja desde la localidad en que fue invocado hasta la máquina especificada.

-nmap, que puede conseguirse en este sitio, permite conocer los detalles de algún servidor. Su uso más sencillo es:

nmap dirIP

nmap nombreServidor

El resultado es una lista de los nombres y números de puertos abiertos en el sistema indicado. También son de uso común los parámetros -O y -A.

-tcpdump, te muestra en tiempo real el contenido de los paquetes de información en una interfaz de red. Su uso más sencillo es:

tcpdump

El resultado es el volcado en tiempo real de todos los paquetes de comunicación que lleguen a la interfaz de red por defecto en el sistema. Cuando tengas suficiente presiona Ctrl-C.

Introduccion...
Al paso 1...
Al paso 2...
Al paso 3...

Servidor Linux desde tu hogar Paso 3

2009-07-13T20:55:00.000-07:00

Recordando la localización de mi servidor

Y otra vez los tres incisos:

conseguir el servicio de DNS
configurar el servidor
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.

Esto se logra de manera sencilla y barata registrándose con servicios gratuitos de DNS dinámico. Por ejemplo dyndns.com, no-ip.com, etc.

En un sitio como estos deberás dar de alta la dirección IP actual y relacionarla con el dominio DNS que desees. Si el servicio es gratuito, por lo general tu domino quedará con un 'apellido' proporcionado por el servicio. Si esto te importa y deseas tener tu dominio completamente personal, deberás buscar un servicio de DNS al cual pagarle una cuota. Si deseas un domino .mx, .es, o de cualquier otra localidad, el servicio de DNS debería de ser proporcionado en el país elegido.

Configurar el servidor
Además de esto, tu servidor debe de ejecutar algún script de inicio para que cada vez que se encienda el servidor se contacte con el servidor DNS dinámico y se asocie el nombre de tu dominio con la dirección IP que tenga tu servidor actualmente, para el caso en que haya cambiado. Por lo general, los sitios de servicios de DNS dinámico te dan instrucciones para poder levantar dicho script de inicio.

Pruebas
A estas alturas las pruebas ya son muy sencillas. Las puedes hacer incluso desde dentro de tu servidor o tu LAN, o desde fuera. Elige alguna aplicación o servicio que esté dado de alta en el servidor e intenta conectarte a él con el número de puerto correcto, pero en vez de utilizar el número de dirección IP, utiliza el nombre del dominio que hayas registrado.

Por ejemplo, con un navegador web, intenta la URL: http://miDominio.posible_apellidoDNS.com_o_net_o_org_o_loquesea y deberás de poder ver la página web de inicio que tengas configurada en tu servidor...

Otra prueba importante es la del cambio de dirección IP, en caso de que, como yo, tengas asignación de dirección IP dinámica por parte de tu ISP. Una manera sencilla puede consistir en desconectar de la corriente eléctrica tu ruteador y esperar un rato, luego reconectar (con la esperanza de que así se renueve la dirección IP y cambie a otra), reiniciar el servidor (me parece que en este caso no hay más que hacer, debe re-ligarse el servidor con la nueva dirección IP, aunque quien sabe, tal vez haya forma de hacerlo sin reinicio... además debe ejecutarse el script de inicio para remapear la nueva dirección IP con el dominio que tengas, cosa que no necesariamente implica un reincio, se podría ejecutar manualmente) y luego volver a hacer la prueba con el nombre de dominio...

Apéndice

Hay muchas otras cosas que se pueden hacer aún para mejorar la configuración y desempeño del servidor. Afinar un servidor para su funcionamiento eficiente es también parte del trabajo que hace un buen administrador de sistemas. Además de lo que se pueda hacer dentro del servidor, se pueden hacer algunas otras cosas para mejorar el servicio de internet mismo que recibe el servidor, como ahorrar un poco y contratar un servicio más rápido, o una dirección IP fija. Una buena inversión puede ser la de protejer tu servidor, y tu ruteador dicho sea de paso, con un no-break / regulador. Además de la protección contra picos de corriente, el hecho de que tu servidor se mantenga más tiempo encendido puede motivarte. Y además, si tu ruteador no se apaga por fallos de corriente, probablemente los cambios de dirección IP te afecten menos...

Internet es, en mi opinión, uno de los sistemas más interesantes que existen en el mundo. La forma en que funciona, su capacidad de auto-organizarse, las características de sus protocolos, etc. Levantar un servidor en Internet es apenas un pequeño pedazo de la complejidad interesante que compone a la red de redes, y al haber levantado un servidor, al mismo tiempo se abre la puerta a muchas otras características interesantes que se pueden conocer de lo que es Internet.

Para conocer más, de servidores en particular y de Internet en general, existen muchos recursos, libros y sitios en la red, que se pueden consultar.

Este link es una introducción breve (en inglés) al funcionamiento general de Internet.

Los protocolos y toda la definición de internet se lleva a cabo a través de documentos llamados RFCs (Request For Comments), que administra la IETF (Internet Engineering Task Force), el organismo que tradicionalmente heredó la administración y definición de Internet desde su creación.

Por ejemplo, el protocolo IP se define en el RFC 791. El TCP en el RFC 793. HTTP en el RFC 2616. SMTP (email) en el RFC 822, etc.

Para conocer de protocolos también se puede hacer uso de software que permite observar la comunicación de la red en acción, ya mencioné tcpdump, pero existen otros programas de entorno más amigable, como Wireshark, entre otros.

Introduccion...
Intro-2...
Al paso 1...
Al paso 2...

Servidor Linux desde tu hogar Paso 2

2009-07-13T20:54:00.000-07:00

Levantado mi servidor

De nuevo, este paso se realiza en tres incisos:

configurar el firewall, para la seguridad
instalar, configurar y levantar los servicios en sí mismos
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.

Por otro lado, también debes seleccionar la interfaz de red que quedará protegida por el firewall. Por un lado es recomendable que actives para todas las interfaces, pero por otro también recuerda que sólo una de las interfaces quedará configurada con el port-forwarding desde el ruteador, por lo que ésta es la más importante a configurar. Las demás, son lo de menos pues el mismo ruteador implementa seguridad de firewall para los otros dispositivos ;)

Por último, debes habilitar los servicios a ser permitidos. Esto no significa que los servicios ya quedarán configurados, solamente se abrirán los puertos especificados para que los servicios funcionen. El listado de puertos debe configurarse para que sean vistos hacia el exterior, de lo contrario no serán vistos desde fuera. Dicho listado puede incluir cuantos servicios quieras levantar en el servidor. Los más comunes son HTTP (puerto 80), FTP (puerto 21), SSH (puerto 22), Telnet (puerto 23), SMTP (puerto 25) y cualquier otro puerto de aplicaciones particulares como MySQL (puerto 3306), PostgreSQL (puerto 5432), SubVersion (puerto 3690), algún servidor de aplicaciones como Tomcat (puerto 8080), etc. Obviamente, si al momento de levantar un servicio (lo que cubriré a continuación), eliges utilizar un puerto diferente al estándar, entonces dicho puerto es el que debes abrir en el firewall, en lugar del que comúnmente se utilizaría, y debes recordar conectarte al servidor en ese puerto específico para usar dicho servicio, de lo contrario puedes estar intentando conectarte al puerto por defecto y asumir que no hay conexión o que el servidor no funciona correctamente.

Los servicios
A continuación, debes levantar los servicios a utilizar. Igualmente, puedes hacerlo 'a mano', o utilizando las utilidades de configuración que vengan con la distribución Linux que estés utilizando. Sin enfocarme en una u otra opción, ni en ningún servicio en particular, básicamente tienes que instalar y configurar la aplicación que proporcione dicho servicio en el sistema.

Por ejemplo, para un servidor HTTP, puedes instalar el popular Apache. Para un servidor FTP, puedes utilizar VSFTP. Para SSH, el más común es OpenSSH. Para aplicaciones particulares, como servidores de bases de datos, versionadores o aplicaciones, cada aplicación la debes instalar y configurar correctamente (sin olvidar abrir los puertos necesarios en el firewall del servidor cada vez que hagas esto).

Hecho esto, ahora sí solamente te queda probar...
Supongamos que instalaste Apache en tu servidor (o cualquier otro servidor web). En un navegador web dentro del mismo servidor puedes introducir en la URL lo siguiente: http://localhost/, con lo que no estarás utilizando el port-forwarding. Si por otro lado introduces http://midireccionip/ y obtienes el mismo resultado que con localhost, entonces las cosas van funcionando bien. Si haces la prueba de http://midireccionip/ desde otra máquina de la LAN, debes obtener el mismo resultado. Pero la prueba más interesante, y la más efectiva, es realizar la prueba desde el exterior. Te puedes ir a un cibercafé cercano, o probar desde otro lugar con acceso a internet, o que alguien más prueba mientras te informa del resultado. Asegúrate, claro está, de tener tu servidor encendido y conectado a internet, y de recordar ese feo numerito: midireccionIP ;)

Las mismas pruebas las puedes hacer para servicios distintos a un servidor HTTP:

con FTP conéctate e intenta bajar/subir archivos (dependiendo la forma en que hubieras configurado el servico)
con SSH, intenta conectarte y entrar a sesión en el servidor de forma remota
con SVN, levanta un repositorio en el servidor y luego trata de acceder a él (haciendo un checkout y luego checkins a cambios hechos) desde el exterior
con MySQL, con un cliente de dicha base de datos en el exterior, intenta conectarte al servidor levantado
en fin, las prueba dependerá de la aplicación y servicio instalados

Además, si es posible que tengas acceso fuera de la LAN a los programas de utilidad que mencioné al principio, puedes hacer un ping al servidor nuevo, para ver si responde, un traceroute para ubicar la ruta para llegar a el, y un nmap para conocer qué puertos tiene abiertos tu servidor. Por otro lado, de regreso al servidor, las aplicaciones levantadas suelen dejar un log que será conveniente que siempre revises y monitorees, para observar cómo ha sido el desempeño y el uso que se ha hecho de tu servidor desde el exterior.

Para terminar este paso, una pequeña nota: para los que son observadores, podrán haber notado que este segundo paso (levantar el servidor), es de alguna manera independiente al paso 1 (publicar la dirección IP). ¿Qué se logra si se realiza este paso 2, sin haber realizado el paso 1?... ¿Aún no? Bueno, pues se logra tener servicios levantados, pero exclusivamente para la LAN en que se encuentre el servidor. Es decir, todas las demás máquinas de la LAN podrán usar los servicios del servidor, a manera de una intranet. Es cuando se publica la dirección IP que se consigue tener el servidor a nivel externo de la LAN.

Introduccion...
Intro-2...
Al paso 1...
Al paso 3...