Últimas tecnoloxías

SVN commit from perl script

2008-11-26T06:44:00.000-08:00

Although SVN is getting dead due GIT expansion, there are a lot of projects that still use it, like the one I'm involved.

In order to make commits easier I've developed this perl script. You can get it from sourceforge:

http://sourceforge.net/projects/utils/

Programming tip

2008-11-07T16:48:00.000-08:00

Commonly, we have to compare constants with variables. Traditionally, it is achieved like that:

if (variable == CONSTANT)
{
...
}

But this is a common source of errors. If we write '=' instead '==', compilation will be achieved correctly, but execution maybe crash.

In order to avoid this problem, the first member of the comparison must be the constant:

if (CONSTANT == variable)
{
...
}

This way, if we forget one 'equal' a compilation error will arise.

Coming back!

2008-11-02T06:28:00.000-08:00

How a long from my last post!!

This time I've been working on HED (Home Entertainment Device), now renamed as Blu:Brain and finishing the Free Software Master.

Then I have to tell a lot of interesting things related these issues. Taking into account this is a personal blog, next posts will be related to the second one.

To start with this review, I show you the new appearance of GMyspace:

As you can see, it is too closed to an useful application :)

See you!

GMySpace source code committed

2008-08-17T14:44:00.000-07:00

GMySpace has been accepted as project in SourceForge.net. Next step has been to upload source code to SVN repository.

Currently, project is in an ALPHA development stage, but next milestone is too near. Then, BETA version will be released.

You can browse source code:
http://gmyspace.svn.sourceforge.net/viewvc/gmyspace/trunk/

[1] http://sourceforge.net/projects/gmyspace/

GMySpace en Sourceforge

2008-08-09T11:45:00.000-07:00

Como todo proyecto que se precie (de software libre of course) GMySpace estará disponible en breve en SourceForge. Lo he dado de alta y ahora está en estado "Pending" a la espera de ser aceptado por los administradores.

Por lo pronto, la página ya existe, aúnque vacía de contenidos. Es la siguiente:

http://sourceforge.net/projects/gmyspace/

Testear software y JUnit

2008-07-17T14:44:00.000-07:00

Bueno... rompiendo un poco con la monotemática GNOME que llevaba últimamente, voy a hacer un pequeño inciso. Ayer, mientras paseaba por Santiago de Compostela (eso sí, después de varias horas peleádome con GLib) me fui a dar un paseíllo con mi compañero de piso. Teníamos varios puntos de paso obligados y uno de ellos era Follas Novas que, para quien no la conozca se trata de una librería enooooooooooorme de la cual, alguien del mundo de la cultura cuyo nombre no recuerdo dijo que se trataba de la otra obra de arte de Santiago (o algo así), al mismo nivel que la catedral.

El caso es que, como de costumbre en las librerías, me fui a la sección de informática y lo vi. Allí estaba esperándome. Entre una pared llena de libros de todo tipo encontré uno que hablaba de cómo probar software usando JUnit[6] como caso práctico. Me llamó la atención desde el principio ya que, como algunos sabéis, la ingeniería del software[5] es uno de los temas que más me gustan. Después de haber estudiado y probado diversos aspectos de esta rama, como las metodologías (eXtreme Programming[4] o Scrum[2, 3], con la que me peleo todos los días en el trabajo), patrones de diseño, paradigmas, etc., las metodologías de prueba era una de esas cosas que tenía pendientes.

El libro en cuestión es: "Pruebas de software y JUnit"[1] de Pearson-Education.

[1]http://www.pearsoneducacion.com/resultado.asp?ean=9788483223543
[2][PDF]http://www.navegapolis.net/files/Flexibilidad_con_Scrum.pdf
[3]http://es.wikipedia.org/wiki/Scrum
[4]http://www.extremeprogramming.org/
[5]http://ultimastecnoloxias.blogspot.com/search/label/Ingenier%C3%ADa%20del%20Software
[6]http://www.junit.org/

GMySpace. Arquitectura

2008-07-13T03:53:00.000-07:00

El siguiente esquema muestra la arquitectura de la aplicación GMySpace

Como vemos existen dos zonas claramente diferencias: backend y frontend. El frontend se encarga de la presentación de los datos al usuario; dejando para el backend las tareas de obtención y almacenamiento de la información. Esta separación en capas tiene una serie de consecuencias:

Permite la realización de distintas aplicaciones de frontend de manera sencilla, ya que no existe acoplamiento con el backend: se accede al mismo a través de una API.
Se puede cambiar el mecanismo de descarga y/o parseo sin que ello suponga cambio alguno para las aplicaciones de frontend.

Por otra parte, cabe destacar la inclusión de una capa de abstracción sobre la base de datos. Esto se debe a un motivo principalmente: independizar la aplicación del motor de base de datos empleado.

En breve se liberará el código del backend, que está casi terminado y algún boceto inicial del frontend :)

GnomeVoiceControl. Primer contacto (y II)

2008-07-13T02:40:00.000-07:00

En el último post[1] sobre GnomeVoiceControl comentaba que tuviera dos problemillas con la instalación:

GnomeVoiceControl es un applet, con lo cual está controlado por Bonobo y éste debe saber donde encontrarlo.
Como el objetivo de la aplicación es controlar el escritorio, se hacen continuamente llamadas de acceso al mismo. Para que esto funcione deben estar activadas las opciones de accesibilidad que, en mi caso, no lo estaban.

Básicamente se deben a mi ignorancia.

El problema número uno se puede solucionar de dos maneras básicamente:

Instalar la aplicación (applet) en un directorio conocido. Esto es, en un directorio en el cual Bonobo busque por defecto, por ejemplo: /usr/libexec/. Esto se consigue con el parámetro 'target' en el configure: ./configure --target=/usr/libexec
Establecer la variable de entorno que usa Bonobo para buscar los applets. De esta manera dejamos que el instalador lo instale donde quiera (esto es, la configuración por defecto del configure) y con dicha variable actualizada correctamente Bonobo tiene acceso a la aplicación.

Para el segundo problema también existen dos soluciones:

Desde el escritorio, activar las opciones de accesibilidad:

System-> Preferences -> Assistive Technologies Preferences y una vez ahí activar el checkbox "Enable assistive technologies"
Ejecutar /usr/lib/at-spi-registryd

En realidad fui capaz de instalarlo gracias al Carlos GC[2] que, vía chat, me iba explicando estas cosillas.

[1]http://ultimastecnoloxias.blogspot.com/2008/06/gnomevoicecontrol-primer-contacto.html
[2]http://carlosgc.linups.org/

GMySpace

2008-06-29T15:58:00.000-07:00

Durante todas las asignaturas del máster, y especialmente en las de la asignatura de "Desarrollo con Software Libre" he tratado de estudiar y trastear un poquillo, según correspondiese, con los contenidos adquiridos. Algunas de esas pruebecillas las he publicado en el blog, pero otras, la mayoría no.

En su día, cuando dimos programación en Bash y tecnologías relacionadas como sed o awk hice un pequeño script muy útil (al menos para mi). Se trataba de un párser de las páginas de myspace.com. Lo que hacía era quedarse con la información relativa a los conciertos de cada uno de los grupos que yo le indicaba. La verdad es que no fue fácil, en parte por mi inexperiencia pero también por el código html tan feo con el que está hecho este portal.

La intención inicial era realizar una aplicación que tuviera como base dicho párser para que mostrase la información de conciertos de tus grupos favoritos de manera amigable. Pero... el máster siguió avanzando y dimos otros contenidos que también tuve que ir probando (ya lo explicaré en entradas posteriores) para no quedar atrasado (sin olvidarnos del resto de obligaciones, como el trabajo :s).

Ahora bien, una vez que hemos profundizado más en el estudio de GNOME como plataforma de desarrollo y siendo esta la que he elegido para el desarrollo del prácticum, he retomado el tema del párser de MySpace. Los motivos han sido fundamentalmente:

La utilidad de la aplicación
Profundizar en el conocimiento de GNOME

A falta de un diagrama que muestre el funcionamiento de la aplicación, explicado de palabra sería algo así: "GMySpace es una aplicación que se descarga la información de conciertos de tus grupos favoritos y te la muestra en una aplicación de escritorio con interfaz gráfica. Dicha información se descarga periódicamente o a petición del usuario y se almacena en una base de datos. La GUI se construye a partir de la información almacena en dicha BBDD y de las preferencias del usuario (ver conciertos de un grupo o de todos, ver conciertos entre dos fechas dadas, ver en formato calendario o en forma tabular, etc)". Para ello, las tecnologías usadas son:

sed, awk, para parsear la página descargada
sqlite, como BBDD
GTK+, para la GUI

Como mi lista de TODOs va bajando (lentamente, pero bajando), en breve podré centrar todos mis esfuerzos en el prácticum con lo que mis conocimientos de GNOME se verán ampliados y podré realizar más aportaciones a GnomeVoiceControl. Entretanto, y como complemento, trataré de dar forma a lo expuesto en esta entrada.

GnomeVoiceControl. Primer contacto

2008-06-26T10:37:00.000-07:00

Un mes sin postear pero no un mes sin trabajar. Más bien todo lo contrario. Han sido (y son) varios los frentes abiertos que es difícil afrontarlos todos de manera sólida y más difícil aún tener tiempo para relatarlos en el blog. Para no perder el hilo, a continuación expondré como va lo concerniente a GNOME y en concreto a GnomeVoiceControl.

Primer contacto
Lógicamente, lo primero a realizar fue descargarse el código para su posterior compilación y ejecución. Para ello accedí al SVN para, así, obtener la última versión en desarrollo:

svn checkout http://svn.berlios.de/svnroot/repos/festlang/trunk/gnome-voice-control

Además, es necesario descargase también las siguientes librerías:

