Spanish

Implementando un servidor Radius para WIFI

La verdad es que es casi de vergüenza que en la época en la que estamos aún no me haya metido en el fregado de montar una Wifi en condiciones en la empresa. Hasta la fecha, como no demasiada gente se conectaba a nuestra Wifi, usábamos una encriptación WPA2 con clave fija. Evidentemente con poca gente esto no supone muchos riesgos, ya que en caso de despido y cese en la empresa de alguno de los usuarios que usan la Wifi con cambiarla y dar la nueva contraseña es suficiente. El problema es cuando este número de usuarios crece, y crece…

Evidentemente hoy en día con el auge de las tabletas, móviles con Wifi, portátiles, etc etc.. es casi imposible que no haya nadie que te diga “¿Me puedes dar la contraseña de la Wifi?”… Solución: Wifi por usuarios, ¿el método? Autenticación con Radius.

Para este pequeño experimento he utilizado un punto de acceso DLINK DWL-2100AP y un servidor Proliant al que primeramente instalé FreeRadius y a continuación TekRadius. Las pruebas con FreeRadius fueron realmente satisfactorias. Mi pobre iPhone acabo harto de que cada dos por tres estuviera entrando y saliendo de la Wifi. Finalmente opté por dejar el servicio con TekRadius, ya que la versión de FreeRadius que hay ahora mismo en Windows 2008 tiene un Bug y solo funciona en modo DEBUG, lo cual no es deseable en entornos de producción.

En fin… Para configurar este invento hay que hacer lo siguiente:

Primeramente descargarnos TekRadius de la web: www.tekradius.com

Existen dos versiones, una que guarda los datos en SQL y otra que utiliza SQL Lite y que no necesita de una base de datos externa. Yo me he descargado la versión para SQL Lite, ya que para hacer pruebas realmente no tengo por qué estar complicándome demasiado.

Es importante también bajarse el programa TekCert de la misma web ya que con él crearemos el certificado de seguridad que incluiremos con nuestra conexión e instalarlo, ya que lo primero que haremos será crear un certificado que se utilizará en los clientes que tengan capacidad de utilizar PEAP usando un certificado, más seguro.

Como ya he comentado anteriormente lo primero es abrir TekCert. Y rellenar los campos para crear un certificado. En la siguiente captura de pantalla podemos ver cómo quedaría uno que he creado yo:

Deberéis de rellenarlo con vuestros datos.Quizás lo único que habría que tener en cuenta es la duración del certificado “Valid for”. Yo le he puesto 9999, lo que hace que el certificado sea válido para este número de días. Eso ya a ha gusto de cada uno.

Tras haber creado el certificado con “Generate Certificate” podemos salir del programa e irnos al TkRadius Manager. Lo primero de todo es dejar el programa bien configurado antes de meternos en líos. Para ello pulsamos sobre la pestaña Setting y a continuación Service Parameters. Veremos que aparece algo así:

Y lo configuraremos de la siguiente manera:

Listen IP Address: La dirección IP de nuestra máquina servidora, es decir, donde está instalado el programa

Startup: Automatic, así en caso de reiniciar la máquina el servicio Radius arrancará solo

Logging: Yo uso debug para obtener logs de todo, en caso de no querer ponéis none o un nivel inferior.

Authentication Port: 1812. Es el usado por defecto para Radius.

PEAP Inner Auth Method: Hay varios. Yo con EAP-MS-CHAP he conseguido que se me autenfiquen iPhones y Blackberrys. Con otros puede daros problemas. Es cuestión de ir probando.

Accounting Enabled Port: Se marca solo si vuestro punto de acceso requiere este dato. Por lo normal es el puerto Radius + 1, por lo que si el puerto era 1812 este será 1813. En mi caso tuve que usarlo o mis clientes no se autentificaban corréctamente.

Grabamos con “Save Settings” y a continuación nos vamos a la pestaña “Users” donde definiremos los usuarios que podrán conectarse a nuestra Wifi. He creado un usuario llamado “pruebita”, con contraseña igualmente “pruebita”. En la siguiente pantalla podeis ver cómo quedaría:

