Para poder incluir un reporte realizado con JasperReports en nuestra aplicación Jruby necesitamos:

1) Descargar I-Report, la herramienta de administracion de reportes de JasperReports. http://jasperforge.org/projects/ireport y descomprimirlo.

2) Dentro del directorio del i-report, ir a modules/ext/ y copiar todos los archivos .jar (si, todos ) al directorio lib de la instalación de JRuby. De esta manera, ya incluimos las librerías necesarias y tenemos preparado nuestro JRuby para utilizar JasperReports.

3) Nos resta crear un reporte para prueba, si nunca hiciste un reporte con i-report: http://jasperforge.org//website/ireportwebsite/IR%20Website/ir_design_a_report.html?header=project&target=ireport

4) Finalmente el código para correr nuestro reporte es el siguiente:

require 'java'
import 'oracle.jdbc.OracleDriver' #Aqui necesitas Utilizar el Driver de la Base de datos que estas usando, en mi caso es oracle
import 'net.sf.jasperreports.engine.JasperCompileManager'
import 'org.apache.commons.dbcp.BasicDataSource'
import'java.util.HashMap'
import'net.sf.jasperreports.engine.JasperFillManager'
import'net.sf.jasperreports.engine.JasperExportManager'                                                                             

#Creo el datasource
basicdatasource = BasicDataSource.new
basicdatasource.driver_class_name = 'oracle.jdbc.OracleDriver'
basicdatasource.username = 'usuario'
basicdatasource.password = 'password'
basicdatasource.url = 'jdbc:oracle:thin:@localhost:1521:XE'
basicdatasource.connection
conexion = basicdatasource.connection

#Compilamos el reporte
jasperReport = JasperCompileManager.compile_report('/url_de_tu_archivo_jrxml/reporte.jrxml')
#Para pasar los parámetros, definimos un objeto HashMap
m = HashMap.new
m.put('parametro_1','valor_parametro_1')
m.put('parametro_2','valor_parametro_2')
m.put('parametro_n','valor_parametro_n')

#Genero el reporte
jasperPrint = JasperFillManager.fill_report(jasperReport, m,conexion)                           

#Exporto el PDF
JasperExportManager.export_report_to_pdf_file(jasperprint, 'path_al_archivo_PDF.pdf')

Si deseamos generar reportes en Rails, podemos por ejemplo ubicar los reportes en el directorio public/reportes y utilizar send_file para enviarlos, por ejemplo:

JasperExportManager.export_report_to_pdf_file(jasperprint, RAILS_ROOT+"/public/reportes/reporte.pdf")
send_file RAILS_ROOT+"/public/reportes/reporte.pdf"

Espero les sea de utilidad, cualquier cosa comenten y trataré de despejar dudas

Para ir preparándonos y estar al tanto de todas estas mejoras, habilitaron en la wiki de PostgreSQL una sección especial donde se explican estos cambios con sus correspondientes ejemplos.

Entre los cambios más importantes tenemos la incorporación de características como:

• Hot Standby: Esta característica nos permite crear una base de datos ‘Standby’. Esto es una segunda instancia de la base de datos: normalmente en un servidor separado a partir del log binario de la primera base de datos, permientiendo que el servidor standby esté disponible para consultas de sólo lectura.
• Streaming Replication: Es un complemento de Hot Standby. Si bien existen varias soluciones de replicación de terceros disponibles para PostgreSQL, ésta nueva versión trae una simple e integrada versión que probablemente será usada como default en la mayoría de las soluciones de High Availability de PostgreSQL.

Más info de las características nuevas y ejemplos en What’s new in PostgreSQL 9.0

• Cortar segmentos de la red.
• Comprar software costosos.
• Incorporar Hardware tipo cazafantasmas con luces psicodélicas.
• Enviar memos y reprimir a los empleados que no son de sistemas, que no tienen la mas mínima idea de lo que es una dirección de IP.

Si en nuestra red tenemos una pc con linux esto es muy sencillo de resolver, el paquete se llama: arping.

Pasos para utilizarlo:

1) Instalación

sudo apt-get install arping

2) Uso

sudo arping -I eth0  192.168.0.1
 
ARPING 192.168.0.1
60 bytes from 00:26:55:36:ec:a1 (192.168.0.1): index=0 time=74.863 usec
60 bytes from 00:1a:92:4e:4c:9e (192.168.0.1): index=1 time=160.933 usec

Como se puede observar  el problema aquí es una IP duplicada asociada a dispositivos de red diferentes (placa de red, switch, router).

Su utilidad principal es hacer ping a direcciones mac, por ejemplo:

sudo arping -I eth0  00:26:55:2e:95:EE
 
ARPING 00:26:55:2e:95:EE
98 bytes from 192.168.0.1 (00:26:55:2e:95:EE): icmp_seq=2738 time=771.392 msec
98 bytes from 192.168.0.1 (00:26:55:2e:95:EE): icmp_seq=2740 time=770.830 msec

Esto ultimo resulta interesante de utilizarlo en redes WIFI. Entonces, de manera muy sencilla y sin costos adicionales resolvimos un problema  con Linux, espero les sea útil esta información.

Para aquellos desarrolladores que utilizan el IDE Eclipse y el sistema de control de versiones git les va a interesar esta info: org.eclipse hizo pública la primera versión del plug-in EGit que proporciona soporte integrado para el SCM distribuído git, utilizando JGit.
JGit es una biblioteca que implementa Git en Java. EGit, a diferencia de Eclipse Subversion, no tiene dependencias externas o de los requisitos del código nativo.

En la página del proyecto hay un manual muy completo.

Link: http://gbarcode.rubyforge.org/

Ejemplo de uso:

require 'rubygems'
require 'gbarcode'

# Incluir el módulo

include Gbarcode

# Existen tres pasos para generar un codigo de barras
# 1) preparar el espacio para el string
# 2) codificar el string como un codigo de barras
# 3) imprimir el codigo de barras

# preparar el codigo de barras para el string "TEST1234"

bc = barcode_create("TEST1234")

# codificar el codigo de barras usando code 39,
# desde que code 39 no usa dígito de verificacion (checksum),
# lo podemos pasar en un flag

barcode_encode(bc, BARCODE_NO_CHECKSUM | BARCODE_39)

#imprimir el codigo de barras usando postcript

barcode_print(bc, File.new("testout.ps", "w"), BARCODE_OUT_PS)

# ó

barcode_print(bc, File.new("testout.eps", "w"), BARCODE_OUT_EPS)

Hace poco por casualidad me topé con Whenever, una gema de Ruby que nos permite crear tareas en cron de manera muy sencilla. A través de un DSL nos abstrae de la complejidad de la sintáxis de cron. Whenever está muy integrado al framework de desarrollo web Ruby on Rails, aunque puede utilizarse en un programa independiente que genera salidas de tareas para cron y hasta actualiza el archivo crontab.  En este post vamos a ver la manera de crear tareas con Whenever desde el punto de vista de un Administrador de Sistemas.

Como es habitual el primer paso es la instalación de la librería, ésto lo hacemos con el administrador de paquetes de Ruby:

sudo gem install whenever

Creamos un archivo scheduler.rb en donde vamos a detallar las tareas que queremos ejecutar y con qué frecuencia. La primer acción que deberíamos especificar es el path de trabajo a través de la directiva set

set :path, '/home/alfredo/Proyectos'

Ahora definimos dentro de un bloque every la frecuencia con la que deseamos correr las tareas. Técnicamente, la frecuencia está determinada en segundos, pero es más fácil definirlas con .minutes, .hours, .days y .months.

# se ejecuta cada 15 minutos
every 15.minutes do
   command 'comando_que_deseo_ejecutar'
   command '/usr/bin/aplicacion'
end

Cuando la frecuencia es mayor a 1 hora, podemos agregar el parámetro :at y determinar en qué momento de ese período de tiempo ejecutamos la tarea dentro del bloque:

# se ejecuta cada 2 horas en el minuto 25 de cada hora
every 2.hours, :at =>25 do
   command '/ruta/comando'
end

También podemos especificar al parámetro :at con literales. Ésto es especialmente útil cuando tenemos frecuencias mayores a 1 día, por ejemplo:

# ejecuta cada 2 dias a las 4:30 a.m.
every 2.days, :at => "4:30am" do
   command '/ruta/backup_base_datos'
end

Si es necesario podemos decidir incluso el día de la semana en la que queremos que se ejecute:

# ejecuta todos los viernes a las 00:30 a.m.
every :friday, :at => "00:30am" do
   command '/ruta/backup_home'
end

Es posible especificar cualquier día de la semana y además :weekend para correr un programa los sábados y domingos, y :weekday para cuando necesitamos hacerlo de lunes a viernes.

Para escribir el archivo crontab ejecutamos el siguiente comando:

whenever -f scheduler.rb --update-crontab

Si todo salió bien deberíamos ver la siguiente salida [write] crontab file updated en la consola. Ahora resta revisar la salida con crontab -e.

25 0,2,4,6,8,10,12,14,16,18,20,22 * * * /ruta/comando
 