pocketsphinx: http://cmusphinx.org/download/nightly/pocketsphinx.nightly.tar.gz
GStreamer development packages: gstreamer-devel gstreamer-plugins-base-devel http://gstreamer.freedesktop.org
GNOME development packages: libwnck-dev, libatspi-dev, gnome-panel-dev startup-notification-devel: http://gnome.org
GNOME build system: libtool gnome-common intltool http://gnome.org
libnotify: http://www.galago-project.org/news/index.php

Una vez que tenemos todo instalado solo queda probarlo. Pero esto no fue trivial por varios motivos:

GnomeVoiceControl es un applet, con lo cual está controlado por Bonobo y éste debe saber donde encontrarlo.
Como el objetivo de la aplicación es controlar el escritorio, se hacen continuamente llamadas de acceso al mismo. Para que esto funcione deben estar activadas las opciones de accesibilidad que, en mi caso, no lo estaban.

[to be continued...]

GNOME

2008-05-26T16:07:00.000-07:00

Antes de entrar en la descripción de gnome-voice-control creo necesario echar un vistazo a la plataforma GNOME, sobre la cual se desarrolla la aplicación.

Lo primero que hay que decir es que el lenguaje de programación es C (a diferencia de otras plataformas donde se eligen lenguajes de alto nivel , como C++ en KDE[1] o C# en MONO[2]). Hablar de C siempre asusta un poco. Se asocia a trabajar a bajo nivel sin mucha más ayuda que la agudeza de cada cual. Ahora bien, la eficiencia en tiempo y espacio lograda en dicho lenguaje no es equiparable a ningún otro, la cual ha sido siempre la principal baza de C ante el resto de alternativas. ¿Compensa dicha eficiencia la complejidad del lenguaje? No es este el momento ni el lugar para ese debate, sino para mostrar como en GNOME se ha solucionado el problema de la complejidad... [entonces... sin complejidad ni pérdida de eficiencia... estamos ante el lenguaje perfecto? :|].

Una de las principales carencias de C es proporciona unas estructuras de datos muy pobres, así como las herramientas para procesarlos. Esto se soluciona en GNOME con la librería GLIB que, concretamente ofrece:

Tipos abstractos de datos (listas, colas, hash table...)
Manipulación de cadenas
Memory allocation
Dynamics loadable modules
Abstracción del bucle principal
Expresiones regulares

Por otra parte, otra carencia fundamental de C es su NO orientación a objetos. Pero esto también tiene solución, GObject. Por último, tenemos GIO, que proporciona una abstracción sobre el sistema de ficheros de manera que las aplicaciones pueden manipularlos independientemente de su localización física

Estas tres, (Glib, GObject y GIO) en la práctica, se consideran un solo bloque que, por extensión, se denomina Glib, tal como vemos en la figura.

A continuación se explican brevemente cada uno de los componentes de la arquitectura GNOME. Sobre la figura, únicamente destacar que aquellos componentes con fondo azul están marcados como DEPRECATED, con lo cual no se aconseja su uso ya que serán suprimidos en futuras versiones del framework. Esto no es ningún obstáculo ya que su funcionalidad ha sido implementada o absorbida por otros componentes.

Siguiendo con la figura observamos que, al mismo nivel de Glib tenemos:

Cairo, encargada de pintar en el dispositivo de salida
D-Bus, un bus de comunicación entre aplicaciones. Se trata de un sistema IPC de alto nivel, similar a CORBA[3], pero más sencillo.

Sobre esta capa inferior se asientan todo un conjunto de librerías:

GDK, relacionada con el sistema gráfico. Se trata de una capa intermedia que emplea GTK+ (creación de widgets) para acceder a Cairo abstrayendo los detalles característicos de cada tipo de ventana.
ATK. API de accesibilidad.
Pango. Librería para el manejo de fuentes y texto.
GVFS
GNOME-VFS
Libbonobo. Se trata de un framework para la creación de componentes independientes. Está planeada su desaparición, si bien, en la práctica, se sigue usando.

La siguiente capa tiene cuatro módulos:

GTK+. Para construír interfaces gráficas
LibGnome
Gconf, donde se guardan las opciones de configuración de cada usuairo del sistema.
AT-SPI. Proporciona interfaces usadas por las tecnologías de accesibildad

Seguimos:

LibGlade. Para construír interfaces gráficas a partir de descripciones XML
Gail. Es una implementación de las interfaces ATK
LibBonoboUI. Controles de UI para crear componentes BONOBO

Y arriba de todo,

LibGnomeUI. Widgets para aplicaciones. La gran mayoría ya han sido portados a GTK+.

Este post no es más que corta+pega+adapta un poquillo de:

la documentación de gnome[4]
apuntes[5] de GNOME de la asignatura de Desarrollo de Software Libre,[6] de Carlos García Campos[7]

Referencias:

[1] KDE, www.kde.org
[2] MONO www.mono-project.com
[3] CORBA www.corba.org
[4] Referencia de GNOME http://library.gnome.org/devel/references
[5] Apuntes de GNOME: http://gsyc.escet.urjc.es/moodle/mod/resource/view.php?id=497&subdir=/2008-03-07-gnome
[6] Asignatura Desarrollo de Software Libre, http://gsyc.escet.urjc.es/moodle/course/view.php?id=41
[7] Blog de Carlos García Campos: http://carlosgc.linups.org/

Prácticum. Elección de proyecto

2008-05-26T14:48:00.000-07:00

Tras la elección de la temática del prácticum y del conocimiento de las necesidades en el ámbito de la accesibilidad toca el momento de elegir un proyecto en el que trabajar o incluso proponer uno nuevo. Son varias las cuestiones a tener en cuenta:

Sistema Operativo

Linux
Windows
Independiente

Plataforma

Al margen de los requisitos técnicos del proyecto, es necesario delimitar bien el ámbito funcional del mismo. Esto es, cada disfunción tiene unas necesidades particulares, lo cual implica que la solución adoptada para paliarla deberá ser específica.

El máster ha estado organizado en distintas asignaturas o bloques. A estas alturas ya hemos pasado por:

En esta última aprendimos las distintas tecnologías y plataformas de desarrollo empleadas de forma mayoritaria. Entre todas ellas, la que más caló en mi fue GNOME. Así, será esta sobre la cual desarrolle mi aplicación.

Por último queda definir cuál será la aplicación concreta sobre la que trabajar. Como en todo proyecto, y especialmente los de software libre, la primera tarea es realizar un estado del arte con el fin de saber cómo están las cosas en el momento actual. Por suerte, en GNOME, viendo que la accesibilidad es un tema muy en boga en los últimos tiempos, han lanzado el programa GNOME Outrech[6], cuya finalidad es:

Incrementar la percepción de las cuestiones relacionadas con la accesibilidad y cómo estas se atañen a las aplicaciones informáticas.
Animar a trabajar en dichas cuestiones
Ayudar a la comunidad del software libre a mejorar su soporte para accesibilidad

Así,dentro del programa, se ha elaborado una lista de tareas a realizar, que podemos consultar en

http://live.gnome.org/action/edit/Accessibility/GetInvolved

Como vemos, se trata de una lista que recorre todos los campos relacionados con la accesibilidad, siendo de especial interés para mi el punto tres: Assistive Technology and Other Work, y más concretamente los puntos seis y siete dentro de éste:

Es decir, aquellas herramientas relacionadas con el habla, tanto a nivel de síntesis como de reconocimiento. Si recordamos el post anterior, una de las carencias manifestadas por las instituciones que trabajan en este ámbito era precisamente el "acceso al ordenador por voz", de ahí el interés en estos dos puntos.

Ahora bien, durante este proceso de elección de proyecto, los profesores del máster comentaron la existencia de una aplicación cuya finalidad era el control del escritorio GNOME por voz: GnomeVoiceControl[7]. Se trata de una aplicación aún en pañales, nacida en el GSoC 2007[8], y con mucho margen de maniobra. Después de echarle un ojo encontré en ella justo lo que buscaba. Resultó fácil la elección.

Referencias:

[1] Gnome: http://www.gnome.org
[2] KDE: http://www.kde.org
[3] Java: http://java.sun.com
[4] Mono: http://www.mono-project.com
[5] Asignaturas del máster: http://gsyc.escet.urjc.es/moodle/course/category.php?id=17
[6] Gnome Outrech: http://www.gnome.org/projects/outreach/a11y/
[7] GnomeVoiceControl: http://live.gnome.org/GnomeVoiceControl
[8] GSoC 2007 http://code.google.com/soc/2007/

Prácticum

2008-05-22T11:04:00.000-07:00

Como culminación del Free Software Master[1], los alumnos debemos realizar unas prácticas (o Practicum) con el objetivo de consolidar los conocimientos adquiridos, así como coger experiencia en proyectos de software libre reales.

Para ello tenemos dos opciones:

Realizarlas en una empresa de las que han colaborado en el master: Igalia[2], Trabe Soluciones[3], Grupo Libresoft de la Universidad Rey Juan Carlos[4] o Telefónica ID por medio del proyecto MORFEO [5]
Trabajar en un proyecto de software libre por nuestra cuenta

La primera opción implicaría dedicarse en exclusiva a ello; permitiendo la segunda compaginarla con otra actividad. Este último es mi caso, que tendré que compaginarlo con mi trabajo en Blusens[6].

¿Qué hacer?
Una de las características que define a los proyectos de software libre es que los hackers que participan en ellos hacen lo que les gusta: programar en las aplicaciones que les gusta mejorando y arreglando aquellas funcionalidades que más les gusten. Siendo esto así, el abanico de posibles proyectos en los que colaborar es inmenso. De esta manera la primera tarea para mi prácticum fue elegir sobre qué trabajar.

Esto que podría parecer complicado a primera vista no lo fue en mi caso, ya que desde hace tiempo he considerado que una de los principales objetivos de la tecnología en general (y de las TIC en particular) debería ser ayudar a la integración de personas con algún tipo de discapacidad.

Siguiendo por esta vía me puse en contacto con distintas instituciones (Discapnet [7], Ceapat[8], Fundación Once [9]) de este ámbito con la intención de obtener información sobre las carencias en la materia.

Entre las distintas opciones propuestas dos me parecieron de especial interés:

Acceso por voz al ordenador
Control de entorno a través de la voz.

La primera consistiría en poder disfrutar de las distintas funcionalidades proporcionadas por un ordenador usando solamente la voz en lugar de los habituales dispositivos de entradas, como el teclado o el ratón. Una aplicación de estas características ayudaría a las personas con discapacidades motrices.

En cuanto a la segunda, control de entorno a través de voz, es un pasito más allá de la primera. Se trata de poder controlar los distintos dispositivos con los que tratamos habitualmente en la vida cotidiana por medio de la voz. Esto implicaría tecnologías no estrictamente software con lo cual quizá excediesen el alcance del Máster (además que el tiempo del que dispongo es muy limitado).

Así que, una vez decidida la temática comenzó la búsqueda de un proyecto concreto... pero eso es cosa de otro post :)