Para dar de alta los usuarios hay que hacer lo siguiente:

En la parte izquierda añadimos el nombre de usuario. Cuando esté hecho pinchamos sobre él y en los “Attribute” de la derecha activamos:

  • Check User-Password: Y en la casilla de la derecha ponemos la contraseña que va a tener dicho usuario. Vereis que queda oculta con asteriscos
  • Check TLS-Server-Certificate: Al pulsar sobre el desplegable de la derecha os aparecerá el certificado que habéis creado con TkCert.

Con esto ya tenemos nuestro usuario creado. Ya estamos casi, falta solamente definir al punto de acceso. Para ello pulsamos sobre la pestaña “Clients” y aparecerá algo parecido a lo siguiente:

 

Para dar de alta nuestro punto de acceso (En nuestro caso el DLINK) rellenaremos los campos de la siguiente manera:

  • NAS: IP que tiene actualmente el punto de acceso. Esto es importante. En caso de cambiar alguna vez la IP del punto de acceso también deberemos de cambiarla aquí.
  • Secret: Contraseña con la que el punto de acceso se conectará a nuestro Radius. Poned una cualquiera , que sea segura, y es la que usaréis a la hora de configurar el punto de acceso.
  • Vendor: por lo normal usad ietf
  • Enabled: Yes

Ya tendremos TkRadius configurado. Para más seguridad de que funcione corréctamente debereis de reiniciar el servicio o incluso reiniciar el ordenador completamente. El último paso sería configurar el punto de acceso. En el caso de mi DLINK quedaría de la siguiente manera:

Tanto en Radius server como Accounting Server debéis de poner la dirección IP de vuestro servidor Radius. Aplicad los cambios y lo siguiente es coger un dispositivo Wifi y conectaros a la red. ¡A mí me ha funcionado incluso con un iPhone!

Me siento engañado en España por las compañias Telefónicas

Esta semana he estado en Londrés. La verdad es que estuve hace pocos meses, pero por causas que no vienen al caso he tenido que volver con mi queridísima @MariMarCampoy.

La historia de mi “cabreo” monumental fue debido a que conocimos a un grupo de españoles que estaban trabajando en Londrés y les comentamos la posibilidad de conectarnos a internet de alguna manera “barata y sencilla”. Por mi parte llevo un iPhone con contrato de Movistar de empresa, que podre de mí que active el Roaming, porque con solo encender la itinerancia de datos estamos embolsando a estos señores 10€ por 10Mb diarios, que por supuesto en caso de superarse vuelven a ser otros 10€… y así hasta quién sabe… ¿Solución? Contratar una tarjeta PREPAGO (Sí! Prepago!) para el iPhone en una compañia llamada “3”, así como suena, el numero “3”, que por 15 libras esterlinas, unos 18€ mensuales, permite: Internet ilimitado!! (Nada de restricciones como en España), 3000 mensajes, 3000 minutos gratis, 1000 minutos si es a otros números que no sean de “3”….

Cuando me lo comentaron no me lo creía, así que dicho y hecho nos acercamos a una tienda de “The Phone Warehouse”, que viene a ser el “The Phone House” de España. En poco más de 10 minutos teníamos nuestra tarjeta en nuestras manos y doy fe de que funciona sin problemas. Además, si tenemos un móvil que permita compartir Internet, como el iPhone que llevábamos, podremos usar un portatil y sin límite de nada estar navegando a nuestras anchas… ¡¡ por 15 míseras libras !!

Lo mejor de todo es que esto no acaba aquí… Cualquier compañía te da tarjetas de prepago para iPhone, Android o lo que sea. No hay que volverse loco. Incluso O2, que son nuestra Telefónica pero en Inglaterra, te da tarjetas que por 1 libra al día te conectas a Internet, pero que encima permiten llamar a España por 5 peniques de libra por minuto. Y ya para volverse loco… Londres está lleno de los llamados “HotSpots Wifi”. Son puntos Wifi que si contratas este servicio con tu operador tendrás acceso Wifi en prácticamente cualquier parte de Londres, sin tener que estar tirando de 3G que a veces “garraspea” un poco. Gracias a eso entendí cómo la gente llegaba a los millones de cafeterías de Londres, abría sus portátiles y se ponían a trabajar…

