v.codeweblog » tips & tricks

XSD to Java o cómo crear un WebService a partir de schemas

VictorR — Thu, 11 Mar 2010 15:49:10 +0000

Hoy un post “tecky”. Pero esta vez, y recordando lo que yo mismo predico, sólo va a ser una referencia a otro blog.

Llevo unos días peleándome con la creación de un web service. En concreto, tengo el schema que debe seguir, pero no tengo el WSDL. Bien, tras mucho buscar, he encontrado la manera de generar, sí, generar, el WSDL.

Aquí la referencia:

Build contract first web services using CXF+JAXWS+JAXB & Spring

Zen Coding

VictorR — Fri, 29 Jan 2010 09:42:23 +0000

Desde Smashing Magazine encuentro Zen Coding, que como dice el artículo se trata de:

a handy set of tools for high-speed HTML and CSS coding

Pues eso. Una vez presentado, ¿cómo funciona? muy facil, yo te lo explico Sólo tienes que poner selectores CSS, sí, sí, selectores CSS para generar la estructura html que deseas en tu editor (lista de editores soportados más abajo), y lanzar el shortcut correspondiente (en Aptana alt+E) para generar el código html.

Enlace a la noticia en Smashing Magazine, Zen Codign: A Speedy Way To Write HTML/CSS Code.

Editores soportados:
– Aptana (cross-platform)
– Coda (Mac)
– Espresso (Mac)

Editores semi-soportados:
– TextMate (Mac, la alternativa para Windows es E-text);
– TopStyle
– Sublime Text
– GEdit
– editArea online editor

A disfrutar.

Validando Cif, Nif y Nie

VictorR — Mon, 29 Jun 2009 13:29:39 +0000

Del proyecto en el que trabajo en la actualidad he “sacado” estas tres piezas de código. Nada fuera de lo común, pero que sin duda sirven y servirán para una parte de las pequeñas tareas que se realizan en cada proyecto. Esto es, validar datos.

Como todo el mundo sabe, para que una aplicación, web, cosa… funcione, debe mantener un conjunto discreto de datos (esto siempre me gustó de las clases de mates), información, de una manera poco ambigua. Y por eso es necesario validar la mayoría de datos que la aplicación, web, cosa… acepta.

Básicamente hay dos maneras de validar los datos, una es en el navegador del cliente, con tecnologías tipo javascript, y la otra es en el servidor, por ejemplo con java, php… Poco más queda decir a parte de que la manera más fácil de controlar los datos y más segura es validar los datos a nivel de servidor. Ya sabes, desactivas el javascripi y te quedas sin validar.

Sim embargo, lo que os traigo aquí es javascript, ¿por qué? Porque a modo de “repositorio” quiero guardar estas “perlas” para futuros trabajos y que sirva a otros ~~vagos~~ de ayuda.

Validar CIF

String.prototype.testCIF = function(){
var pares = 0;
var impares = 0;
var suma;
var ultima;
var unumero;
var uletra = new Array("J", "A", "B", "C", "D", "E", "F", "G", "H", "I");
var xxx;

texto = this.toUpperCase();

var regular = new RegExp(/^[ABCDEFGHKLMNPQS]\d{7}[0-9,A-J]$/g);
if (!regular.exec(texto)) return false;

ultima = texto.substr(8,1);

for (var cont = 1 ; cont < 7 ; cont ++){
xxx = (2 * parseInt(texto.substr(cont++,1))).toString() + "0";
impares += parseInt(xxx.substr(0,1)) + parseInt(xxx.substr(1,1));
pares += parseInt(texto.substr(cont,1));
}
xxx = (2 * parseInt(texto.substr(cont,1))).toString() + "0";
impares += parseInt(xxx.substr(0,1)) + parseInt(xxx.substr(1,1));

suma = (pares + impares).toString();
unumero = parseInt(suma.substr(suma.length - 1, 1));
unumero = (10 - unumero).toString();
if(unumero == 10) unumero = 0;

if ((ultima == unumero) || (ultima == uletra[unumero]))
return true;
else
return false;
}