Referencias:

[1] Free Software Master http://www.igalia.com/eventos/master/
[2] Igalia http://www.igalia.com
[3] Trabe Soluciones http://www.trabesoluciones.com/
[4] Libresoft http://libresoft.es/
[5] Proyecto Morfeo http://www.morfeo-project.com/
[6] Blusens http://www.blusens.com
[7] Discapnet - Portal de las personas con discapacidad http://www.discapnet.es/
[8] Centro estatal de autonomía personal y ayudas técnicas http://www.ceapat.org
[9] Fundación ONCE http://www.fundaciononce.es

Splitting terminal

2008-04-06T14:58:00.000-07:00

I'm an Emacs user and... I like split window into two or three panels in order to read some views at a time. I wonder if I could do the same with xterm... and... yes! I do! Terminator!

It's very useful when you are debugging a client-server application because you can see both programs at a time.

From:

http://www.go2linux.org/multiple-terminal-in-one-window-terminator-console

Official site:

https://launchpad.net/terminator/

Retrieving information from source code

2008-04-06T14:45:00.000-07:00

In the development stage of a program, usually we write debugging lines (yeah... debugging tools such as gdb[1] or valgrind[2] would be a more valuable option). But, when we work with very large programs, would be very useful knowing the file and line os source code where such debugging line is placed. This task can be achieve with the preprocessor directives[3]:

__FILE__
__LINE__

Example of use:

fprintf( stderr, "%s <%d>: %s\n", __FILE__, __LINE__, "some text");

[1] http://sourceware.org/gdb/
[2] http://valgrind.org/
[3] http://www.cplusplus.com/doc/tutorial/preprocessor.html

PyRenamer. Automatically renaming tool

2008-03-22T11:52:00.000-07:00

As you know, after taking photos for a whole day, we have to face to the hard task of classifying them. The most commonly task is renaming them accordingly people involved or whatever criteria.

Then, we start in a situation like this:
If we want to rename them, probably we'll have to write the same name a lot of times. Ex.:

A_Place_1.jpg
A_Place_2.jpg
A_Place_3.jpg
Second_place_1.jpg
...
Second_place_34.jpg

This is a hard task. It would be very simple with an automatically renamer tool. This way, I've developed this tool.

It is a simple Python application that renames all files between two ones in alphabetical order.

Example:

P1010085.JPG
P1010089.JPG
P1010093.JPG
P1010097.JPG
P1010101.JPG
P1010105.JPG
P1010109.JPG
P1010113.JPG
P1010117.JPG
P1010121.JPG

The emphatic ones will be rename:

renamer -s P1010093.JPG -e P1010113.JPG -n MyPlace

-s [start]*
-e [end]*
-n [new name]*
-c [initial counter value]

Fields with [*] are mandatory. Anyway, if you omit any of them, application will question you:
Above example will result:

P1010085.JPG
P1010089.JPG
MyPlace_0.JPG
MyPlace_1.JPG
MyPlace_2.JPG
MyPlace_3.JPG
MyPlace_4.JPG
MyPlace_5.JPG
P1010117.JPG
P1010121.JPG

Source code: [Download] [View]

KScope: beyond CScope

2008-03-19T07:37:00.000-07:00

Previos post I presented CScope[1], a code browser tool. Now, I write about KScope[2], a graphical user interface for CScope..

This tool give us a graphical representation from CScope data. In addition, it has edition capabilities. Next pictures[3] give a clear idea of its power.

[1] CScope, http://cscope.sourceforge.net
[2] KScope, http://kscope.sourceforge.net/
[3] KScope screenshots, http://kscope.sourceforge.net/sshots.shtml

Cscope: source code browser

2008-03-09T10:59:00.000-07:00

Sometimes we have to fight with third party code, maybe without any documentation. In addition, this code can be very scattered and intermingled. This way, reading it is a too difficult task. In this context, using code browsing tools is a good idea in order to explore the code easily. Among these ones, I know Cscope [1], a pattern and symbol browser for C language.

Installation
apt-get install cscope

Running from command line
The basic mode is execution from command line. After running cscope in the source code directory, it presents us the next query list:

As we can see these queries can answer a lot of questions. Answering them directly from source code would be a very difficult and boring task.

After querying, in the above corner, we can see the result. Moreover, if we press enter in a result line, we will enter in our default editor in order to edit the source code.

Integration with Emacs[2]
Command line isn't a friendly interface. If you want, you can use it, but there is a more powerfull way to use cscope: integrating with Emacs. Next, I describe the steps to do it:

1) Copy xcscope.el from contrib/xcscope in cscope tarball to any directory in emacs path (for instance /usr/share/emacs/site-lisp). If you have installed cscope with apt-get you can jump this step.

2) Add (require 'xcscope) to ~/.emacs o ~/.emacs.d/init.el

If you like, you can integrate it with Vi [2]

[1] Cscope homepage: http://cscope.sourceforge.net/
[2] http://www.linux.com/articles/114237?theme=print

Region filter. Version 1.2 released

2008-03-02T13:40:00.000-08:00

New way to invoke it. Following classical approach of the vast majority of commands, "pipe invoking" is available now!

Use:
./your_program | region.sh [params]

This way "file parameter" is omitted.

Source code: [Download] [View]

P.S.: behavior of previous version... a feature or a bug? :)

Region filter. Bash version

2008-03-02T08:56:00.000-08:00

Sometimes, we have to fight with very large programs with a lot of debugging lines too. Reading this verbose output usually is a very tedious task. Moreover, each moment we are interested in a little set of the output. This way, it would be very useful filter the big amount of information and then, get the interesting one.

For this task, I've written a short bash script. It cuts regions from a file. These region are delimited with start and end tags. Ex.:

[bla bla bla]
BEGIN
[interesting things]
END
[bla bla bla]

Moreover, more than one region can be defined:

[bla bla bla]
BEGIN
[interesting things]
END
[bla bla bla]
[more bla bla bla]
BEGIN
[very interesting things]
END

In addition, we can name the region

[bla bla bla]
BEGIN reg1
[interesting things]
END reg1
[bla bla bla]
[more bla bla bla]
BEGIN reg2
[very interesting things]
END reg2

This way, the bash script can filter the first region or the another one.

Command line
./region -f file [-b begin_tag] [-e end_tag] [-i id_tag]

Default values are:

begin_tag: BEGIN
end_tag: END
id_tag: [None]

Use:

your_program > output.txt
region -f output.txt

Source code: [Download] [View]

Montar dispositivos en Ubuntu

2008-02-28T04:43:00.000-08:00

¿Quién no se peleó alguna vez con ese pendrive que no se monta automáticamente? En el siguiente enlace se explican una serie de pasos a seguir. Muy interesante.

http://www.asturlinux.org/comunidad/MemoriaUSB

Como se intuye del título está enfocado a las memorias USB pero se puede extrapolar a otros dispositivos

Fosdem 2008

2008-02-26T02:35:00.001-08:00