En resumen, me siento engañado en España por las compañias telefónicas a más no poder. A parte cada vez tengo más claro que tecnológicamente hablando estamos en la prehistoria.. ¡y encima en crisis!

¿Es que somos tontos?

Si hay una profesión que de verdad está mal definida es sin duda la de técnico informático o informático a secas. Pues sí señores, por suerte o por desgracia esa es mi profesión, ¿y qué es lo que hace un informático? Según me contaron, dijeron o explicaron cuando estaba haciendo la carrera: un informático es una persona que, con los medios informáticos de los que dispone, crea soluciones a problemas dados. Pues bien, ¿me quiere alguien explicar qué tiene que ver un paquete de folios con un problema informático?….

Esta deshonra e indignación viene dada porque un iluminado de mi empresa el otro día me pidió que bajara 10 paquetes de folios para la fotocopiadora. Mi pregunta instantánea fue preguntar ¿y por qué yo? Y la respuesta del susidicho subnormal fue: porque tú te encargas de que funcione la fotocopiadora cuando se acaba el tóner ¿no?

Punto UNO: Le cambio el tóner yo porque sois unos manazas y siempre acaba tirado por el suelo

Punto DOS: La arreglo si puedo, y si no llamo al servicio oficial

Punto TRES: Nadie dice que yo sea un esclavo porteador de material, y menos de paquetes de folios.

En fin. Supongo que tonterías de estas le habrán pasado a más de uno. Luego encima tenemos la dichosa mala suerte que si hay una profesión con intrusión es la nuestra.

Calentico que vengo esta semana…

Webs compatibles con SmartPhones

Los smartphones, sí esos cacharritos que aunque han credido en tamaño siguen siendo móviles, están cada día más presentes en nuestras vidas. El parque de este tipo de terminales ha crecido como la espuma después de que Apple con su famoso iPhone y RIM con Blackberry empezaran a acaparar el mercado gracias a terminales cada vez más asequibles y que “nos hacen la vida más fácil”. Atrás quedó la hegemonía de marcas como Nokia a la que nadie parecía poder toserle en la cara y el desplome absoluto de otras marcas que ya parecían estar casi moribundas como Motorola.

El nuevo concepto de teléfono móvil del siglo XXI no se parece en nada a los de principios de siglo. Recordad que solo han pasado 12 años desde que en el año 2000 solo la mitad de la población española tenía un terminal móvil y que los que lo tenían alucinaban con terminales que hacen “pipipipipopo” como tomo de llamadas con pantallas minúsculas monocromáticas. Marcas como Alcatel, Nokia y Ericsson (antes de ser Sony-Ericsson) eran las que mandaban. ¿Y tanto ha cambiado la cosa en 12 años? Y tanto… los terminales empezaron a empequeñecerse. La moda era que cuanto más pequeño era el teléfono, más “portátil” era y por lo tanto “más chic”, hasta que RIM sacó su primera Blackberry y poco tiempo después Apple le puso las cosas duras con el primer iPhone.

De “navegar”, y lo pongo entre comillas porque aquello más que navegar era una broma, usando la tecnología WAP en los primeros móviles con GPRS, amén de los sablazos que metían las compañías en aquel entonces por usar transmisión de datos por la red GSM, hasta los primeros navegadores que traían las blackberrys, que se parecían más al Lynx de Unix/Linux que otra cosa hemos llegado a terminales como los de hoy en día, que poco tienen que envidiar a los de sus hermanos mayores en los ordenadores de sobremesa. En los terminales con Android podemos instalar Firefox. Apple diréctamente hizo una versión de Safari para su terminal (El navegador que llevan por defecto los Macs y que también está para Windows). Sin embargo todavía hoy en día existe un “pequeño problema”. La pantalla.. No podemos comparar una pantalla de un móvil que por lo normal suele trabajar a 320 o 480 pixels de ancho con una de un ordenador que empieza a moverse medio bien a 1024 y más teniendo en cuenta que la resolución más estándar en nuestros días es tener 1280 pixels de ancho en casi todas las resoluciones de monitor, ya sean en 4:3 o en 16:9.