30 4 1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31 * * /ruta/backup_base_datos
 
30 0 * * 5 /ruta/backup_home
 
0,15,30,45 * * * * comando_que_deseo_ejecutar
 
0,15,30,45 * * * * /usr/bin/aplicacion

La decisión si a determinado usuario se le permite acceder a un recurso dentro de la aplicación se llama “decisión de control de acceso”. Se basa en el estado de la autenticación del usuario, y de la naturaleza de los recursos y los atributos de acceso. En Spring security, las decisiones de control de acceso son llevados a cabo por los managers de decisión de acceso, los cuales deben implementar la interfaz AccessDecisionManager. Cada uno es libre de crear su propio manager de decisión de acceso implementando esta interfaz, de todas maneras Spring Security viene con tres managers que implementan esta interfaz basado en el método de votos.

Todos estos managers de decision requieren un grupo de vontantes que se configuran para la votación sobre las decisiones de control de acceso. Cada votante debe implementar la interfaz AccessDecisionVoter. Un votante puede votar para garantizar el acceso, puede abstenerse de votar o puede denegar un recurso. Los resultados se representan por las constantes ACCESS_GRANTED, ACCESS_DENIED, y ACCESS_ABSTAIN que son definidos en la interfaz AccessDecisionVoter.
Por defecto si no se especifica ningún manager de decision de acceso entonces Spring va a configurar automaticamente un manager con el método AffirmativeBased con los dos siguientes votantes:

• RoleVoter: vota por una decision de control de accesos basando en el rol del usuario. Solamente procesará los atributos de acceso que contengan el prefijo ROLE_, pero este prefijo se puede configurar. Vota por garantizar el acceso si el usuario tiene el mismo rol que el requerido para accedejor al recurso. vota por denegar el acceso si el usuario carece del rol requerido. Si el recurso no tiene un atributo de acceso que comienza con el prefijo ROLE_, el vontante se abstendra de emitir su voto.
• AuthenticatedVoter: vota por una decision de control de acceso basado en niveles de autenticación de usuario. solamente procesará si el atributo de acceso es IS_AUTHENTICATED_FULLY, IS_AUTHENTICATED_REMEMBERED, and IS_AUTHENTICATED_ANONYMOUSLY. Votará afirmativamente si el nivel de autenticacion es superior que el atributo requerido. De arriba para abajo los niveles de autenticacion son: “fully authenticated,” “authentication remembered,” y “anonymously authenticated.”

Por defecto, Spring security configurará un manager de decisión de acceso si no se especifica alguno. Este managaer de decision de acceso por defecto es equivalente al definido en la siguiente configuración:

<bean id="_accessManager">
  <property name="decisionVoters">
    <list>
      <bean class=org.springframework.security.vote.RoleVoter/>
        <bean class=org.springframework.security.vote.AuthenticatedVoter/>
      </list>
    </property>
</bean>

Este manager de decision de acceso y su s votantes deberian satisfacer los requerimientos tipicos de autenticacion. No obstante, si no satisface alguno específico, se puede crear uno propio. En la mayoria de los casos, se necesitará crear un votante customizado. Por ejemplo, se puede crear un votante que tome decision en base a la direccion IP del usuario:

package com.apress.springrecipes.board.security;
import org.springframework.security.Authentication;
import org.springframework.security.ConfigAttribute;
import org.springframework.security.ConfigAttributeDefinition;
import org.springframework.security.ui.WebAuthenticationDetails;
 
public class IpAddressVoter implements AccessDecisionVoter {
  public static final String IP_PREFIX = "IP_";
  public static final String IP_LOCAL_HOST = "IP_LOCAL_HOST";
 
  public boolean supports(ConfigAttribute attribute) {
     return attribute.getAttribute() != null
     && attribute.getAttribute().startsWith(IP_PREFIX);
}
 
public boolean supports(Class clazz) {
return true;
}
 
public int vote(Authentication authentication, Object object,
   ConfigAttributeDefinition config) {
if (!(authentication.getDetails() instanceof WebAuthenticationDetails)) {
   return ACCESS_DENIED;
}
 
WebAuthenticationDetails details = (WebAuthenticationDetails) authentication.getDetails();
String address = details.getRemoteAddress();
int result = ACCESS_ABSTAIN;
for (Object element : config.getConfigAttributes()) {
  ConfigAttribute attribute = (ConfigAttribute) element;
  if (this.supports(attribute)) {
    result = ACCESS_DENIED;
    if (IP_LOCAL_HOST.equals(attribute.getAttribute())) {
      if (address.equals("127.0.0.1")) {
        return ACCESS_GRANTED;
      }
    }
  }
}
return result;
}
}