El pasado fin de semana tuvo lugar en Bruselas el Fosdem (Free and Open Source Software developers' European Meeting). Se trata de uno de los eventos de Software Libre más reconocidos a nivel mundial y en él se dan cita los distintos roles involucrados en la materia, desde desarrolladores independientes hasta grandes empresas, pasando por grupos de investigación universitarios. Cada uno de estos expone los proyectos en los que participa, futuros desarrollos o nuevas tendencias en el mundo del Free Software.

Hoy en día la actividad en el Software Libre es frenética, de manera que para exponer los distintos proyectos en curso harían falta semanas. Como esto es inviable en un encuentro de varios días, la solución por la que optan los organizadores es la de realizar conferencias en paralelo, de manera que cada cual elija la que más le interesa. La 'concurrencia' se lleva a cabo por temática, esto es, las charlas en paralelo son aquellas que se engloban dentro de un mismo tema. De esta manera, los 'temas' en los que se dividen son:

Además de las conferencias y workshops en las que se engloban dichas actividades, también existe la posibilidad de realizar los exámenes de las certificaciones LPI (Linux Professional Institute) y BSD.

Por último, destacar que había un gran número de stands de organizaciones vinculadas, de una manera u otra al software libre, en los cuales explicaban su trabajo. Además, repartían pósters, trípticos explicativos, pins, cds...

Los alumnos del Free Software Master tuvimos la oportunidad de asistir en calidad de ponentes!! Allí expusimos (quien puso voz y cara fue Pablo), en la Research Room, nuestra particular visión sobre calidad en el software libre: Quality and libre software: a theoretical and practical approach.

I can't believe it

Occam's razor, porque lo más sencillo es lo más probable

2008-02-03T01:44:00.000-08:00

Hace más o menos un año surgió en la Universidad de Vigo la iniciativa de publicar una revista técnica libre. Tras tres números publicados no cabe otra cosa más que dar la enhorabuena a los promotores de dicha iniciativa así como a todos los que han trabajado en la misma.

No voy aquí a hacer ningún breve resumen de los contenidos porque, sinceramente, no sabría qué artículos nombrar. Tendría que enumerar todos, ya que todos me parecen interesantísimos. Sin más, dejo el enlace a la página de descargas para que cada cual valore por sí mismo.

http://webs.uvigo.es/occams-razor/

P.D.: ah! como todo documento libre, permite bajarse los fuentes (en látex) así como colaborar enviando nuevos artículos.

Wikia

2008-01-07T16:25:00.000-08:00

É coñecida por todos a meirande cantidade de información que circula pola rede. Tamén é de sobre coñecida que quen deu coa mellor solución para buscar esta información levouse o gato á auga (pobre gatiño, co medo que lle teñen a auga), é dicir, google. Comezou sendo un simple buscador e converteuse no sistema preferido de moitos para publicar blogs (blogger), visualizar mapas(google.maps e google earth), ler feeds (google reader) e un longo etcétera.

Parece mentira pero a realidade é que eu agora mesmo non concibiría a internet sen google. A realidade é así de... crúa? Pois, no que se refire o servicio básico, é dicir, ao buscador, dende onte temos unha alternativa aínda en fase alpha. Trátase de wikia, o buscador web dos creadores da wikipedia. Baséase nas ideas da Web 2.0 para intentar ofrecer ao usuario os resultados que realmente busca empregando para iso a información proporcionada por outros usuarios.

Eu probeino. Pensaba que con iso de que era o primeiro día e ao estar baseado en redes sociais pois aínda non tería suficientes datos como para dar un bó resultado. Nada máis lonxe da realidade. Fixen unhas poucas buscas e, se ben é certo que para cada unha delas obtiven poucos resultados, estes foros verdadeiramente significativos. Posiblemente sexa esta unha das vantaxes que nos ofrece: un refinamento nas buscas, a diferencia do que pasa en google onde se proporciona ao usuario unha cantidade inxente de resultado onde só os primeiros (a primeira páxina de resultados, por exemplo) son relevantes.

Agora só nos quedan dúas cousas: participar e esperar a ver que pasa.

De chegarse a un resultado satisfactorio e ser este proxecto unha alternativa real a google... solucionaríase a progresiva monopolización da web que estamos a experimentar?

Ofrecerá wikia, de ter éxito, outros servicios seguindo o modelo de google?

Tempo ao tempo.

Escritorios e webs. Un camiño entre dous mundos.

2007-12-16T11:14:00.000-08:00

Corría o ano 2005. Estaba en cuarto de carreira (Teleco Vigo) e coido que foi aí cando comezou o meu verdadeiro interese pola tecnoloxía alén do estrictamente académico. Descubrín por esa época unha chea de tecnoloxías relacionadas co desenvolvemento web como JSP, os servicios web, os proxectos de Mozilla... Entre estes últimos estaba XUL, unha linguaxe XML para crear interfaces gráficas de usuario (GUIs). Lembro que me chamara bastante a atención. Nese momento estaba entusiasmado ca maquetación web con CSS e co cumplimento estricto dos distintos estándares e o seguimento de directrices para garantir a interoperabilidade entre plataformas cando de súpeto... zas!! unha linguaxe que me permite facer aplicacións web como se foxen aplicacións de escritorio. De feito, moito máis doado todavía xa que a sintaxe era XML... impresionante!

Tanto me impresionara que a miña primeira entrada nun blog (que eu mesmo implementara :), con un par) trataba sobre este tema. Creo recordar que comentaba algo así como que a tendencia era desenvolver cada vez máis aplicacións web deixando a un lado as de escritorio e tecnoloxías como XUL, facilitaban esa transición xa que permitían facer GUIs de maneira moi sinxela cunha apariencia similar ás de escritorio.

Pois ben, hai case tres anos de eso pero nesta última semana ata en dúas ocasións e outra máis uns días máis atrás topei con estes mesmos temas. Primeiramente topei cos sistemas operativos web como EyeOS ou YouOS. Son, grosso modo, sistemas que che amosan, vía web, unha interface coma as dos sistemas operativos de escritorio, cun conxunto de aplicacións para realizar as tarefas habituais. Non me vou extender máis neste tema, xa que non é motivación deste post, déixote que te inmiscúas neles e os descubras en profundidade por ti mesmo. A miña impresión é que non son a solución á migración dos sistemas de escritorio aos sistemas web porque non son máis que unha simple simulación dos SO de escritorio sobre unha infraestructura web. Penso que este é un erro común en moitos sistemas: inténtase imitar un modelo que funciona cunha tecnoloxía distinta. Esa tecnoloxía (neste caso a infraestructura web) pode ofrecer unha serie de oportunidades que a primeira non ten e, polo feito de imitar esta primeira, quedarán sen explorar. De feito, a grande maioría dos avances tecnolóxicos xurden de ideas novidosas, pode que inspiradas noutros sistemas, pero non da copia exacta. Por este motivo, son os investigadores ou técnicos máis novos os que teñen moito que dicir neste eido xa que ao non levar traballando moito tempo nunha tecnoloxía concreta carecen de moitos prexuízos nese campo ao que lles permite romper coas tendencias actuais e propoñer ideas que rompan radicalmente con todo o anterior.

Neste campo dos sistemas web penso que é moito mellor a proposta de google, que ofrece un paquete de aplicacións ás que se accede vía web, pero de maneira independiente cada unha delas como: Google Reader, como lector de feeds, Google Docs, como paquete de ofimática; Blogger, para os blogs; Picassa, para fotografías; Gmail, para correo... bueno e tantas outras. Desta maneira permite realizar vía web, moitas tarefas que habitualmente se facían en aplicacións de escritorio. A diferencia cos sistemas operativos web comentados no paragrafo anterior é que non estás nun entorno pechado, é dicir, non existe un contenedor sobre o cal se dispoñen as distintas aplicacións ofrecidas. O único elemento de unión que hai entre todas elas é o concepto de sesión, o cal é transparente para o usuario, xa que esta se mantén entre os servidores de google e a máquina cliente mediante os protocolos subxacentes.

Agora ben, as aplicacións de escritorio seguen a estar aí e coido que, durante un tempo bastante longo, isto seguirá a ser así. Desta maneira, plantéxase unha cuestión inquedante... ¿non sería necesario algún mecanismo de sincronización entre as aplicacións web e as de escritorio? Esta cuestión xurdíu nunha tertulia con Andrés Maneiro na xélida noite de A Coruña, o venres pasado. Chegamos á conclusión de que sería necesario un mecanismo de sincronización entre ámbalas dúas partes de maneira que se poidera empregar ferramentas de ámbolos dous lados indistintamente en tempo e lugar e se mantivesen os mesmos datos de maneira consistente. Desta maneira teriamos os documentos accesibles no noso ordenador persoal en local e tamén de maneira remota dende calqueira equipo. E foi aquí cando nos demos de conta dunha cousa: o correo electrónico xa permite isto dente hai moitos anos. Podemos descargarnos as nosas mensaxes, respondelas offline, e no momento no que recupere a conexión enviaranse de verdade ditas respostas, sincronizando así a información que dispós no teu ordenador local coa que está na rede. Este mecanismo do correo electrónico baséase en protocolos como POP3 ou IMAP. Pois ben, da mesma maneira podería (debería de) existir protocolos similares para outro tipo de información como: documentos de texto ou follas de cálculo. É máis, idealmente debería de haber un protocolo xenérico (independente do tipo de documento) que mantese a sincronización entre os dous mundos: online e offline.

Utilidades: ferramentas e tecnoloxías (I)

2007-11-27T14:25:00.000-08:00

No meu estudio diario de sistemas de execución de eLearning atópome as veces que estes empregan ferramentas xa existentes para o seu desenvolvemento. Considero que esta é unha moi boa técnica. Desta maneira afórrase tempo ao non programar o xa existente (non reinventar a roda) e, por outra banda, tense a seguridade (se se é coidadoso ao elixir) de que o sistema vai funcionar. Isto non é nada novo, xa o dixo Eric S.Raymond en The Cathedral and the bazaar(español): os bos programadores saben que escribir, os mellores que reescribir (ou reutilizar).

A continuación enumero unha serie de ferramentas e tecnoloxías coas que me teño topado pero que aínda non tiven tempoa estudiar e probar en profundidade (así que xa sabedes o que vos toca...).

openACS
OpenACS (Open Architecture Community System) is a toolkit for building scalable, community-oriented web applications.

Axis
Axis is essentially a SOAP engine -- a framework for constructing SOAP processors such as clients, servers, gateways, etc. The current version of Axis is written in Java, but a C++ implementation of the client side of Axis is being developed.

Quartz
Quartz is a full-featured, open source job scheduling system that can be integrated with, or used along side virtually any J2EE or J2SE application - from the smallest stand-alone application to the largest e-commerce system. Quartz can be used to create simple or complex schedules for executing tens, hundreds, or even tens-of-thousands of jobs; jobs whose tasks are defined as standard Java components or EJBs. The Quartz Scheduler includes many enterprise-class features, such as JTA transactions and clustering.

Log4J
Inserting log statements into your code is a low-tech method for debugging it.It may also be the only way because debuggers are not always available or applicable. This is often the case for distributed applications.
On the other hand, some people argue that log statements pollute source codeand decrease legibility. (We believe that the contrary is true). In the Java language where a preprocessor is not available, log statements increase the size of the code and reduce its speed, even when logging is turned off. Given that a reasonably sized application may contain thousands of log statements, speed is of particular importance.

With log4j it is possible to enable logging at runtime without modifying the application binary. The log4j package is designed so that these statements can remain in shipped code without incurring a heavy performance cost. Logging behavior can be controlled by editing a configuration file, without touching
the application binary.

openLDAP
OpenLDAP Software is an open source implementation of the Lightweight Directory Access Protocol.

