#Java y los Impuestos (#DIAN)

Todos los que hayan liquidado/pagado/sufrido un trámite ante el ente nacional de impuestos (DIAN, SAT, IRS, etc) saben que es una forma de mortificación humana soportable solo por esos seres extraños que llamamos contadores. Sin embargo, mes a mes debo hacerme cargo de una de esas tareas y cada vez que lo hago recuerdo de neuvo porque a nadie le gusta JAVA y es que con los applets y la cantidad de pequeños pero muy molestos problemas que presenta la plataforma me pregunto siempre porque sigue siendo tan saludable en el mundo corporativo.

El último problema que encontré pagando los impuestos es de permisos sobre las propiedades del sistema sin ser un gurú en seguridad estoy seguro de que la solución entraña un potencial problema pero…entre eso y una potencial interventoría por impuestos…el menor de los males. Asi que si llegna a obtener un mensaje como

java.security.AccessControlException: access denied (“java.util.PropertyPermission” “user.home” “read”)

Cuando firman un documento en el portal de la DIAN (www.dian.gov.co – aka MUISCA) recuerden editar el archivo JAVA_HOME/jre/lib/security\java.policy agregando:

permission java.util.PropertyPermission "user.home", "read"; 
permission java.security.AllPermission; 
permission java.io.FilePermission "<<ALL FILES>>", "read"; 
permission java.io.FilePermission "<<ALL FILES>>", "write"; 
permission java.util.PropertyPermission "*", "read, write"; 
permission java.util.PropertyPermission "user.dir", "read"; 
permission java.lang.RuntimePermission "*";

antes de finalizar el archivo. Luego de pagar el impuesto…como estaba, es mejor prevenir.

El asunto con /usr/lib/jvm/default-jvm

Probando Intellij IDEA tuve un problema ejecutando una app Maven, al parecer mi maven seguía tratando de ejecutarse usando el viejo JDK 1.6 y no el 1.7 configurado con sudo updade-alternatives –config java sucede que maven usa la variable JAVA_HOME y ésta se encuentra configurada para apuntar a /usr/lib/jvm/default-jvm que es un enlace al jdk por defecto del sistema. Solución, cambiar el destino del enlace (reemplazar jdk_name con el nombre de un jdk listado con el primer comando).

sudo update-java-alternatives -l
sudo update-java-alternatives -s jdk_name
sudo unlink /usr/lib/jvm/default-java
sudo ln -s /usr/lib/jvm/jdk_name /usr/lib/jvm/default-java

Agentes y videojuegos

Los juegos de video son una industria enorme, una forma de deporte y un sueño de casi todos los que empezamos a codificar en los 90’s. Con el acceso a motores y librerías para generar juegos sencillos (Quien no recuerda largas noches en la universidad trabajando con Allegro?) varios nos acercamos un poco al rol de creadores que al de jugadores.

Ahora en Colombia nos encontramos con un apoyo -tardío e inusitado, falta ver si exitoso- por parte del gobierno para la creación de contenido en entretenimiento digital, dentro de esa categoría se encuentra el desarrollo de video juegos.

Creo que hay un espacio intermedio entre los jugadores y los productores de videojuegos en el que nos encontramos quienes sabiendo algo de programación y teniendo aún poca experiencia en la producción de juegos queremos acercarnos a la industria. Creo que la forma ideal de hacerlo es mediante las competencias de programación de agentes autónomos.

Existen varios torneos en los que a partir de un API pública los desarrolladores generan implementaciones que juegan un juego y que tienen reglas claras y referencias para realizar pruebas con las cuales es posible empezar a pensar de la forma necesaria y conocer algunos de los requisitos para hacer videojuegos sin necesidad de hacer un salto de carrera inmediato, entre otras me gustaría destacar tres:

JavaCup

Es un torneo organizado de forma anual por el porta Javahispano, se desarrollan equipos de fútbol que compiten en un torneo mundial, hay premios en efectivo para los cuatro primeros puestos y el desarrollo es muy sencillo. En la web existen varios videos con partidos jugados durante la competencia.

Mario AI

Es un torneo organizado desde 2009, se usa Java para las implementaciones, tiene divisiones para agentes jugadores, generación de niveles (escenarios, tableros) y uno muy interesante para agentes que compiten para pasar un test de Turing (el público compara el juego del agente contra el de un humano y decide cual es humano).

Starcraft AI

Uno de mis juegos favoritos -nunca he sido buen jugador, pero como en el fútbol eso no le quita emoción- que cuenta con un API en C++ y Wrappers para programar los agentes usando Java, Python, Lua, C# (Mono) e incluso Prolog (Porqué no PHP? jajaja toma eso @srdraka). Este sí que es un desafio y hay varias tesis de grado de maestría que han competido.