Para poder hacer una aplicación que sea 100% compatible con un smartphone móvil tenemos varias opciones:

  • Primera: Pasar ligeramente de todo y hacer una web que se muestre bien pero que haya que estar haciendo zoom (típico gesto de los usuarios de iPhone con los deditos para ampliar o alejar la pantalla)
  • Segunda: Hacer una rutina en JavaScript o PHP/ASP/Ruby/… que detecte qué tipo de terminal tenemos y nos redirija a una versión para móviles de la web en cuestión. Esto es bastante típico hoy en día en periódicos online.
  • Tercero: Hacer una versión híbrida que detecte el móvil y “adapte” la web, normalmente mediante JavaScript, para que salga corréctamente con la resolución de un smartphone. Esto puede ser por ejemplo quitar div’s laterales tipo menús, o información que se pueda colocar en otro lado de la pantalla y que de esta forma el texto no se desplac

Sea cual sea la versión que escojamos está claro que lo suyo es la segunda o tercera opción. Muchos usuarios lo agradecerán. Por mi parte las primeras pruebas las estoy haciendo con la segunda, más que nada porque me permite aprender de una forma más ordenada y cuando ya esté todo avanzado quizás una tercera versión nos ahorrará reescribir código innecesario. Sin embargo, como lo primero es aprender allá vamos.

Primeramente habrá que detectar que estamos usando un móvil, ¿cómo? He aquí las diferentes variantes:

JavaScript:

Se podría mejorar, pero por lo normal nos interesará saber, mediante la propiedad navigator.userAgent el tipo de navegador que está usando. En dicha propiedad con buscar iphone, android, o lo que nos interese sería suficiente para detectar al smartphone. El siguiente código es una buena prueba de ello:

<script type=”text/javascript”>
var navegador = navigator.userAgent.toLowerCase();
if( navegador.search(/iphone|ipod|android/) > -1 ){
document.location = ‘https://miversionparamoviles.com’;
}
</script>

Evidentemente la búsqueda en userAgent podemos extenderla más usando palabras como blackberry,palm, etc…

PHP:

if (eregi( ‘ipod|iphone|android|opera mini|blackberry|palm os|windows ce’, $_SERVER[‘HTTP_USER_AGENT’] )) {

código aquí….

}

Ya sabemos cómo detectar que usamos un móvil, ahora prepararemos nuestra web:

Las webs para SmartPhones suelen estar preparadas según XHTML, sin embargo por lo normal suelen trabajar bien en cualquier tipo de código que sea estándard a W3C. Sin embargo para evitar problemas de compatibilidad prepararemos nuestro DOCTYPE según dicho acuerdo. Para comenzar nuestra cabecera se debe de preparar de la siguiente manera:

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “https://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>
<html xmlns=”https://www.w3.org/1999/xhtml” id=”v1.06″ xml:lang=”es” lang=”es”>

Esto evitará más de un susto a más de uno. Ahora viene lo realmente interesante. Queremos que sea 100% compatible con smartphones. Lo primero de todo es evitar que se pueda hacer zoom y cosas raras que los usuarios suelen hacer cuando no se ve bien una web porque o salen las letras muy pequeñas o todo lo contrario. ¡Por supuesto contamos con que haremos las pruebas en un smartphone a medida que vayamos haciendo nuestro proyecto! Toda esta magia la hace el llamado ViewPort. ViewPort es una propiedad que pasaremos a través de un METATAG al navegador y al mismo tiempo también define la visión que va a tener el smartphone. Llamamos viewport a la parte visual que tiene la pantalla del smartphone. De momento para mis pruebas he utilizado el siguiente:

<meta name=”viewport” content=”width=device-width, initial-scale=1, maximum-scale=1″ />