AspectJ
Some aspects of system implementation, such as logging, error handling, standards enforcement and feature variations are notoriously difficult to implement in a modular way. The result is that code is tangled across a system and leads to quality, productivity and maintenance problems. AspectJ is a seamless aspect-oriented extension to the Java programming language that enables clean modularization of these 'crosscutting concerns'. For the best AspectJ development experience, the AspectJ Development Tools (AJDT) project provides Eclipse platform based tool support for AOSD with AspectJ.

JPam
JPam is a Java-PAM bridge. PAM, or Pluggable Authentication Modules, is a standard security architecture used on Linux, Mac OS X, Solaris, HP-UX and other Unix systems. JPam is the missing link between the two.

JPAM permits the use of PAM authentication facilities by Java application running on those platforms.
These facilities include:

account
auth
password
session

It features JAAS and direct APIs, support for most Unix OSs and architectures and much more...

JPam is available under an Apache open source license and is actively developed, maintained and supported.

JAAS
Java^TM Authentication and Authorization Service

JAXM
The Java API for XML Messaging (JAXM) enables applications to send and receive document-oriented XML messages. JAXM implements Simple Object Access Protocol (SOAP) 1.1 with Attachments messaging so you can focus on building, sending, receiving, and decomposing messages for your applications instead of programming low-level XML communications routines.

JADE
JADE (Java Agent DEvelopment Framework) is a software Framework fully implemented in Java language. It simplifies the implementation of multi-agent systems through a middle-ware that complies with the FIPA specifications and through a set of graphical tools that supports the debugging and deployment phases. The agent platform can be distributed across machines (which not even need to share the same OS) and the configuration can be controlled via a
remote GUI. The configuration can be even changed at run-time by moving agents from one machine to another one, as and when required. JADE is completely implemented in Java language and the minimal system requirement is the version 1.4 of JAVA (the run time environment or the JDK).

State pattern

2007-11-06T13:10:00.001-08:00

Moitas veces ao programar xurden escenarios nos que a resposta que debe de dar a aplicación non sempre é a mesma, senón que depende da situación na que se atope o programa nese momentos. Esta pode estar caracterizada, por exemplo, polo valor que toman algunhas variables. Estas distintas situacións nas que se atopa a aplicación son os estados, e o mecanismo coñecido e posto en práctica na maioría das ocasións para xestionar as distintas accións características de cada estado é a implementación dunha máquina de estados.

Tralas máquinas de estado hai toda unha teoría matemática que, para aos programadores carece de importancia algunha. Simplemente nos adicamos a pensar nun programa cun estados en tres termos: estado-estímulo-resposta. Noutras verbas, para cada estado a resposta do sistema ás distintas ordes ou interaccións vai ser distinta.

Agora ben, a nivel de programación, interactuar cun módulo software consiste en invocar unha serie de métodos, públicos se os chamamos dende fora a través da súa interface ou privados se o facemos dende dentro. En ámbolos dous o comportamento vai depender do estado. Tradicionalmente a implementación deste mecanismo consistíu nunha sucesión de sentencias if ou case dun switch. Unha sentencia por cada estado. Esta metodoloxía ten unha serie de inconvenientes:

Ineficiencia. Nun determinado momento só hai un estado activo, pero non sabemos cal, polo que hai que pasar por toda a secuencia de if ou case ata chegar ao de interés. Isto supón unha carga innecesaria. O ideal sería executar a parte do código correspondente ao estado actual sen executar os if

Metodoloxía propensa a erros. Calquera cambio nun estado pode implicar cambiar todos os métodos. Máis concretamente cambiar unha pequena parte de cada un dos métodos, a correspondente ao estado en cuestión. Dende o punto de vista do programador isto é moi engorroso e perigoso. Ao estar a parte do código dun estado misturado cos demáis, cambiando un, se non se fai con tino, pódense estragar os demáis. Por outra banda, sería doado esquecerse de modificar algún método. Isto último é moi probable no caso de que esteamos a engadir un novo estado. Se modificamos todos os métodos menos un podemos levar o sistema a situacións anómalas.

A solución a todos os males anteriores pasa polo emprego do Patrón Estado. Este patrón propón encapsular o código de cada estado nunha clase. Así, teremos unha clase por estado. A entidade á que pertenzan eses estados, isto é, a aplicación ou clase que poida estar en varios estados terá unha obxecto estado activo de cada vez. Desta maneira soluciónanse os dous problemas anteriores:

As chamadas aos distintos métodos non perderán tempo en secuencias de if ou case xa que no seu interior só está o código corresponde ao estado da clase na que se atopan.

Ao non ter misturado código de distintos estados minimizamos a posibilidade de cometer erros ao facer modificacións. As modificacións sobre un estado afectarán só á clase correspondente a ese estado. Engadir un novo estado supón crear unha nova clase, non existindo o perigo de engadir o if correspondente en cada dos métodos. Pódese pensar que desta maneira podemos esquecer engadir un método ao crear unha nova clase, pero non é así. As clases correspondentes a cada estado deberán de implementar unha determinada interfaz ou herdarán dunha clase xenérica que lle obrigará a sobrecargar os distintos métodos ou, terá unha implementación por defecto para aqueles métodos que non sexan característicos de ningún estado e, por tanto, de implementación opcional.

Este mecanismo queda máis claro á vista do seguinte diagrama de clases:

Contexto é a entidade que manexa estados (a que pola implementación tradicional tería as ristras de if para cada método). Como vemos, esta posúe un obxecto da clase Estado. Esta clase é a que encapsula o comportamento de cada estado. As implementacións concretas de cada un fanse nas súas clases fillas, as EstadoConcretoX. Contexto disporá en cada instante dun só obxecto Estado e este, á súa vez, disporá dun só elemento EstadoConcretoX activo.

Os patróns de deseño software propoñen sulucións xenéricas deixando, ás veces, cuestións sen especificar que dependerán do criterio do programador. Así, xurden as seguintes preguntas:

¿Como se fai un cambio de estado? Os cambios de estado detéctanse por mecanismos á marxe desta arquitectura. Serán os tradicionais, como premer un botón ou finalizar unha acción. Agora ben, como cada estado está encapsulado nun obxecto e aplicación traballará en cada momento cun só destes deles (o correspondente o estado actual), temos que lidiar coa tarefa de cambialo. Para dar resposta a isto temos que antes considerar como almacenamos os estados, isto é:

¿temos todos os estados cargados e almacenados nunha estructura como un array?

¿temos en cada instante cargado só o obxecto correspondente ao estado actual?

A primeira solución apuntada implica a creación de todos os obxectos EstadoConcretoX posibles ao inicio da aplicación e, en cada instante, ter apuntado un deles, o correspondente ao estado actual, que será o soporte as operacións características de dito estado. Seguindo esta proposta, cambiar de estado significa simplemente cambiar o obxecto apuntado. Esta solución caracterízase por:

Ocupación de memoria. Como temos cargados todos os obxectos a ocupación de memoria pode ser importante se éstes ocupan moito e/ou se temos demasiados

Cambios de estado moi rápidos. É unha característica a ter en conta en aplicacións onde os cambios de estado sexan moi frecuentes.

O segunto método implica a destrucción e creación dun novo obxecto EstadoConcretoX cando se cambia de estado. As características deste mecanismo son as opostas ao anterior:

Moi baixa ocupación de memoria. De feito é a mínima posible, xa que só temos cargado un obxecto.

Cambios de estado lentos. As accións de destrucción e creación de obxectos son lentas.

De entre os dous mecanismos, como outras tantas veces, teremos que decidir se darlle prioridade á ocupación de memoria ou a velocidade de execución. Para aplicacións con cambios de estado habituais parece máis apropiado mantelos todos en memoria. Un exemplo disto poden ser os protocolos de comunicacións, nos que se están a invocar primitivas de maneira moi frecuente e, por tanto, os cambios de estado deben de ser moi rápido, para non ter que encolar as peticións.

¿Quen xestiona os cambios de estado? Caben dúas posibilidades: os estados en si, isto é, os obxectos EstadoConcretoX o cal implicaría un mecanismo distribuído; ou a clase Estado ou Contexto, dando lugar a unha técnica más centralizada. O primeiro método da lugar a un alto acoplamento entre clases, xa que unhas terían que coñecer as outras. Ademáis teriamos o código dunha determinada función (cambiar de estado) desperdigado en varias clases (scattered code), o cal non é modular (é unha cagada). Un cambio na xestión dos estados implicaría tocar máis dunha clase (insostible). Estes problemas non se dan se deixamos a xestión para Estado ou Contexto. Desta maneira só queda decidir cal é a que garda os estados actuais se unha ou a outra, pero isto xa é cuestión do programador.

Exemplos de aplicación deste patrón poden ser:

Máquinas de estados de comunicacións

Ferramentas gráficas. En moitas ferramentas gráficas disponse dun panel no que se pode debuxar. Para facer isto é habitual dispor dun panel de botóns no que se elixe a ferramenta de debuxado desexada (un pincel, un lapis, etc.). O resultado sobre o panel de debuxado non será o mesmo, variará en función da ferramente empregada. Así, pódese pensar que a ferramente elixida constitúe o estado da aplicación.

Java to HTML

2007-10-23T07:38:00.000-07:00

Ás veces precisamos escribir código java durante algunha explicación, como por exemplo, nunha documentación ou nun blog, como pode ser este.
Case todos os IDE de hoxe en día colorean o código de maneira que se poida apreciar a simple vista cada unha das partes que o compoñen. Se queremos ter esa mesma apariencia en HTML teremos que coller o código e aplicarlle un montón de etiquetas para obter dito resultado. Isto é moi engorroso. Pero como case sempre, temos unha aplicación que fai o traballo sucio por nós, trátase de Java2Html. Vaga a penar botarlle unha ollada. É verdadeiramente sinxelo e o resultado é moi bo.

A continuación amósase un exemplo de funcionamento. Primeiramente se pode observar un pedazo de código pegado directamente e, de seguido, o mesmo código, tras pasar por Java2Html