Notar que este vontante procesará los atrbutos de acceso que comienzan con el prefijo IP_. Por el momento, solamente soporta el atributo IP_LOCAL_HOST. Su el usuario es un cliente web cuya direcciones IP es iguial a 127.0.0.1, votará por un acceso permitido. De otra forma, votará por denmegar el acceso. Si el recurso no tiene un atributo que comienza con IP_, entonces se abstine de votar.
A continuación habra que definir un manager de decision de acceso personalizado  que incluya este votante:

<beans:bean id=”accessDecisionManager” class=”org.springframework.security.vote.AffirmativeBased”>
	<beans:property name=”decisionVoters”>
		<beans:list>
			<beans:bean class=”org.springframework.security.vote.RoleVoter” />
			<beans:bean class=”org.springframework.security.vote.AuthenticatedVoter” />
			<beans:bean class=”com.apress.springrecipes.board.security.IpAddressVoter” />
		</beans:list>
	</beans:property>
</beans:bean>

Ahora supongamos que nos gustaría permitir usuarios de maquinas que corren un container WEB. Habra que hacer referencia a este manager de decision de acceso desde el elemento de configuracion  <http> para agregar el atributo de acceso IP_LOCAL_HOST a la url  /messageDelete-htm*:

<http access-decision-manager-ref=”accessDecisionManager”>
	<intercept-url pattern=”/messageList.htm*” access=”ROLE_USER,ROLE_GUEST” />
	<intercept-url pattern=”/messagePost.htm*” access=”ROLE_USER” />
	<intercept-url pattern=”/messageDelete.htm*” access=”ROLE_ADMIN,IP_LOCAL_HOST” />
…
</http>

Entonces si se quiere acceder a la aplicacion board message desde localhost, no se necesitará loguearse como administrador para ejecutar la acción.

Traducido de Apress Spring Recipes A Problem-Solution Approach (2008) - Gary Mak

Los héroes de esta historia son dos:

• SystemRescue
• VirtualBox

El primero es una LiveDistro es decir una distribución de Linux que se ejecuta en el arranque sin instalarse en un disco duro. Un comentario al margen respecto de esto es que en nuestro país Argentina se encuentra una de las primeras LiveDistro del Planeta y lleva el nombre de UTUTO, además de ser la primer Distribución reconocida totalmente libre por el proyecto GNU.

Volviendo a SystemRescue en particular la uso por el Kit de herramientas necesarias para cuando ocurre lo peor, una de estas herramientas que me agrada mucho utilizar es Partimage http://www.partimage.org, por medio de esta podemos crear imágenes comprimidas en Bzip2 o Gzip de particiones (ext2/3, ntfs, fat32,etc) y luego restaurarlas.Entonces si tengo una imagen de mi sistema esto me permitira clonarlo en otra maquina sin mayores problemas y si es una maquina virtual con VirtualBox mucho mejor.

Aqui nos detendremos a darle su mencion a VirtualBox que si bien hoy por hoy es parte del imperio Oracle, no deja de ser una herramienta útil, simple y actualizada. Entre las importantes cualidades que tiene para mi son: Multiplataforma y exportación Appliance.

Por lo tanto la idea es salvar sistemas de la siguiente manera:

1. Booteo la maquina que quiero salvar con SystemRescue
2. Una vez SystemRescue termino de levantar y me dio una Consola, ejecuto Partimage
3. Con Partimage voy a crear imágenes del Sistema que estará en algunos de los discos presentes (Generalmente suele ser /dev/hda o /dev/sda).
4. La imagen resultante la copiare en otro medio, por ejemplo un disco extraíble de buena capacidad.
5. Instalo en otra maquina VirtualBox y creo una maquina Virtual.
6. En esa maquina virtual hago que arranque SystemRescue.
7. En la maquina virtual que contendrá un disco virtual restauro en el por medio de partimage la imagen del sistema creada en el punto 3.
8. Se necesitara también restaurar el masterboot récord de la imagen a la maquina virtual.
9. Reiniciamos nuestra maquina virtual y tendremos nuestro sistema clonado y listo para sincronizarlo o ponerlo en producción directamente.

Espero les sea útil este Post y dejen sus comentarios de las experiencias que tengan.

Cuando se trabajan con grandes volúmenes de datos restaurar suele ser un trabajo que demanda muchas horas,para resolver esto Postgresql creo una manera sencilla de editar los dumps que lo veremos en este Post.

Como en todo proceso de backup lo primero que existe es el dump de la base, por ejemplo:

#pg_dump  -U postgres -Fc  -f archivo_dump.txt base

Donde  el archivo_dump.txt es el resultante del proceso.

Ahora bien si ese archivo (archivo_dump.txt) contiene tablas de unos miles de registros no hay problema,pero la cosa se complica cuando trabajamos con tablas de millones de registros y a su vez índices asociados a estas;es un hecho que demandara un tiempo importante de restauración. En mi caso en particular con tablas de miles de millones de registros el tiempo aproximado de restauración es de 18 a 24 horas.

Ahora bien como resuelvo que restaurar y que no del archivo: archivo_dump.txt, veamos el siguiente ejemplo. Primero creo un archivo legible para la raza humana de la siguiente manera:

#pg_restore -l archivo_dump.txt  > archivo.lista

El resultado del archivo.lista sera algo como lo siguiente:

; Archive created at Fri Jan 22 22:28:36 2010
; dbname: ipcorp
; TOC Entries: 74
; Compression: 0
; Dump Version: 1.4-0
; Format: CUSTOM
;
;
; Selected TOC Entries:
;
2; 145344 TABLE species postgres
3; 145344 ACL species
4; 145359 TABLE nt_header postgres
5; 145359 ACL nt_header
6; 145402 TABLE species_records postgres
7; 145402 ACL species_records
8; 145416 TABLE ss_old postgres

Las primeras lineas son una serie de referencias acerca del nombre de la base de datos, fecha del dump, mas abajo encontramos números de linea asociados a tablas, funciones e índices; esto ultimo puede ser comentado mediante “;” o también se puede eliminarlos directamente.

Entonces una vez que tenemos nuestro archivo de lista modificado con los elementos que realmente nos interesa, restauramos de la siguiente manera:

# pg_restore -Fc -d base -L archivo.lista < file_dump.txt

REST son las siglas de Representational State Transfer (Transferencia de Estado Representacional), es una técnica de arquitectura software para sistemas hipermedia distribuidos como la World Wide Web. El término se originó en el año 2000, en una tesis doctoral sobre la web escrita por Roy Fielding, uno de los principales autores de la especificación del protocolo HTTP y ha pasado a ser ampliamente utilizado por la comunidad de desarrollo.

Es un hecho olvidado por muchos desarrolladores Web de  hoy que el protocolo HTTP puede hacer algo más que GET y POST. No debería resultar tan sorprendente si consideramos que los navegadores solo soportan estas dos peticiones. El protocolo HTTP define también los métodos PUT y DELETE que deberían utilizase para crear o borrar un recurso en la Web. (más sobre REST: http://es.wikipedia.org/wiki/Representational_State_Transfer)

Por que usar REST?

• URLs limpias: en REST, las urls representan recursos y no acciones, por lo tanto siempre tienen el mismo formato.
• Formatos de respuesta variados: los controladores REST estan escritos de manera tal que las acciones pueden devolver sus resultados fácilmente en diferentes formatos de respuesta. Una misma acción puede entregar resultados en HTML, XML, RSS o cualquier formato que solicite el cliente, de manera rápida y sencilla.
• Menos código: el desarrollar acciones únicas capaces de soportar múltiples clientes evita repeticiones en el sentido DRY (Don’t repeat Yourself)
• Controladores orientados a CRUD (Create Read Update Delete): los controladores y los recursos se funden en una única cosa. Cada controlador tiene como responsabilidad manipular un único tipo de recurso.
• Diseño limpio de la aplicación: REST produce un diseño y escritura de código clara y fácil de mantener.

Si nunca has utilizado  REST con Rails, te recomiendo que te descargues el pdf RestFul Rails desde http://www.b-simple.de/documents (disponible en español, inglés y alemán!) y comiences por alli. Este pequeño libro tiene la desventaja que la versión utilizada de Rails es la 1, por lo que te encontrarás con varias disidencias a la hora de probar los ejemplos, sobre todo al final del libro. Pero afortunadamente esto no es un gran problema, dejo aquí algunas urls que te servirán a modo de consulta y mayor aprendizaje:

• Recursos anidados con REST y RAILS: http://www.jaimeiniesta.com/2007/12/22/tutorial-recursos-anidados-con-rest-y-rails-2/comment-page-1/
• Rapid restful Apps (en inglés): http://articles.sitepoint.com/article/rapid-restful-rails-apps
• Easy restful Screencast: http://akitaonrails.com/2008/1/25/easy-restful-rails-screencast
• Whats new on REST Rails (en inglés) http://ryandaigle.com/articles/2006/08/01/whats-new-in-edge-rails-simply-restful-support-and-how-to-use-it