Esta línea modifica el viewport del smartphone y le indica que se ajuste en forma vertical a la resolución de nuestro smartphone y al msimo tiempo que la escala de visualización sea 1. Esto es importante porque imaginaos que haceis una aplicación web y que en un iPhone se ve de maravilla pero que en una Blackberry se viera realmente pequeña. Con “tocar” estos valores, poniendo el valor initial-scale a otro mayor ampliaríamos la visión del viewport, por poner un ejemplo, aunque se puede hacer de muchas otras maneras.

Sigamos…

<meta content=”text/html; charset=UTF-8″ http-equiv=”content-type” />
<meta http-equiv=”cache-control” content=”no-cache” />
<meta http-equiv=”cache-control” content=”no-store” />
<meta http-equiv=”cache-control” content=”max-age=0″ />
<meta http-equiv=”cache-control” content=”must-revalidate” />

Estos meta son realmente interesantes. El que no hay que olvidar nunca poner es que indica el content-type. Los navegadores para SmartPhones trabajan en codificación UTF-8. Algunos son compatibles con el estándar ISO-8859-1 que usamos en España, pero es mejor no arriesgar. Los siguientes indican que no se utilice caché, de esta forma evitaremos problemas a la hora de recargar la página ya que a fin de cuentas un smartphone NO ES UN ORDENADOR.

y finalmente ya podemos empezar con nuestro código..

<body> Blabvlablablablbll </body>

Hay que tener cuidado en no usar cosas especialmente raras, por ejemplo, las tablas de las que se ha abusado tanto en el pasado para maquetar corréctamente las webs tienen poco sentido gracias a los bloques (divs) de los que se disponen de hoy en día.

Se pueden usar CSS sin ningún tipo de problema, al menos los que yo he probado, pero hay que intentar no usar propiedades demasiado nuevas o “extrañas” que sean útiles en navegadores modernos para hacer algún truco poco documentado.

Google ¿social?

Recientemente he estado “trasteando” un poco con el nuevo invento de Google, conocido como Google+. La verdad es que pensé en un primer momento que iba a ser algo como Waves, que pasaría prácticamente sin pena ni gloria por la red, sin embargo empiezo a sorprenderme al ver en muchísimas páginas donde se coloca el ya más que conocido “Me Gusta” de Facebook el iconito “+1” de Google+, que viene a ser algo “parecido”. Si esto se está poniendo, digo yo que será porque funciona…

Ni corto ni perezoso entro en mi cuenta Google/Gmail y abro la parte de Google+. Actualizo mis datos y ¿qué nos encontramos? A primera vista se parece a Facebook, eso sí, algo menos cargado y con un estilo que me recuerda enormemente a GMail, es decir: simplicidad, limpieza y orden, pero lo que es más importante y Google nos tiene acostumbrados: ¡¡ES RÁPIDO!! Las páginas cargan que es una barbaridad, casi instantáneo. Pero… ¿y cuál es la diferencia con el resto de redes sociales? Veámoslo..

Imaginad por un instante que cogéis Facebook y Twitter, los meteis en una batidora, aderezais con un toque de GMail y volcais todo en un plato. Os saldrá algo seguramente muy parecido a Google+. La primera diferencia es que Google+ tiene algo llamado CÍRCULOS. Un círculo es un conjunto de personas. Este conjunto pueden ser tus amigos personales, familia, conocidos, personas que no conoces pero te gustaría seguir (Twitter??), etc…  De esta forma podemos digamos personalizar qué datos serán visibles ya que cuando hacemos una publicación podemos definir si queremos que lo vea un círculo, varios, todo el mundo, etc.. Realmente interesante.

Otra característica interesante es que a diferencia de Facebook, donde podemos aceptar o denegar solicitudes, lo que se hace es “Seguir” a la gente, como ocurre en Twitter, salvo que en Twitter no podemos comentar diréctamente un muro, sino un Twit, pero aquí podemos comentar una publicación diréctamente en un muro. Es complicado de explicar, casi que hay hasta que verlo. ¿Y si alguien se pone pesado? No hay problema, se puede bloquear, denegar el acceso, etc, por lo que el tema de la privacidad está más que solventado.