/**
* This is about ClassName.
* {@link com.yourCompany.aPackage.SuperClass}
* @author author
*/
public class ClassName extends SuperClass {
/* This comment may span multiple lines. */
private int integer = 0;
public final static char character = 'A';
// This comment may span only this line
private String string = "zero";
}


 
/**
 * This is about <code>ClassName</code>.
 * {@link com.yourCompany.aPackage.SuperClass}
 * @author author
 */
public class ClassName extends SuperClass {
  /* This comment may span multiple lines. */ 
  private int integer = 0;
  public final static char character = 'A';
  // This comment may span only this line 
  private String string = "zero";
}

Filosofando sobre compoñentes software..

2007-10-18T11:44:00.000-07:00

O software é unha disciplina relativamente recente. Coido que aínda non acadou a súa fase de madurez. Día a día os que estamos máis ou menos metidos neste mundiño observamos como xurden novas técnicas, como morren outras, como aquela maneira de traballar de hai un ano hoxe nos parece unha toleira. En definitiva, está todo moi caótico. No outro lado da moneda temos o hardware. Xa o dicía un profesor meu da universidade: “los que en la Edad Media hacían molinos, hoy hacen hardware”. Dende un punto de vista histórico non sei se é certo ou non mais, no ámbito deste artigo, carece de importancia esa cuestión. Pero alén disto esa frase agocha moito máis significado. Trátase da larga traxectoria que levou o hardware ata os nosos días, gracias a cal atópase nun estado de madurez e estabilidade que debe de servir como exemplo ao software.

Nos últimos tempos apareceron novos estándares e revisións doutros existentes como BlueTooth ou Wifi sobre os que se constrúen aplicacións cada vez máis complexas. Mais, as placas electrónicas (con permiso dos electrónicos) son todas “parecidas” entre si, isto é, uns poucos chips insertados nunha plaquiña e interconectados mediante pistas. Quizais algunha resistencia para facer algunha adaptación ou condensadores para pequenos filtrados pero pouco ou nada máis. E isto é así para sistemas tan sinxelos como un mando a distancia ata a placa base do meu ordenador (e supoño que do teu tamén). A funcionalidade do sistema ben dada pola interconexión entre os distintos chips, así como “das tripas” destes. Cada un destes chips unha ofrece ao enxeñeiro de hardware unha serie de patiñas ou pins que actúan como entrada ou saída de información. Nas mans do electrónico está o poder de conectalo debidamente con outros chips ou circuitos integrados para crear grandes sistemas. Cada un destes circuitos integrados está deseñado por distintas empresas e... sen embargo... todo funciona!

No software a realidade pinta de maneira ben distinta. Se as cousas funcionasen como no hardware bastaría con coller unha serie de compoñentes deseñados por distintos desenvolvedores e unilos entre si cunha infraestructura moi básica: nada máis lonxe da realidade. Coa aparición da POO (OOP – object oriented programming) deuse un pulo á reutilización, permitindo deseñar clases que se poden reutlizar posteriormente. Na práctica isto non funciona así xa que as clases non encapsulan funcionalidades de maneira correcta, atopándose estas distribuídas entre varias Así, nunha aplicación existen unha chea de dependencias entre clases, de maneira que é difícil coller unha de elas e reutilizala outra vez.

Nos últimos tempos toman cada vez máis protagonismo as tecnoloxías web e, neste eido, xurden unha chea de frameworks como SPRING, JSF ou .NET. Estes proporcionan unha infraestructura ou un esquelete do sistema moi complexo que é totalmente transparente ao programador, permitindo a este a construcción de sistemas complexos de maneira sinxela. Aínda así, coido que non son a solución definitiva. As miñas razóns son as seguintes:

Infraestructuras moi complexas. Para crear pequenas aplicacións empréganse máis recursos no soporte das mesmas que nelas en si mesmas. ¿Para as grandes é válido? Verdadeiramente funciona, pero penso que non é a solución ideal porque esta vai depender do framework empregado, complicando así calquera migración futura e obrigando a ter expertos no manexo dos mesmos.
Seguindo co exemplo do hardware, alí os grandes sistemas compóñense dos mesmos elementos cos pequenos, ¿non sería viable que no software isto fose da mesma maneira? Así se solucionarían os dous problemas plantexados no punto anterior: a migración, a cal xa non tería sentido porque o sistema non estaría asentado sobre outro e, por este mesmo motivo, non habería que ter expertos nese outro sistema base.

O que propoño é:

Deseñar compoñentes software autónomos, cunhas interfaces ben definidas, que se poidan empotrar en calquera sistema. Ben, esta idea non é ningunha novidade. É máis pódese dicir que o obxectivo de moitos arquitecturas que teñen xurdido nos últimos anos.
Da mesma maneira que no hardware temos as tarxetas como “frameworks” para os distintos compoñentes, ter no SW unha infraestructura moi sinxela tamén.
Conectarase as entradas dun compoñente ás saídas doutro (mapping) . Esta conexión pode ser directa ou mediante algún elemento intermediador que adapte o protocolo de comunicación, como un bridge en redes ou unha resistencia de pull-up en electrónica.
Estas conexións definirán o fluxo de datos e de control pero... ¿cando se establece este? ¿quen o fai? Deberemos de ter unha ferramenta de modelado, gráfica ou textual, na que se definan as conexións entre os disintos compoñentes. Nesta definirase o comportamento inicial do sistema, mais este poderá variar mediante o cambio no fluxo de datos ou control e os compoñentes.
Os compoñentes poderanse extraer e poñer en quente (hot swap). Para que isto sexa posible os outros compoñentes deben de ser o suficientemente robustos como para soportar estas situacións. Este comportamento é parecido ao dos nodos das redes de comunicacións, se un se cae, a rede ten que seguir funcionando. Para elo os outros nodos cambiarán as súas táboas de encamiñamento dacordo a nova situación. Aquí non ten sentido falar de táboas de encamiñamento, a non ser que teñamos compoñentes redundantes (distintos compoñentes que dan a mesma funcionalidade). Neste caso o novo compoñente que reciba a orde de executarse deberá tamén recibir algún tipo de información para acadar o mesmo estado no que estaba o outro. Con respecto a esto xurde unha cuestión, ¿poderase recuperar o estado directamente (como un patrón memento) ou teranse que dar unha serie de pasos ata acadalo?

No hardware é doado imaxinarse o hot swap porque os compoñentes son tanxibles. No software é máis complexo. Non vamos a coller un compoñente SW coa man, extraelo e por outro no seu lugar, senón que haberá un axente ou entidade coordinadora que os active e desactive. Isto pode ser a petición dun usuario, co cal se comunica.
A interconexión dos compoñentes deberá de ser independente da linguaxe na que estes estean programados, así como da plataforma sobre a que se interconecten (linux, windows...)
A conexión dos mesmos poderase facer de maneira local ou ben remota. Este punto pode entroncar coas Arquitecturas Orientadas a Servicios. Xurde aquí, entón, unha cuestión, ¿podemos considerar os compoñentes como servicios e/ou viceversa?
Os compoñentes poderán ampliar a súa funcionalidade mediante plugins. Cada vez que se engade un plugin a un compoñente este deberá de actualizar a súa interface coa nova funcionalidade ofrecida ou ampliada.

Dúbidas

Un dos requisitos impostos por SOA é que os servicios sexan sen estado. Aquí, os compoñentes, ¿pode ter sentido que teñan estado? ¿Con estado é posible que poidan ofrecer funcionalidades maiores?
¿Pode ter isto relación coas POJO (clases de java de toda a vida) bautizadas por Martin Flower e as ferramentas que hai para traballar con elas?

¿As tarefas de comunicación as leva o compoñente en si mesmo ou necesita dunha capa ou doutro de compoñente de apoio?

Tecnoloxías, arquitecturas e ferramentas a estudiar relacionadas:

COTS
CBSE
SOA
ADL (Architecture Description Languages)
Notación UML-RT (en teoría isto é anterior a UML 2.0)
Rational Rose
Event-driven Modelling??

rsync

2007-10-17T15:19:00.000-07:00

Cando traballamos en varias máquinas de maneira habitual, ou temos unha como copia de seguridade, gustarianos ter sincronizada a información en todas elas.

Isto é moi doado co comando rsync.

Nunca máquina debemos de ter correndo un servidor de rsync. Nos clientes executaremos o comando cada vez que queiramos sincronizar o contido dalgún directorio local con outro directorio da máquina na que corre o servidor.

É interesante destacar que a sincronización pode ser en ámbolos dous sentidos. Ademáis, entre outras opcións, a ferramente ofrece a opción de ter en conta a versión máis recente dun ficheiro para actualizalo ou non según se lle indique.

SOA, Web Services, Orchestration e Choreography

2007-10-16T15:36:00.000-07:00

SOA (Services Oriented Architecture) é unha arquitectura software cuio obxectivo é distribuír a funcionalidade entre unha serie de axentes. Estes axentes funcionan de maneira autónoma sendo totalmente independentes entre si.

Cada un destes axentes ou servicios ofrece un servicio (un cálculo, a encriptación dun texto, unha conversión de formato) á aplicación que o invoque. Desta maneira estase a repartir a funcionalidade dunha aplicación en distintas entidades. Agora ben, a aplicación principal debe de poder acceder a este servicio para o cal é preciso que este se tivera rexistrado previamente nun directorio (como unhas páxinas amarelas).

Cada servicio debe de cumplir unha serie de restriccións para que poida ser descuberto e empregado por outras entidades. Estas son:

Independencia da linguaxe

Independencia da plataforma

Idempotencia. Para non dar lugar a situacións erróneas polo envío de mensaxes repetidas.

Sen estado.

Interfaces ben definidas

A esta arquitectura responden os servicios web cunha serie de características:
As interfaces deben de estar baseadas en protocolos de Internet (HTTP, ...)
As mensaxes deben de ser XML (excepto os attachments que poden ir en binario)