Validar DNI

String.prototype.testDNI = function() {
dni = this.toUpperCase();
numero = dni.substr(0,dni.length-1);
let = dni.substr(dni.length-1,1);
let = let.toUpperCase();
numero = numero % 23;
letra = 'TRWAGMYFPDXBNJZSQVHLCKET';
lletra = letra.charAt(numero);

return (lletra == let)
}

Validar NIE

String.prototype.testNIE = function() {
var dni = this.toUpperCase();
var pre = dni.substr(0, 1);
var prev = '0';
if (pre == 'X')
prev = '0';
else if (pre == 'Y')
prev = '1';
else if (pre == 'Z')
prev = '2';
numero = prev + dni.substr(1,dni.length-1);
return numero.testDNI();
}

Si os dáis cuenta, las funciones extienden la clase String de javascript, esto es simplemente para que sea más facil de utilizar y lo más “orientado” a objetos posible.

Ejemplo de USO

// validación de un DNI
"74185296S".testDNI(); // value: true

NOTA: que quede claro que el código no me lo he inventado yo, lo he adaptado de los recursos que se pueden encontrar en la inmensidad de internet. Lo que pasa es que no recuerdo de dónde los saqué, ni si lo saqué yo, y no puedo poner la retribución que se merece el autor/es de dichos scripts.

Definiendo entornos con Maven

VictorR — Wed, 03 Jun 2009 08:05:11 +0000

Una pregunta, ¿qué pasa cuando quieres desplegar tu aplicación en diferentes entornos? Lo normal es que estos entornos no sean iguales, aunque es lo aconsejable. Lo normal es que no acaben de tener la misma configuración, por ejemplo el nivel de logs (debug para desarrollo, error para producción…). Lo normal, vaya, es que tengas que controlar la configuración para cada entorno por separado. Frameworks como Ruby on Rails, o Symfony ya vienen con esta idea de tener entornos diferentes, con configuración diferente y propiedades diferentes, pero en Java te lo tienes que “currar” un poco más.

Ahora bien, tienes dos opciones, o lo haces a “manija” o te lo curras con algún sistema automatizado para cambiar estas configuraciones. Y es aquí donde viene que ni pintado Maven, en particular los Profiles de Maven. Y es que:

Profiles are specified using a subset of the elements available in the POM itself (plus one extra section), and are triggered in any of a variety of ways. They modify the POM at build time, and are meant to be used in complementary sets to give equivalent-but-different parameters for a set of target environments (providing, for example, the path of the appserver root in the development, testing, and production environments). As such, profiles can easily lead to differing build results from different members of your team.

Aquí un simple ejemplo de que cómo especificar diferentes recursos a maven según el entorno:

GeSHi Error: GeSHi could not find the language (using path /usr/home/v-code.org/web/blog/wp-content/plugins/codecolorer/lib/geshi/) (code 2)

El ejemplo es sencillo, especifica las carpetas de los resources del proyecto para los entornos de desarrollo y de test. Ahora lo que se necesita para activarlo es ejecutar Maven pasando como parámetro -Denv=dev o -Denv=test. Hay otras maneras de activar los Profiles. Puede depender del sistema operativo donde estés compilando el proyecto, si existen o dejan de existir diferentes archivos (también dependiendo del entorno en el que te encuentres)… Lo importante de la configuración es saber que en el tag activation es dónde y cómo se activan los profiles.

GeSHi Error: GeSHi could not find the language (using path /usr/home/v-code.org/web/blog/wp-content/plugins/codecolorer/lib/geshi/) (code 2)

Con este código estamos diciendo que cuando se compile el proyecto, si existe una variable llamada env con valor test pasada como parámetro, el Profile se active. No es muy dificil… Así, si queremos compilar el proyecto en el entorno de desarrollo (-Denv=dev) la llamada sería:

GeSHi Error: GeSHi could not find the language (using path /usr/home/v-code.org/web/blog/wp-content/plugins/codecolorer/lib/geshi/) (code 2)