Realmente desconozco si Google+ tendrá el impacto social que Google espera, ya que Internet empieza a estar saturado de redes sociales. En España recordemos que también tenemos Tuenti, y que a pesar de que ha perdido empuje en el último año en favor de Facebook no deja de estar ahí. Twitter empieza a arrasar abanderado por los medios de comunicación y personas públicas que ven en él la manera ideal de hacer llegar sus mensajes y/o información. El tiempo, como siempre, lo dirá.

La recompensa de hacer las cosas bien

En anteriores posts he dejado patente mi gran agrado en el uso de la orientación a objetos y el que debido a las locuras que ocurren cuando uno trabaja bajo un enorme stress se llegan a hacer auténticos disparates para llegar a tiempo.

Por suerte para mí por fin he conseguido entregar un proyecto que está realizado 100% en OOP y que utiliza mi queridísimo lenguaje PHP5. Las mejoras no se han hecho esperar. Tras presentar esta mañana el proyecto en cuestión se me han pedido hacer una serie de cambios/mejoras a nivel de funcionamiento (filtros en los informes, algún que otro botón adicional, etc..). Por suerte para mí el haber realizado todo en base a objetos me ha permitido que para hacer estos cambios solo hubiera que abrir la clase en cuestión de la que depende el formulario, y “toquetear” el código del que depende.

Está claro en que de aquí en adelante el futuro va en esta línea. A veces vale la pena perder un poco de tiempo en definir corréctamente las clases, métodos y variables privadas, y sobretodo el definir bien los métodos de acceso con nomenclatura adecuada. Ahorraremos muchísimo código, reutilizaremos nuestras rutinas un disparate, pero sobretodo es importantísimo, y más que nunca, el análisis previo al desarrollo para poder crear todo de una forma coherente.

Clases y objetos en PHP5. Flexibilidad para el programador

Desde prácticamente mis tiempos universitarios he sido un fiel seguidor de las tendencias en lo que a programación orientada a objetos se refiere, sin embargo, debido a mis labores como currante perdí el hilo durante unos años y cuando de nuevo me tuve que poner a programar después de todos estos años dedicándome únicamente a a la administración de sistemas me encontré con que mi cabeza estaba oxidada en cuanto a los buen haceres de una programación bien estructurada, por no hablar de la correcta utilización de los patrones de la programación orientada a objetos. El resultado podía haber sido peor de lo que yo me hubiera imaginado. Mis scripts en PHP realmente funcionaban bien (utilizaba el estándard PHP4 aunque ya corría PHP5 en mis servidores) pero la estructura interna de los mismos era de ese tipo que cuando un programador medianamente experimentado los ve se hubeira caído de espaldas del susto.

En fin, para los siguientes proyectos intenté organizarme mejor y la verdad es que todo empezó de maravilla hasta que lo de siempre, la fecha objetivo se acercaba y el sprint final hace que tengas que tomar una decisión salomónica, sacrificar la estructura y buen hacer en detrimento de acabar el proyecto “como sea”. Sin embargo por fin las cosas han cambiado, y he conseguido empezar a hacer un proyecto desde el principio utilizando clases y objetos en PHP para la casi totalidad de mis scripts y sinceramente ¡¡qué gozada!! Tras ver cómo van evolucionando mis clases y objetos, y sobretodo que interrelacionan entre sí en un código limpio y de fácil comprensión me pregunto, ¿pero cómo es posible que te pase siempre lo mismo?

Bromas a parte, a continuación os muestro un par de ejemplos de cómo crear objetos y clases en PHP5, que PHP5 incluso permite crear clases estáticas y llamarlas desde cualquier parte del programa. En fin… que después de ver esto me pregunto ¿realmente hace falta Java/JSP para crear webs dinámicas existiendo PHP5? ¿¿¿Cómo es posible que haya aún gente que se interese por ASP/ASPX???

Ejemplo de una clase en PHP:

class miClase {
private $miVariable;
function __construct($param) { /* el constructor en PHP5 se define como __construct */
$this->setVariable($param);
}
function setVariable($param) {
$miVariable = $param;
}
function getVariable() {
return $miVariable;
}
}