Unha vez feita esta brevísima descrición inicial xurde a seguinte cuestión, ¿non sería posible que estes servicios cooperasen entre si dando lugar a sistemas máis potentes? Pois si. Está cooperación vén descrita por dous termos: choreography e orchestration. Choreography é unha descrición das interaccións peer to peer externamente observables que existen entre os servicios que forman parte do sistema. Esta descrición dase dende un punto de vista neutral, non dende o punto de vista dos servicios, mediante o estándar WS-CDL. Pola contra orchestration fai referencia á composición de servicios, controlando a maneira en que interactúan entre eles e, verificando que isto se faga de maneira segura, seguindo unha secuencia lóxica e fiable. A composición de servicios para dar lugar a outros novos segue o estándar WS-BPEL.

Agora que xa temos un conxunto de servicios perfectamente definidos que cooperan entre si proporcionando unha certa funcionalidade xurde outra pregunta, ¿estamos ante un sistema de workflow? A resposta é si. Stephen Ross-Talbot [1] o describe da seguinte maneira tengo en conta se hai interacción humana ou non: “in a SOA services can be software agents as well as human agent. It is when we include a human agent as a service that we start to see that orchestration and choreography are different ways of defining workflows. In the case of orchestration we use a service to broker the interactions between the services including the human agents and in the case of choreography we define the expected observable interactions between the services as peers as opposed to mandating any form of brokering”.

[1]Orchestration and Choreography: Standards, Tools and Technologies for Distributed Workflows.
Stephen Ross-Talbot
Pi4 Technology, London, UK and W3C, Geneva, Switzerland

[2]http://www.lightreading.com/

[3]Web Services Architecture
W3C Working Group Note 11 February 2004
http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/

Andrés Estévez Costas, 16/10/2007

Adaptive Object Modeling (AOM)

2007-10-12T13:47:00.000-07:00

Adaptive Object Modeling (AOM)

[NOTA: o que está en inglés é por vagabundería pura e dura]

Trátase dunha arquitectura que responde á seguinte cuestión: “¿Como construír sistemas que poidan, dinamicamente, adaptarse aos novos requirimentos do negocio?”. É dicir, trátase de construír sistemas que se adapten facilmente aos cambios no dominio. Facilmente, no extremo, pode significar “sen programar”. Esta é a arquitectura empregada por moitos sistemas de workflow.

Esta arquitectura baséase en dúas cuestións fundamentais:

Metadatos. Como o seu nome indica son datos sobre datos. AOM propón o emprego de metadatos para modelar aquelas cuestións “predicibles”. Desta maneira non se ata a unha funcionalidade dada, permitíndoa modificar en tempo de execución. Ao meu entender non é a solución idónea, xa que hai que saber no momento da implementación do sistema por onde poden ir os tiros, o cal non é máis flexible posible.
Patróns de Diseño que afondan no tema da reutilización e dos cambios ao voo durante a execución dun sistema. Entre estes están:
- Patróns dinámicos:
  - TypeObject, desacopla as instancias das súas clases, de forma que esas clases poidan ser implementadas como instancias doutras clases. Permite CREAR CLASES DINÁMICAMENTE (ollo!! clases, non obxectos), permitindo ao sistema proporcionar as súas propias regras de chequeo de tipos. Pode conducir a sistemas más sinxelos e pequenos.
  - Property, proporciona mecanismos para acceder, alterar, engadir e eliminar atributos en tempo de execución .
  - TypeSquare. A combinación do TypeObject co Property
  - RuleObject. "This pattern language balances the forces in the problem doaain of modeling, design, implementation and placement of business rules, workflow, routing in distributed, object-oriented and component-based applications. As the need arises for more scalability, flexibility and performance, additional patterns are introduced that balance the new forces that come into the picture as a result of additional functional or non-functional requirements"
- Patróns “clásicos”
  - Strategy. Define unha familia de algoritmos encapsulando cada un deles nun obxecto. Estes obxectos son intercambiables. Esta solución permite que o algoritmo varíe en función do cliente que o empregue.
  - Composite
  - Interpreter
  - Builder

Patróns de Software

2007-08-08T16:05:00.000-07:00

A Enxeñería do Sofware é unha ciencia relativamente recente no mundo da técnica, non comparable á mecánica, a electricidade ou a electrónica. Nestas últimas, por exemplo, existe unha grande experiencia acumulada ao longo de moitos anos. Por este motivo tódalas cuestións que atinxen a estas materias atópanse perfectamente definidas e delimitadas, coñecéndose perfectamente a problemática que involucran, así como a súa solución. Ademais, ditas solucións fóronse depurando pouco a pouco limando todos os pequenos detalles que non se tiveran en conta nun primeiro momento.

A tecnoloxía do software está moito máis verde. Se ben é certo que nos últimos anos experimentou un gran desenvolvemento coa aparición de novos paradigmas como a Programación Orientada a Obxectos (OOP – object oriented programation) ou, moito máis recente, a Programación Orientada a Aspectos (AOP – aspect oriented programation), que non se tratarán aquí por escaparse do ámbito deste apéndice. Ademais da aparición destes paradigmas aparecen novas técnicas como o emprego de Patróns de Deseño Software. Un patrón “describe un problema que ocorrre unha e outra vez no noso entorno, así como a solución a dito problema, de tal modo que se poida aplicar esta solución un millón de veces, sen facer o mesmo dúas veces”. O contexto orixinal desta descrición era a arquitectura urbana, pero pódese aplicar noutros ámbitos. Neste caso ao Software. Neste ámbito, segundo o seu propósito os patróns divídense nos seguintes grupos:

De creación, que tratan sobre o proceso de creación de obxectos.
Estructurais, que tratan coa composición de clases ou obxectos.
De comportamento, que caracterizan o modo no que as clases e os obxectos interactúan e se reparten a responsabilidade.

Refactorización de código

2007-08-07T16:18:00.000-07:00

A refactorización é un concepto que toma cada vez máis peso no desenvolvemento de software. Consiste en realizar modificacións no código co obxectivo de mellorar a súa estructura interna, sen alterar o seu comportamento externo. O obxectivo final é manter un código limpo e estructurado ou, dito doutro xeito, sinxelo e de calidade.

Unha vez definida esta técnica toca o momento de profundizar nas súas peculiaridades. Cada proxecto de desenvolvemento de software parte dunhas especificacións iniciais a partir das cales realízase o deseño e, posteriormente, a implementación. A partir desas especificacións, as dúas fases seguintes, débense de desenvolver de maneira que se cumprar todas as directrices propostas na Enxeñería do Software para garantir uns altos niveis de calidade. A práctica afástase un tanto desta descrición. As especificacións cambian de cotío, incluso cando xa se superou esta fase, e se está en pleno deseño ou incluso na implementación. Isto implica que se teñan que realizar modificacións non consideradas no plantexamento inicial. Estes cambios provocan que a arquitectura proposta inicialmente para o sistema a desenvolver deixe de ser a máis adecuada. A consecuencia disto é unha perda gradual da calidade do software que se manifesta de diversas maneiras:

existencia de código duplicado;
o código non permite entender o deseño;
método e clases moi longos;
cada cambio implica cada vez un maior esforzo de programación;

A maneira de solucionar isto é aplicar técnicas de refactorización, consistentes en pequenos cambios no código que transformen a estructura para dar lugar a outra que se adapte mellor as especificacións actuais. Agora ben, hai que ter en conta que todo cambio no código conleva un risco importante. Focalizando a atención nunha determinada cuestión pódense deixar de lado outras que tamén se ven afectadas por estes cambios. Para evitar esta problématica é imprescindible contar cun conxunto de probas automáticas que garantan que calquera cambio realizado non estrague ningunha funcionalidade.

Existen dous escenarios principais de uso da refactorización. O primeiro deles da lugar á chamada refactorización a posteriori e, por outra banda, tense a refactorización continua.

A refactorización a posteriori consiste no conxunto de cambios a realizar tras coller unha aplicación desenvolvida previamente. Os motivos polos que aplicar refactorización aquí son principalmente dous:

O código non é de calidade. Neste caso aplicaranse os cambios oportunos para invertir esta situación.
A estructura non é valida para soportar as novas funcionalidades e engadir.

O problema principal neste escenario é que os cambios poden moi grandes. A maneira de paliar este problema é tratar de dividilos no maior número posible deles. Así cada un dos resultantes será o máis pequeno posible e, polo tanto, máis doado de realizar. Estes cambios tan grandes poden dar lugar a outro problema: a espiral refactorizadora, consistente na identificación de novos problemas mentres se está a refactorizar. Estes novos tamén se empezan a refactorizar. Este proceso pode ser recursivo, non tendo ningunha estimación da súa durabilidade, o cal debe de evitarse por todos os medios. A maneira de evitar este problema é definir claramente os obxectivos da cara refactorización. Se durante o desenvolvemento da mesma se atopan outros novos, apuntaranse, pero non se solucionarán neste momento para evitar entrar na espiral.

O outro escenario de refactorización é a refactorización continua. A diferencia principal co anterior está no punto de partida. Este tipo refactorización dase cando un equipo de desenvolvemento comeza un proxecto dende cero. Por tanto, as necesidades de refactorización virán dadas unicamente polas novas funcionalidades que se engadan. Trala implementación de cada unha delas procederase á refactorización. Desta maneira consíguese que a estructura da aplicación sexa sempre a ideal.

A continuación descríbense unha serie de cuestións a ter en conta en calquera tipo de refactorización:

Coñecementos teóricos básicos. A identificación de situacións que “pidan” unha refactorización (bad smells) non debe de ser unha tarefa que xurda da inspiración de cada un dos membros do equipo. Existen unha serie de situacións comúns que, o seu coñecemento previo, aforrará moito tempo. Tamén é moi importante o coñecemento dos distintos patróns de deseño existentes, os cales, axudarán a identificar ditas situacións.
Compromiso entre funcionalidade e estructura. Acadar unha estructura perfecta da aplicación pode supoñer realizar refactorizacións que empreguen moito tempo de desenvolvemento. Ocupar este tempo nestas tarefas sacrifica o avance da aplicación no tocante ás funcionalidades. Non se debe de caer en ningún dos dous extremos, chegando a un compromiso entre ambos.