#Bitbucket y repositorios #Maven

Generalmente cuando se hace algún tipo de libreria en Java se empaqueta en un artefacto .jar, para gestionar el ciclo de construcción de una aplicación (entre ellas la gestión de dependencias) se puede usar Maven u otra herramienta similar (ant, ivy, gradle).

Ahora bien para publicar los artefactos al equipo y dejarlos disponibles se puede usar un ftp, dav o un gestor completo como Artifactory o Nexus, sin embargo con soluciones como Bitbucket o Github es buena idea mantener todo junto (más aún si Bitbucket permite repositorios privados tanto en Mercurial como en Git).

Para ello simplemente tenemos que configurar en el pom.xml de nuestro proyecto para que haga un deploy local del artefacto y luego publicarlo en bitbucket (git) mediante el ciclo commit , push. Finalmente cuando se necesite usar la dependencia en otro proyecto solo hay que agregar la configuración de repositorios para descargar la dependencia. Por ahora un pom.xml de ejemplo:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>org.simmetrics</groupId>
  <artifactId>simmetrics</artifactId>
  <version>1.6.2</version>
  <packaging>jar</packaging>

  <name>simmetrics</name>
  <description>SimMetrics is a Similarity Metric Library, based on previous work by http://sourceforge.net/projects/simmetrics/</description>
  <url>https://bitbucket.org/Nickmancol/simmetrics</url>

  <properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <altDeploymentRepository>releases::default::${project.baseUri}/mavenRepo/releases/</altDeploymentRepository>
  </properties>
  
  <developers>
    <developer>
      <id>@Nickmancol</id>
      <name>Nicolas Bohorquez Gutierrez</name>
      <email>nicolas.bg@gmail.com</email>
      <timezone>America/Bogota</timezone>
    </developer>
  </developers>

  <scm>
    <connection>scm:hg:http://bitbucket.org/Nickmancol/simmetrics</connection>
    <developerConnection>scm:hg:http://bitbucket.org/Nickmancol/simmetrics</developerConnection>
    <url>http://bitbucket.org/Nickmancol/simmetrics</url>
  </scm>
  
  <distributionManagement>
	  <repository>
      <id>releases</id>
      <url>https://bitbucket.org/Nickmancol/simmetrics/raw/tip/mavenRepo/releases/</url>
	  </repository>
	  <snapshotRepository>
	  	<id>snapshots</id>
      <url>https://bitbucket.org/Nickmancol/simmetrics/raw/tip/mavenRepo/snapshots/</url>
	  </snapshotRepository>
  </distributionManagement>

	<build>
    <plugins>
    	<plugin>
	      <groupId>org.apache.maven.plugins</groupId>
	      <artifactId>maven-compiler-plugin</artifactId>
	      <version>2.3.2</version>
	      <configuration>
	        <source>1.5</source>
	        <target>1.5</target>
	      </configuration>
	    </plugin>
	    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-javadoc-plugin</artifactId>
        <executions>
          <execution>
            <id>attach-javadocs</id>
            <goals>
              <goal>jar</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-source-plugin</artifactId>
        <executions>
          <execution>
            <goals>
              <goal>jar</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
		</plugins>
  </build>
	
	<profiles>
		<profile>
			<id>deploy-snapshot</id>
			<properties>
				<altDeploymentRepository>snapshots::default::${project.baseUri}/mavenRepo/snapshots</altDeploymentRepository>
			</properties>
		</profile>
	</profiles>
	
  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.8.1</version>
    </dependency>
  </dependencies>
</project>

Corresponde a un proyecto para actualizar una librería para el cálculo de similitud entre dos cadenas de texto usando diferentes métricas, originalmente publicada en sourceforge (CVS) sin mantenimiento desde hace 5 años.

En las lineas 34 a 43 se declaran los repositorios para distribución del artefacto. En la linea 16 se declara la propiedad altDeploymentRepository que sobreescribe la publicación del artefacto en el repositorio por una ruta local directorio del proyecto/mavenRepo/releases cuando se ejecuta la tarea de maven deploy. Finalmente en las lineas 82 a 89 se declara un profile para sobreescribir la propiedad altDeploymentRepository cuando se hace deploy de un snapshot.

Peticiones #https desde #java: illegal_parameter

En un test case necesité hacer una petición httpS (http commons client) pero como resultado siempre obtenía la siguiente excepción:

javax.net.ssl.SSLException: Received fatal alert: illegal_parameter