Ya tenemos creada una fantástica clase donde guardaremos, y de forma privada, un atributo (variable) que será accedido mediante los métodos que sí que serán públicos. Con esto conseguimos cumplir una de las premisas de la programación orientada a objetos, la encapsulación.

¿Y se puede hacer herencia? Y tanto…

class miOtraClase extends miClase {
function otraFuncion() {
print “Esto se imprime desde otra funcion”;
}
}

¿¿Y cómo creamos objetos?? Tan sencillo como esto…

$miObjeto = new miClase(“Pepito”);
echo $miObjeto->getVariable();
$miObjeto->setVariable(“Joselito”);
echo $miObjeto->getVariable();
$miOtroObjeto = new miOtraClase(“Pepote”);
echo $miOtroObjeto->getVariable();
$miOtroObjeto->otraFuncion();

Y el resultado sería…

Pepito
Joselito
Pepote
Esto se imprime desde otra funcion

Evidentemente este es un ejemplo sencillísimo, pero en cuatro líneas como se suele decir se puede ver que a este lenguaje no le hace falta ¡¡de nada!!

¡Java y XML se entienden!

Hace un par de semanas tuve que ponerme de nuevo manos a la obra en algo que había tocado poco o prácticamente nada. El mayo de mis problemas es que llevaba casi dos años sin tocar el lenguaje Java y aunque PHP se le parece no deja de ser solamente eso, que se le parece… pero ni de lejos llega a ser completamente el mismo lenguaje.

La historia es la siguiente. Desde hace ya bastante tiempo veníamos usando un programita que nos hicieron en su día en VisualBasic, que para colmo de males no tenemos ni el código fuente, que cogía los teletipos que provenían de una agencia de noticias en formato XML y los traspasaba, previamente habiendo sido analizados, a una base de datos. El problema vino cuando dichos teletipos cambiaron internamente el formato. El programa no los reconocía. Ni corto ni perezoso abrí mi queridísimo Eclipse, instalé nuevamente el compilador de Java y ¡¡a trabajar!!

La primera decisión, ¿qué librería usaremos para leer los XMLs? En fin, tiré de biblioteca universitaria desempolvando mis viejos apuntes de carrera de cuando programar en Java era algo que tenía que hacer todos los días y… entonces recordé aquellos “maravillosos” momentos en los que SAXBuilder me tuvo un día hasta cerca de las 3:30 de la madrugada para poder hacer una práctica. Como se suele decir, más vale malo conocido que bueno por conocer, así que está claro que si en su día funcionó, ¿por qué no lo va a hacer otra vez?

Tras unas cuantas horas comiéndome el coco la verdad es que la historia quedó bastante elegante. Os dejo aquí un par de funciones que he implementado, ya que incorporar a esta entrada del blog el programa entero sería un absurdo y lo interesante es que se vea lo sencillo que es recorrer un XML en Java una vez que se conoce la estructura interna del mismo.

Comencemos con el programita…

import org.jdom.Document;
import org.jdom.Element;
import org.jdom.input.SAXBuilder;

Para leer un archivo XML dado se debe de hacer de la siguiente manera. Primeramente se crea un objeto de clase SAXBuilder que será donde cargaremos el XML. A continuación leemos el archivo desde el disco utilizando el objeto creado y pasándole como parámetro la ruta del archivo que deseamos analizar. Finalmente se crea un objeto de clase Element (¡sí! ¡Element! ¡Viva lo genérico!) y mediante el método getRootElement tendremos ya lista la raíz del archivo XML para empezar a trabajar.

SAXBuilder builder = new SAXBuilder();
Document doc=builder.build(“c:midirectorioarchivo.xml”);
Element e = doc.getRootElement();

¿Y ahora qué hacemos con todo esto?

Imaginemos que nuestro xml internamente tuviera algo así..

<raíz>

<identificador>12345</identificador>

….

</raíz>

… y quisiéramos leer lo que hay en identificador. Una forma un tanto “animal” sería la siguiente:

encontrado = false;