Por último sinalar que a refactorización é unha peza básica en diversas técnicas de programacións actuais, como son:

A Programación Extrema (Extreme Programming)
O Desenvolvemento Dirixido por Probas (TDD – Test Driven Development)

Creación de servicios de Internet en Ubuntu

2006-08-23T15:28:00.000-07:00

En alguna ocasión hemos ejecutado algo parecido a esto

telnet url_destino puerto

Lo que estamos haciendo es ejecutar de manera remota un programita en la máquina indicada que está escuchando peticiones en ese puerto.

Esa interfaz no es nada clara, así que lo que se hace es asociar un nombre a esa aplicación en ese puerto. Y eso es lo que pasa cuando hacemos, por ejemplo:

ftp url_destino

Ahora vamos a explicar como podemos crear nosotros nuestro propio servicio. Para ello tendremos que introducir unas líneas en dos ficheros de configuración y crear los ficheros de la aplicación en sí.

/etc/xinetd.conf
En este fichero se definen las características del servicio. Puede tener un aspecto parecido a este:


service nada
 {
        disable                 = no
        socket_type             = stream
        wait                    = no
        user                    = root
        server                  = /usr/sbin/nada
        nice                    = 10
 }

Todas las opciones, así como sus posibles valores se pueden consultar con man xinetd.conf

Comentar solamente que la línea server indica la ruta del script que se ejecutará cuando se acceda al servicio.

/etc/services
Es una lista en la que se enumeran todos los servicios, así como el protocolo de transporte subyacente (tcp/udp) y el puerto. Tiene el siguiente aspecto:


...
dircproxy       57000/tcp                       # Detachable IRC Proxy
tfido           60177/tcp                       # fidonet EMSI over telnet
fido            60179/tcp                       # fidonet EMSI over TCP

# Local services
nada            12345/tcp              # Comentario de nuestro servicio

La primera columna es el nombre del servicio que coincide con el especificado en /etc/xinestd.conf. OJO!! Aquí el nombre del servicio y del script son iguales, pero esto NO tiene porqué ser así.

Ahora, para probasto, basta hacer:
telnet localhost 12345

Próximamente explicaremos cómo acceder al servicio por su nombre.

Crear usuario root en Ubuntu

2006-08-20T14:16:00.000-07:00

Los que nos pasamos de otra distribución de Linux a esta nos encontramos con que, por defecto, no existe el usuario root. Para solucionarlo basta teclear lo siguiente en una consola:

sudo passwd root

A continuación nos pedirá la nueva contraseña para el usuario "root"

AJAX. Implementación

2006-08-15T12:39:00.000-07:00

Continuando con el artículo introductorio a AJAX vamos a presentar ahora una implementación sacada del Rasmus' 30 seconds tutorial, sobre la cual haremos algún comentario y propondremos alguna modificación.

En primer lugar tenemos la función createRequestObject() que se encarga de inicializar el objeto encargado de la comunicación, esto es, aquel que nos proporcionará los métodos necesarios para enviar la petición al servidor y recibir la respuesta.

En el código podemos observar como se tiene en cuenta el navegador que se está utilizando

function createRequestObject() {
var ro;
var browser = navigator.appName;
if(browser == "Microsoft Internet Explorer"){
ro = new ActiveXObject("Microsoft.XMLHTTP");
}else{
ro = new XMLHttpRequest();
}
return ro;
}

A continuación tenemos que llamar a la función anterior para obtener una instancia de dicho objeto:

var http = createRequestObject();

sndReq(action) se encarga de enviar la solicitud al servidor. Como vemos invoca el método http.open con dos parámetros: método de la petición ("get" o "post") y la url. En este caso se le está pasando a la función la lista de variables a enviar ("action"), no ocurriendo con la página destino ("rpc.php"), que está puesta de manera constante en el código. Queda a gusto del programador hacerlo como lo estime más oportuno o como le dé más rabia.

En la siguiente línea ( http.onreadystatechange = handleResponse;) le estamos indicando qué función tiene que ejecutarse cuando "cambie el estado de la petición", esto es, cuando después de haber enviado la petición, reciba la respuesta sin error.

Y por el último tenemos http.send(null);, parte muy importante, ya que indica el fin de la petición.

function sndReq(action) {
http.open('get', 'rpc.php?action='+action);
http.onreadystatechange = handleResponse;
http.send(null);
}

Por último tenemos la función handleResponse que se encarga de recibir la respuesta a la petición anterior e insertar el código html recibido en el elemento correspondiente. Esta implementación lo que hace es que el servidor envíe una cadena al cliente con el siguiente formato:

identificadorElementoHtml|contenido

donde identificadorElementoHtml es el atributo "id" del elemento de la página en el que queremos insertar el código recibido (el "contenido"). Por tanto lo primero que hay que hacer es separar ambos campos, usar el primero de ellos para buscar el elemento "padre"(document.getElementById(identificadorElementoHtml)) y cambiar su contenido por el nuevo, para lo cual accedemos al atributo innerHTML

function handleResponse() {
if(http.readyState == 4){
var response = http.responseText;
var update = new Array();

if(response.indexOf('|' != -1)) {
update = response.split('|');
document.getElementById(update[0]).innerHTML = update[1];
}
}
}

Tal como está hecho este ejemplo, el servidor ("rpc.php") envía una cosa u otra en función de la variable "action". Otra posibilidad es tener un script en el servidor distinto por cada acción. De esta manera en el cliente la página destino ya no debe ser una constante y podemos obviar la variable "action".

Se puede dar el caso de que el resultado de una misma petición la querramos mostrar en distintos elementos, unas veces en unos y otras en otros. Para ello la solución puede ser enviar al servidor en una variable el atributo "id" deseado y este lo devolverá en su respuesta como primer campo. Otra solución (no me comprometo a que funcione) sería dejar una variable en javascript indicando en donde hay que colocar la siguiente información recibida.

Referencias:
http://www.w3schools.com/ajax/
Rasmus' 30 seconds tutorial

Esquivar los spambots

2006-08-13T14:20:00.000-07:00

Es de todos conocido el afán de muchas compañías por hacerse con direcciones de correo electrónico activas para enviar correos publicitarios a las mismas.

Una de las técnicas empleadas son los cadenas de correos que todos hemos recibido alguna vez en las que, antes del contenido del mensaje en sí, aparecen infinidad de direcciones. Además de esta existe otra mucho más sofisticada, que es el uso de spambots, esto es, robots que rastrean páginas en busca de direcciones . De forma más técnica podemos decir que lo que hacen es buscar en el código de una página web patrones que coincidan con la sintaxis correcta de una dirección de correo, por lo tanto, es condición necesaria que en dicho código se encuentre explicitamente el e-mail, así que para esquivar estos spambots lo que tenemos que hacer es, simplemente, no escribir la dirección en la página web. ¿Y cómo la mostramos? Existen dos maneras: la primera, poco elegante, hace uso de javascript. Consiste en que en la posición en la que queremos mostrar la dirección de correo insertamos un código javascript que la genere, por ejemplo, mediante la concatenación de dos variables. De esta manera no existirá ninguna cadena en el código que cumpla el patrón de un e-mail. La segunda forma es hacer uso de CSS, más concretamente del pseudo-elemento after de la siguiente manera:

[en la hoja de estilos...]

address:after{
/* \40 es un código para escribir el caracter '@' */
content: " <ultimastecnoloxias\40 gmail.com>";
}

[ en el lugar de la página donde queremos que aparezca...]

<address>© 2006 Últimas tecnoloxías</address>

En el ejemplo aparece la etiqueta address pero podía ser cualquier otra.
De esta manera hemos conseguido evitar que un spambot encuentre nuestra dirección de correo, ya que en ningún momento aparecerá en el código html de la página. Además, usando esta última técnica, lo hacemos de manera sencilla y elegante.

[OJO!!!] Microsoft Internet Explorer no soporta pseudo-elementos, así que esto no funcionará. ¿La solución? Concienciar al personal para dejar de usar productos Microsoft.

AJAX. ¿De qué va?

2006-08-12T14:18:00.000-07:00

Tradicionalmente la visualización de páginas web ha consistido en la solicitud y descarga de la misma a partir de un archivo .html generado previamente o bien generándose bajo demanda por algún lenguaje del lado de servidor, como PHP.
En ambos casos se descarga la página completamente, siendo este el punto débil de esta arquitectura. Durante la navegación por un sitio web, al acceder a cada una de sus secciones es habitual que no cambie la página completamente, sino una pequeña parte. Por esto motivo es innesario descargar las partes constantes, y es esto lo que soluciona AJAX.

La idea es pedir al servidor el cachito de código html que va a cambiar respecto a la vista actual. De esta manera ahorramos ancho de banda y hacemos que la navegación sea más rápida.

Para que todo esto sea posible es necesario programar un par de funcioncillas en javascript que se encargan de:

Petición de contenidos
Espera hasta finalizar la descarga
Actualización de la página. Se trata de cambiar el código html que se está visualizando por el nuevo. Para que esto sea sencillo es imprescindible que tengamos la página bien maquetada, para lo cual debemos olvidarnos de los FRAMES y las TABLAS (para dar formato) en favor de bloques DIV o SPAN. Si es así, basta cambiar el atributo "contenido" de cada uno de ellos por el nuevo

PHP 6

2006-08-12T13:06:00.000-07:00

Ya está en desarrollo la nueva versión de este popular lenguaje, rival de ASP, su sucedáneo en el Imperio Gates. Algunas de las modificaciones que presentará son las siguientes:

HTTP_*_VARS eliminado
Register Globals es retirado
Return By Reference dará un error
...

Esta breve nota fue sacada de Maestros del Web