Sucede que la implementación de java 1.7 openjdk-7 (7~b147-2.0-0ubuntu0.11.10.1) parece que no puede hacer correctamente el handshake necesario para terminar la operación (los detalles exceden mi conocimiento al respecto) sin embargo la solución rápida es cambiar el JDK usado (en netbeans Tools->Java Platforms) por una implementación Java de Sun Oracle en mi caso Java(TM) SE Runtime Environment (build 1.6.0_26-b03). Documento esto solo para que en producción no me pase (Estoy seguro de que va a pasar pero con algo de suerte encuentro la razón rápidamente y lo arreglo sin mucho ruido).

#netbeans, #grails y el classpath (I)

Desde hace algún tiempo (un par de meses) he intentado usar netbeans (siempre he sido amante de STS pero consume recursos de forma excesiva) para desarrollar en grails. Una de las cosas más molestas es el hecho de que netbeans no incluye en el classpath del proyecto las librerias declaradas como dependencias en config/BuildConfig.groovy. Para un proyecto en el que estamos trabajando actualmente necesito usar la excelente librería webharvest y una de mis frustraciones era la incapacidad de usar el autocompletado de clases, métodos y argumentos así que decidí pasar un buen tiempo buscando alternativas…y no encontré.

De tal forma que lo único que se me ocurrió (acepto sugerencias de formas mejores) fue adicionar un Java Platform (netbeans->tools->Java Platforms) para el proyecto específico añadiendo enlaces (sudo ln -s origen destino, en win2 son accesos directos) a los .jar que uso en el proyecto (en este caso webharvest, hamcrest y porque no…el propio groovy):

Luego en las propiedades del proyecto selecciono el Java Platform modificado:

y finalmente no aparecen como errores de classpath las dependencias de webharvest!!!.

Grails: integración de Bpm

Hace unos cuatro años trabajé como consultor en un proyecto (grande) de implantación de un sistema de manejo de procesos de negocio para una entidad estatal centroamericana, en ese momento los motores de gestión de procesos libres no estaban maduros y mi comprensión del proyecto entero y de mi participación (como desarrollador de aplicaciones cliente integrables al motor) era muy oscura y (admitamoslo) lenta.

Sin embargo, gracias a ese proyecto conocí a muchas personas muy brillantes – incluso a un par que diseñaron e implementaron sus propias versiones de motores de gestión de procesos de negocios (tanto en Java como en .Net) – y empecé a hacerle seguimiento a los BPMS Libres.

Hace un año encontré que la versión de Bonita Open Solution 5 tenía un importantes mejoras y que la nueva versión de jBpm estaba a punto de salir, así que intenté (sin mucho éxito) iniciar un acercamiento a Bonita, incluso promoví la investigación al respecto en mi empresa y obtuvimos algunas victorias.

Ahora con Grails como framework principal y después de un laaargo año en un proyecto importante que hubiera sido mucho mas sencillo de manejar si se hubiera modelado como procesos estamos trabajando en la integración de un motor de procesos en nuestro producto.

Después de evaluar de nuevo los motores libres más populares (jBpm, Bonita y Activiti) nos decidimos por Activiti, no solo porque es una implementación basada con licencia Apache sino que además tiene un gran modelador e integración nativa con grails mediante el plugin desarrollado por Lim Chee Kin.

Un punto crucial de la integración se encuentra en la autenticación y autorización (mantener la sincronización de dos bases con los usuarios y roles es una violación flagrante del principio DRY) para lo cual Lim Chee Kin ha desarrollado un plugin que integra activiti con spring security en grails.

Hasta aquí todo perfecto, tenemos un excelente framework web, un motor Bpm libre y un framework de seguridad estable integrados, sin embargo…en nuestro proyecto usamos Shiro Security (principalmente porque tiene un manejo propio de sesiones que es agnóstico del tipo de tecnología en el que se use).

La buena noticia es que grails también tiene un plugin que hace la tarea de integración con shiro algo ultra sencillo, el problema es que no hay una forma obvia (aka plugin) o documentada de integrar shiro con activiti en grails.

Entonces…para eso..he trabajado en un plugin de integración entre Activiti y Shiro sobre grails (1.3.7) basado en el plugin de Lim Chee Kin, solo inicializa el identityService de activiti con los SecurityUtils de shiro, la forma (primitiva y no recomendada) de probarlo es a través de la aplicación de ejemplo VacationRequest del plugin de Activiti para grails (sin usar la integración con spring security).

Por ahora el plugin y la documentación (tbd) de la versión 0.1 están alojados en bitbucket (larga vida a Mercurial), en un futuro cercano espero que se publique en el repositorio central de grails (actualmente están haciendo mantenimiento al sitio de codehaus y no se puede hacer registro de nuevos usuarios).