List<Element> elementos = e.getChildren();
Iterator i = elementos.iterator();
while ((i.hasNext()) && (!encontrado)) {
Element e2 = (Element) i.next();
String texto = e2.getName();
if (texto == “identificador”) {
String identificador = e2.getText();
encontrado = true;
}

y en nuestra variable identificador tendriamos el texto que hay en la etiqueta <identificador> del XML.

Otra forma un tanto más elegante de hacerlo, y que conste que el código se podría mejorar muchísimo más pero que conste que es un simple ejemplo, sería la siguiente…

public static Element getSubNodo(Element e, String subnodo) {
List<Element> elementos = e.getChildren();
Iterator i = elementos.iterator();
while (i.hasNext()) {
Element e2 = (Element) i.next();
String texto = e2.getName();
if (texto == subnodo)
return e2;
}
return e;
}

public static String buscarIdentificador(Element e) {
        String devuelve = “”;
        Element nodo = getSubNodo(e, “identificador”);
        devuelve = nodo.getText();
        return devuelve;
    }

Y la llamada sería:

String identificador = buscarIdentificador(e);

Pues con estas dos bonitas funciones y un par más de mi cosecha que buscaban aún más “hondamente” dentro del XML se pudo leer sin problemas el XML en cuestión, quitando de un plumazo un programa hecho en el horrible, vetusto y anticuado VisualBasic por algo más decente y moderno como es una aplicación hecha en Java.

Buscar o no buscar, el caso es que sea rápido

Hace unos cuantos meses terminé de desarrollar un proyecto de Hemeroteca digital para el medio de publicación para el que trabajo que sinceramente, me dejó más que satisfecho porque por una vez en la vida he podido programar a mis anchas, sin grandes presiones de tiempo. Muchas veces esas dichosas presiones hacen que uno empiece a volverse loco y tu código fuente, sea cual sea el lenguaje que en el que uno esté programando, se convierta más en un cutreprograma tipo Basic de los que solíamos hacer al principio de los tiempos cuando nadie nos había explicado lo que era la programación estructurada. Este proyecto unificaba lo mejor de mis conocimientos en PHP5 y amplió hasta nuevos horizontes cosas muy peculiares que he descubierto que se pueden hacer en JavaScript y por supuesto añadir una dimensión desconocida a JQuery, una maravilla que cada día me sorprende más.

Y sin embargo todo tiene un “pero”… El sistema de búsquedas basado en MySQL parecía ir a las mil maravillas cuando en las primeras pruebas solo teníamos 5 o 6 años de publicaciones hechas, pero cuando se hizo la indexación de todo nuestro fondo editorial (65 años) la cosa ya no era lo que parecía. Descubrí que las búsquedas Full-Text de MySQL no eran nada del otro mundo, de hecho funcionan muy pero que muy bien usando una o dos palabras, pero como se nos ocurra hacer una búsqueda “tipo Google”.. en fin… puede ser que tengamos suerte y tarde 3 segundos la búsqueda o que tarde perfectamente un minuto. ¿Cómo es posible? Mi gozo en un pozo… pero como hay remedio para todo, o eso espero hoy me he propuesto intentar hacer pruebas con Lucene.

Lucene es un motor realizado por Apache Group y que como todo lo que sale de esta gente es lo más de lo más. El primer problema con el que me he encontrado es que está originalmente hecho para Java, ¡pero tranquilidad! ¡Hay versiones ya para todo! Ruby, PHP, Python, etc…

Probemos pues y veamos en qué acaba el asunto….

Haciendo caso a mis amigos…. ¡creando un blog!

En un mundo cada vez más estrechamente ligado a las nuevas tecnologías y con un empacho de sobreinformación cada vez más acusado no se me ocurre otra cosa mejor que crear un Blog. Tras escuchar una y otra vez comentarios de mis amigos que una y otra vez me aconsejaban de las bondades de estos medios fue el señor Carlos Blé, hace dos días, que finalmente me dió el empujoncito que me faltaba para dar el salto, y esperemos que no precisamente al vacío.

Desde aquí os invito ya a que visitéis de vez en cuando este pequeño oásis en medio de la locura que es Internet. Veremos en qué se termina convirtiendo.