Bueno, esto sólo ha sido un ejemplo básico, no dejéis de revisar la documentación del POM de Maven para obtener más información y profundizar más en el tema.

Setting the php.ini MAMP file as default on OSX

VictorR — Thu, 05 Mar 2009 21:02:51 +0000

Hace poco, muy poco, que sigo el tutorial Jobeet para aprender a utilizar Symfony y así hacer subir mi geek power. Desde aquí, lo recomiendo firmemente.

Bien, primer hecho, para el correcto/buen uso de este framework, es necesario tirar de Terminal (en mi caso OSX, cmd en Win) y ejecutar comandos para crear, generar, modificar, cargar el proyecto/aplicación/base de datos… Symfony está implementado con PHP 5 por ser un framework orientado a objetos (creo recordar que como requerimiento es necesario la versión 5.2). Y muchos de esos comandos ejecutados desde el Terminal, son precisamente scripts de PHP.

Segundo hecho. Mac OS X, por lo menos en su última versión, 10.5 (Leopard) tiene configurado ya una versión de PHP.

Tercer hecho. Yo que soy un poco gandul, decidí bajar, antes de ponerme a configurar nada a mano, la versión gratuita de MAMP (Mac OSX, Apache, MySQL, PHP).

Problema. A partir de ahí, los 3 hechos anteriores, ya te puedes poner como un loco a tocar la configuración del php del MAMP, que la versión que utilices por línea de comando o Terminal en tu Mac, es la preinstalada. De esto me di cuenta cuando revisando la configuración en MAMP, y revisando la configuración por el Terminal, habían sustanciales diferencias entre ambas versiones.

Después de probar y acceder a los scripts de php por el terminal, y preguntarme dónde está esta preinstalada versión, y ver que ni siquiera había un php.ini configurado intenté modificar los ficheros de configuración de la versión preinstalada para que apuntaran al php.ini del MAMP.

Bien, si por el Terminal pruebas el siguiente comando:

$ php --ini

debería aparecer la información sobre dónde encontrar el fichero php.ini (Path /etc), y dónde busca nuevos ficheros equivalentes para su uso. En mi caso, todos los resultados eran “(none)”. Así que ni corto ni perezoso (pero si gandul), voy al directorio /etc y le hecho un vistazo. Aquí, aparte de muchos ficheros de configuración encontré un php.ini.default (por si no lo sabes, lo puedes renombrar quitando el .default final y sería el fichero utilizado). Pero como he dicho antes, este no es el php.ini que quiero usar.

Así que mi solución ha sido la de crear un link al php.ini de MAMP, en mi caso en /Applications/MAMP/conf/php5/php.ini.

Atención, necesitarás permisos de root (o super usuario) para poder crearlo, si lo quieres activar puedes hacerlo como indico aquí Activar el Super Usuario en OS X.

Y luego ejecutar (siempre dentro de /etc):

$ sudo ln -s /Applications/MAMP/conf/php5/php.ini php.ini

Sólo debes introducir el password de super usuario y listo. Al volver a ejecutar el comando php –ini debería aparecer algo parecido a esto.

¡Pedazo de invento los links! Aquí podemos ver que “Loaded Configuration File” es /Applications/MAMP/conf/php5/php.ini, es decir, el fichero php.ini del MAMP.

Changing login window background image on Leopard

VictorR — Mon, 08 Dec 2008 22:26:49 +0000

Personalmente, no recuerdo casi nada de Apple (y estoy hablando de diseño) que no me guste. Bueno, he dicho casi nada porque la imagen de la pantalla de login en Leopard es terrible… Esa especie de ¿nebulosa? con esos colores no me gusta nada. Y googleando el otro día encontré la manera de cambiarla.

Es sencillo, sólo hay que reemplazar la siguiente imágen por la que quieras.

/System/Library/CoreServices/DefaultDesktop.jpg

Eso sí, para reemplazarla tienes que tener privilegios de super usuario, si no malo.

Yo ya me la he cambiado.