abc Web

Si lo pago, lo uso

2008-06-08T11:52:00.002+02:00

Soy linuxero de pro. Tengo actualmente una Debian testing en el sobremesa y una Arch linux en el portátil. Y me encanta. Lo que necesito, lo tiene. Navegar por internet, escuchar música, ver vídeos y dvd's, tareas ofimáticas, amuladores, juegos...

Pero he comprado un nuevo portátil. Un Sony VAIO VGN-FZ31E. Muy pero que muy bonito. Y claro, viene con un Windows Vista Home Premium. Así que me dije, vamos a ponerle un linux.

Pero para qué? Libertad, licencias, mejor seguridad... Si, me conozco todos los argumentos. Pero he pagado por un producto. Considero absurdo tirar algo que he pagado. Se actualiza solo, lleva software por un tubo ya instalado, bien propio de Sony o de terceros. Y si necesito de veras algo más, siempre puedo poner GIMP, OpenOffice, Pidgin, Firefox, Thunderbird. Y ahora con los futuros ports de kde podría incluso poner alguna de las utilidades que más me gustan. Como k3b, kopete, basket, amarok, kaffeine o dolphin. Aunque en este último caso creo que no hay nada mejor que Total Commander, aunque sea shareware ;)

Pero en general, para qué? El portátil viene ya con todo lo que necesito para mi trabajo habitual. Así que este portátil se va a quedar con su Windows Vista Home Premium y todas sus utilidades.

Al menos hasta que me harte de reinicios y de preguntas estúpidas. Preguntas, no llevo muchas la verdad, pero reinicios llevo ya 5 y no hace ni una hora que está en marcha.

No me lo quiero ni imaginar cuando le ponga la capturadora de DVB-T. Seguro que alcanzaré los 15 reinicios antes de que funcione del todo.

Cómo instalar WAPP (II)

2007-12-16T15:22:00.001+01:00

Los tiempos avanzan que es una barbaridad y ya ha pasado casi año y medio desde que escribí la primera parte de este artículo. En él explicaba cómo instalar 2 versiones de PHP (PHP4 y PHP5), sobre un mismo servidor Apache, en un sistema operativo Microsoft Windows. En esta segunda parte voy a intentar dar un giro de tuerca al asunto, instalando ambas versiones de PHP como módulos del mismo servidor Apache, pero corriendo en procesos (servicios) separados.

Con este proceso, podremos aprovechar la misma potencia que nos ofrece Apache para un intérprete y para el otro. Además, de esta forma, iremos renovando nuestra infraestructura para el día en que la versión 4 de PHP no se soporte más. Podremos tener nuestro servidor preparado por defecto para PHP5 y, a la vez, seguir manteniendo algún viejo script de PHP4.

Este método sólo tiene un problema: necesita de más memoria RAM en el servidor porque se estarán lanzando 2 servicios en lugar de uno.

Requisitos previos

Tener una máquina con Microsoft Windows (recomendado XP, pero también sirve 2003 Server).
Haber leído la primera parte de este artículo para tener instaladas ambas versiones de PHP en el ordenador. Actualmente, recomiendo instalar las últimas versiones disponibles: la 4.4.7 y la 5.2.5.

Desinstalación de Apache

Este apartado es opcional, pero es recomendable seguirlo si en nuestra máquina ya estamos ejecutando el servidor de Apache y queremos partir de cero para continuar con el resto de instrucciones que se mencionan más adelante.

La idea es dejar la máquina lo más limpia posible, para que nada de lo que haya anteriormente instalado, cause complicaciones con lo que instalaremos a continuación. Estos son los pasos a seguir:

Parar el servicio de Apache. Para ello hay varias opciones:
- Ejecutar desde una consola de comandos la orden:
```
c:\> net stop nombre_del_servicio_apache
```
- Ir a la consola de servicios del sistema (services.msc) y parar desde allí el servicio.
- Utilizar Apache Monitor (el programa que se instala en la bandeja del sistema cuando instalamos Apache).

Parar la ejecución de Apache Monitor, abriéndo la aplicación y pulsando el botón Exit.

Desinstalar Apache desde Agregar/Quitar programas (en el Panel de Control).

Borrar la carpeta de instalación de Apache desde el explorador de archivos. Antes de hacer esto, podemos hacer una copia de seguridad por si acaso luego quisiéramos restaurar alguna configuración especial.

Un Apache, 2 procesos

Vamos a instalar la versión 2.0.61 de Apache. La razón de no utilizar una versión 2.2.x es la misma que daba hace ya un tiempo: la librería de PHP4 que se carga como módulo de Apache no funciona con la versión 2.2.

Si alguien quiere probar con Windows Vista, será mejor que lea estas instrucciones para instalar Apache.

Haremos una instalación normal, hasta que lleguemos al paso en que pregunta si queremos instalar como servicio (utilizando el puerto 80) o sólo para el usuario actual (en el puerto 8080). Elegiremos esta última opción porque, posteriormente, ya nos encargaremos de instalar manualmente los servicios que necesitemos. Para el resto del artículo, consideraré que Apache se ha instalado en el directorio c:\apache\.

Una vez acabado el asistente de instalación, iremos al directorio de configuración de Apache (c:\apache\conf\) y haremos 2 copias del fichero httpd.conf: una se llamará php5_httpd.conf y la otra php4_httpd.conf.

Nuestro servidor "principal" (el que operará en el puerto 80), cargará como módulo PHP5. El otro servidor, que estará en el puerto 8080 (pero puede elegirse otro puerto), llevará el módulo de PHP4.

Edición del fichero php5_httpd.conf

Partiendo de la configuración base de Apache, estas son las líneas que deberemos modificar:


ScoreBoardFile logs/php5_apache_runtime_status
PidFile logs/php5_httpd.pid
Listen 80
ServerName localhost:80
ErrorLog logs/php5_error.log
CustomLog logs/php5_access.log common

Y estas líneas, las deberemos añadir (se considera que PHP5 está instalado en c:\php5\, si no es así, habrá que modificar la ruta):


LoadModule php5_module "c:/php5/php5apache2.dll"
AddType application/x-httpd-php .php
PHPIniDir "C:/php5"

Edición del fichero php4_httpd.conf

Líneas a modificar:


ScoreBoardFile logs/php4_apache_runtime_status
PidFile logs/php4_httpd.pid
Listen 8080
ServerName localhost:8080
ErrorLog logs/php4_error.log
CustomLog logs/php4_access.log common

Líneas a añadir (se considera que PHP4 está instalado en c:\php4\, si no es así, habrá que modificar la ruta):


LoadModule php4_module "c:/php/sapi/php4apache2.dll"
AddType application/x-httpd-php .php
PHPIniDir "C:/php"

Dos configuraciones, dos servicios

La idea es, viendo el contenido de ambos ficheros, mantener en archivos distintos la información de cada uno de los procesos que vamos a lanzar. Y como van a ser 2 los servicios ejecutados, tenemos que utilizar puertos de escucha diferentes.

El siguiente paso a seguir es instalar los 2 servicios. Desde una consola de comandos, iremos al directorio donde está el ejecutable de Apache y escribiremos:


c:\> cd c:\apache\bin
c:\apache\bin> apache -k install -n "Apache2PHP5" -f "c:\apache\conf\php5_httpd.conf"
c:\apache\bin> apache -k install -n "Apache2PHP4" -f "c:\apache\conf\php4_httpd.conf"

Y para lanzar los servicios:


c:\apache\bin> apache -k start -n "Apache2PHP5"
c:\apache\bin> apache -k start -n "Apache2PHP4"

Si todo ha ido bien, ya tenemos todo listo para invocar a ambos servicios por separado. Vamos a hacer una prueba rápida, escribiendo un script llamado prueba_php.php con este contenido:


<?php
/* fichero prueba_php.php */
phpinfo();
?>

El script lo colocaremos en el directorio DocumentRoot de ambos servidores (que debería ser c:\apache\htdocs\ si no hemos modificado la ruta por defecto). Ejecutando http://localhost/prueba_php.php y http://localhost:8080/prueba_php.php en el navegador, nos debería salir información diferente acerca de cada uno de los módulos de PHP.

Cómo testear la configuración de cada servicio

Por si necesitáramos añadir más prestaciones a alguno de los 2 servicios, voy a comentar como comprobar si el fichero de configuración tiene o no algún fallo. Desde una consola de comandos, tendríamos que escribir:


c:\> cd c:\apache\bin
c:\apache\bin> apache -t -f "c:\apache\conf\fichero_de_configuracion.conf"

Un puerto abierto, 2 servicios en puertos diferentes

Las siguientes instrucciones son totalmente opcionales pero pueden venir bien, en el caso de que queramos dejar solamente abierto un puerto en nuestro router para acceder a cualquiera de los 2 Apaches montados y tengamos acceso al DNS para montar más dominios.

Como último paso, podemos hacer que desde fuera del servidor, parezca que las todas las peticiones sean para un único servidor. Realmente, lo que ocurre es que las peticiones que no puede gestionar el primero, las redirige al segundo, sin que por ello cambie la URL que escribe el usuario. Para ello será necesario que podamos discriminar por nombre de dominio ambos servidores porque sólo disponemos de un puerto de salida para los dos.

Para el siguiente ejemplo, se considerará que el Apache con PHP5 es accesible a través de www.examplephp5.org y el otro Apache con PHP4, a través de www.examplephp4.org. Estas 2 entradas, en el DNS, apuntarán a la misma máquina física (serán 2 alias de esa máquina).

Podemos hacer las pruebas en la máquina local, añadiendo estas entradas en el fichero c:\windows\system32\drivers\etc\hosts:


127.0.0.1       www.examplephp5.org
127.0.0.1       www.examplephp4.org

¡Ojo!. Esta configuración del archivo hosts sólo sirve para la máquina local, no para un cliente exterior.

Una vez que ya tenemos nuestro entorno de prueba, veamos qué es lo que tenemos que configurar en el servicio principal (Apache2PHP5 que escucha en el puerto 80). En el fichero de configuración php5_httpd.conf debemos modificar estas líneas (descomentándolas):


NameVirtualHost *:80
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so

Y añadiremos estas:


<VirtualHost *:80>
  ServerName localhost
</VirtualHost>

<VirtualHost *:80>
  ServerName www.examplephp4.org
  ProxyPass / http://localhost:8080/
  ProxyPassReverse / http://localhost:8080/
</VirtualHost>

Tras reiniciar el servicio, podemos hacer la prueba, poniendo las URLs a nuestro fichero de prueba en el navegador web: http://www.examplephp5.org/prueba_php.php y http://www.examplephp4.org/prueba_php.php. Si todo ha ido bien, la información mostrada debe ser diferente. En el primer caso, el módulo cargado es el de PHP5 y, en el segundo, el de PHP4.

Referencias

Firefox & Proxy

2007-11-06T19:31:00.000+01:00

A veces, cuando trabajas con un portátil lo tienes que enchufar a diferentes redes. Y estas a veces te proporcionan acceso a internet a través de un proxy. Y como cada red seguro que tiene su propio proxy definido, pues hay que hacer el cambio en las preferencias de firefox a mano.

Para evitarnos tener que hacer eso hay una extensión de firefox de lo más interesante. Se llama SwitchProxy y tiene un montón de características interesantes. Entre otras, la posibilidad de añadirle un listado de servidores proxy anónimos e ir pasando de uno a otro automáticamente cada x tiempo. Con lo que tu navegación será todo lo anónima que este sistema permite (para cosas más serias, mírese tor y téngase siempre en cuenta que todo pasa por la red del proveedor ;-) y que lo único verdaderamente seguro por ahora es el cifrado fuerte)

Como colofón a esta entrada, aquí van una serie de direcciones interesantes relacionadas con el tema.

Turning Firefox to an Ethical Hacking Platform
FireCAT 1.0 Firefox Catalog of Auditing Tools released
Otras extensiones interesantes para firefox sobre el tema: ProxySel y FoxProxy (la más famosa) aunque yo me quedo con SwitchProxy Tool.
Listas de servidores proxy (no fiarse mucho): http://www.checkedproxylists.com/ y http://gonzo.teoriza.com/almacen/proxy-lista.html

Jornadas sobre la web móvil

2007-10-20T20:15:00.002+02:00

Dentro de los simposios del CEDI 2007, que se celebró en Zaragoza del 11 al 14 de septiembre, hubo uno dedicado a la web móvil, organizado por la oficina del W3C de España, la fundación CTIC y el Ayuntamiento de Zaragoza. Las conferencias de estas jornadas tuvieron lugar los días 12 y 13. El programa y las ponencias están disponibles en la página del W3C.

El resumen que se presenta a continuación está basado en el contenido de las ponencias y en apuntes personales que tomé como asistente a las mismas.

Introducción

Como ocurre en la web de escritorio (para PCs), es muy difícil desarrollar un diseño que sirva para todos los dispositivos y navegadores de los móviles. El hardware es muy diverso y tiene inconvenientes frente al mundo del PC:

Poca capacidad de proceso y memoria.
Limitado tamaño de pantalla (resolución, orientación).
Escasos colores.
Dificultad a la hora de introducir datos.
Poco ancho de banda.
Excesivo precio de las tarifas de conexión.

Los navegadores (como siempre), tampoco ayudan a mejorar el panorama pues cada uno implementa un lenguaje de marcado distinto:

Y sólo algunos tienen características avanzadas como el soporte de CSS y de JavaScript. Por si fuera poco, el abanico de navegadores disponibles es incluso mayor que en el caso de los PCs. Sin embargo, el parque de móviles se renueva mucho más rápidamente que el de ordenadores de escritorio.

El concepto de movilidad

Toda la información disponible para cualquier persona, en cualquier lugar y en cualquier instante de tiempo.

Por primera vez en la historia de la tecnología, se está más cerca de conseguir este sueño, gracias a la utilización de dispositivos móviles. Gracias a su pequeño tamaño, y cada vez más prestaciones, pueden acercarnos a la información que necesitemos en cualquier momento (como la información de proximidad). Siempre que contemos con la cobertura necesaria y si se empiezan a desarrollar servicios que cubran la gran demanda de información que puede surgir.

Aún así, Internet a través del móvil nunca será como la Internet que vemos en los ordenadores de sobremesa:

Por las limitaciones de los dispositivos y del medio de acceso.
Por las ventajas que le otorga la movilidad.
Por la diferencia en el tipo de uso y la necesidad del usuario.

La web móvil requiere que la información sea breve, concisa y que se pueda acceder ágil y rápidamente a ella. Para ello hay que recordar a los generadores de contenidos para los dispositivos móviles que, más que en ningún otro medio de comunicación, la palabra la tienen los usuarios. Si no hay buenos (y útiles) servicios, los usuarios no los consumirán.

Otro reto que queda, para las empresas que ofrecen la cobertura, es disminuir los costes para que más gente pueda acceder a los servicios creados.

Esto con respecto a Internet, pero también hay claras ventajas que aporta la movilización en aplicaciones:

Gestión en tiempo real
- Capacidad de procesar incidentes en tiempo real
- Mejor información al cliente
Mejora de productividad (evitar el envío posterior de datos)
Mejora de calidad (evitar la perdida de datos, detalles)

Desarrollo móvil

Pero para tener esas ventajas es necesario producir aplicaciones para los dispositivos móviles. En este apartado comentaremos algunas herramientas disponibles para llevar a cabo la difícil tarea del desarrollo.

Identificación de dispositivos

En primer lugar es crucial conocer las características técnicas de los dispositivos de los potenciales usuarios. Al conjunto de capacidades del dispositivo (hardware y software) y preferencias de usuario se le denomina perfil de dispositivo. Hay diversos sistemas que podemos consultar para acceder a estos perfiles:

CC/PP: Para almacenar la información usa notación RDF.

UAProf: Promovido por la Open Mobile Alliance. También se basa en RDF. Pero no están todos los que son (los grandes ausentes son dispositivos con Windows Mobile) ni son todos los que están (parte de la información puede no corresponder con datos reales).

WURFL: A diferencia de los otros sistemas, la base de datos se va completando con datos aportados por usuarios de los dispositivos móviles (es una de las ventajas por ser software libre). Esto tiene el problema de que contiene información no autentificada por los fabricante. Sin embargo, tiene la ventaja de que se puede recoger información sobre todo tipo de dispositivos (incluso de los que no tienen perfil UAProf). Además, este sistema se complementa con APIs de consulta para la base de datos (que es un fichero XML) en diversos lenguajes de programación (Java, PHP, Perl, Ruby, Python, dotNet, ...). Por todo esto, es un sistema mucho más usado y fiable que UAProf.

DDR: Con el objetivo de solucionar los problemas de UAProf, el W3C está desarrollando este nuevo sistema. El apoyo por parte de los fabricantes de dispositivos será crucial para que esta iniciativa fructifique.

Por su parte, para el desarrollo de aplicaciones en Java ME, están disponibles estas herramientas:

MIDP 2.0

CLDC 1.1

Buenas prácticas en el desarrollo de la web móvil

Reconocer las capacidades que permite el dispositivo de un usuario es sólo el inicio del camino en el desarrollo de contenidos web. Aparte de seleccionar el lenguaje de marcado adecuado a cada situación, es preciso hacer un buen diseño de arquitectura de la información para mostrar tan sólo los datos justos y precisos en cada página mostrada.

Para no dejarnos solos en esta ardua tarea, el W3C ha escrito un manual donde se recogen las buenas prácticas que nunca debemos olvidar en el desarrollo de contenidos para la web móvil: Mobile Web Best Practice 1.0 Basic Guidelines.

Como resumen de la presentación de estas normas, veamos cuáles han puesto en práctica el Ayuntamiento de Zaragoza para adaptar su web a los dispositivos móviles:

Adaptación del lenguaje de marcado

Reubicación del contenido

Particionado de los documentos

Eliminación de JavaScript

Transformación de tablas y mapas de imágenes

Imágenes: escalado y reducción de colores
- Archivos de audio: reducción de la frecuencia de muestreo
- Archivos de video: escalado y reducción de la calidad de codificación

Mecanismos de caché de información

Herramientas de desarrollo

Cuando sale un nuevo dispositivo, no siempre podremos acceder a la compra del mismo. Una buena alternativa (aunque no sea fiable al 100%), es usar emuladores. Todos los fabricantes importantes ponen a disposición de los desarrolladores emuladores de sus modelos más significativos.

Durante el proceso de diseño e implantación de la solución son herramientas esenciales, para las pruebas finales siempre sería recomendable usar los dispositivos reales, porque no siempre las emulaciones se van a corresponder con la realidad.

La otra gran herramienta que debemos tener siempre a mano es un validador de código para dispositivos móviles. Hay uno disponible en la web de TAW. Además de verificar que el código esté bien escrito, al igual que hacen con los tests de accesibilidad, nos dirá si nuestras páginas son MobileOK. Es decir, si cumplimos las buenas prácticas o no.

dotMobi

Con el fin de proporcionar un servicio de calidad a los usuarios móviles, ha nacido la iniciativa dotMobi. Estas son algunas de sus características:

dotMobi es un dominio específico para el móvil.

Cualquiera puede conseguir un dominio dotMobi, pero se compromete a cumplir esta máxima y respetar las guías de estilo obligatorias. Por ejemplo, en el caso de un site:
- Accesible como dominio de segundo nivel (bmw.mobi) (sin www.).
- Desarrollado conforme a W3C MWI.
- No frames: Muchos móviles no soportan frames.

Si un servicio dotMobi no cumple las guías de estilo, mTLD (el organismo que desarrolla esta iniciativa) iniciará un proceso de apercibimiento que podría terminar con su desconexión del DNS.

Es muy intuitivo, fácil de publicitar y de recordar.

Las páginas dotMobi son una garantía de que el contenido estará bien distribuido, no tendrá grandes fotos, no habrá texto que no se pueda ver ni información fuera de contexto o que no pueda mostrar la pantalla del móvil, ...

dotMobi Mobile Web Developer Guide ofrece información extremadamente útil con reglas para los profesionales.

Ready.mobi es un analizador de conformidad para las páginas y sites dotMobi que, además de una clasificación, ofrece recomendaciones específicas para mejorar el código empleado.

Opinión personal sobre las conferencias

El nivel de las ponencias fue grande y me ayudaron a asentar los pocos conocimientos que hasta entonces tenía sobre los fundamentos de la web móvil.

Como nota negativa, no para el simposio, pero sí para la organización del congreso, decir que la publicidad que se hizo de un evento de estas características fue bastante pobre y escasa (sobre todo en Zaragoza). Personalmente, me enteré del evento a través del blog de Torres Burriel. Si se hubiera dado la cobertura necesaria, el congreso habría tenido incluso más éxito en participación (sobre todo local) que el que no dudo que obtuvo.

A la hora señalada

2007-10-07T14:34:00.000+02:00

A veces, cuando la pila del ordenador está muy gastada o simplemente por un problema hardware, el reloj del ordenador se retrasa. Y no deja de ser incómodo el tener la hora que no toca en la esquina inferior derecha de la pantalla.

En M$ Windows existe desde su versión 2000 la posibilidad de ajustar la hora mediante un servidor de ntp. Aunque muchas veces, no se porqué no funciona del todo bien. Al final, la última vez que lidie con este problema tuve que buscar en el registro la clave HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\DateTime\Servers y cambiar su contenido por alguno de los servidores que aparecen en alguno de los links que hay al final del todo de esta entrada.

En linux es como siempre mucho más fácil. Sólo se se necesita el programa ntpdate. Y el resto de la explicación en este link.

También está la opción de utilizar un demonio para ello, con lo que se puede tener un único ordenador de la red que tenga la hora bien establecida desde internet y los demás que la actualicen desde este. Con lo que se se reduce la carga de los servidores de ntp de internet.

Para más información, mirar aquí, aquí y aquí.

Formularios web (II): Agrupación de los campos con HTML

2007-08-27T17:47:00.000+02:00

En el primer artículo de esta serie, vimos como se codificaba cada uno de los elementos del formulario de contacto en HTML. Aun siendo totalmente funcional el formulario resultante, no es muy usable porque todos los elementos están apelotonados, sin orden ni sentido. Hay que dotar de estructura y semántica al conjunto y para ello veremos varias opciones de distribución y agrupación.

Distribución libre

La primera forma de ordenar los elementos del formulario podría ser esta: form_free_layout_unstyled.html

Simplemente ponemos un retorno de carro después de cada campo y listo. Como primera aproximación, no está mal pero no es la más acertada. De hecho, recuerda mucho a como construyen algunos usuarios de un conocido procesador de textos los saltos de página: a base de retornos de carro hasta pasar de página. Pero ambos casos tienen el mismo problema: simplemente, no funcionan.

En el caso del procesador de textos, si aumentamos o disminuimos el tamaño de letra o quitamos o añadimos contenido, tendremos que cambiar el número de retornos de carro que sirven para alcanzar la siguiente página.

En el caso de nuestro formulario, la etiqueta <br /> no tiene significado alguno dentro de la enumeración de campos. Sólo tiene como objetivo mejorar la presentación. Pero la presentación no debería ser objeto de la codificación HTML, para eso ya están las hojas de estilo CSS. Mediante HTML debemos escribir el contenido de las páginas y dotarlo de significado a través de los diferentes elementos. Así pues, esta primera opción queda descartada.

Distribución basada en tabla

Es la forma más sencilla de disponer los elementos en la plantilla y la que más prestaciones de presentación ofrece, pero también es la que menos semántica aporta al contenido y la que más marcado HTML necesita.

Es sencilla si se domina la codificación de las tablas (que no es nada fácil de aprender) pero, lamentablemente, debido a un mal uso de este elemento, es fácil asumir que esta es una técnica muy conocida porque en multitud de páginas se usan para lo que no fueron hechas: para maquetar las páginas en lugar de usarlas para mostrar datos tabulados.

Ejemplo: form_table_layout_unstyled.html

Con este ejemplo se puede observar que:

Cada etiqueta queda alineada con su campo asociado.
Aunque no se aprecie, la tabla se ajusta al contenido. Es decir, no tiene un ancho del 100% de la página.

Estas ventajas que nos aporta el uso de tablas sólo tienen fines de presentación pero, hemos dicho que de la presentación ya se ocuparían las hojas de estilo, ¿no? De lo que se trata en HTML es de dotar de significado al contenido mediante el marcado. Sin embargo, lo que hemos conseguido es esto:

El título del formulario se ha convertido en un encabezado de tabla.
Hacer trabajar más a los lectores de pantalla porque hemos aumentado el marcado.
La estructura se ha convertido en algo sin sentido por utilizar las celdas de la tabla como contenedores de los campos (¿qué sentido tiene poner un botón dentro de la celda de una tabla?).

Ante estas terribles circunstancias, será mejor valorar otras opciones.

Distribución basada en lista

Para dotar de significado a la codificación del formulario, se podría pensar que los campos constituyen una enumeración (y poder utilizar entonces como contenedor el elemento ul), que puede incluso determinarse un orden en la importancia de los campos (para usar el elemento ol). Otra posible idea sería considerar que tenemos que rellenar la definición que se nos da en la etiqueta (entonces podríamos escribir una lista de definiciones con los elementos dl, dd y dt).

Ejemplo: form_list_layout_unstyled.html

Con cualquiera de estas formas se dota de estructura al contenido y de cierto significado, si alguna de las metáforas tuviera fundamento. Todas me parecen algo sacadas de contexto, sobre todo la de la lista de definiciones (aunque no me he podido resistir a ponerla en el ejemplo por ser la más rebuscada). De todas maneras, veamos si hemos ganado algo respecto al anterior punto:

Hemos conseguido la ordenación de los campos.
Hay menos marcado HTML.
Se consigue dotar de semántica al contenido (aunque no sea la más adecuada).

Distribución basada en párrafos

Antes de explicar la siguiente propuesta, vamos a hacer un pequeño paréntesis para explicar 2 elementos que dotarán de significado al formulario.

El elemento fieldset sirve para agrupar lógicamente un grupo de campos dentro de un formulario. Por ejemplo, podríamos agrupar dentro de un fieldset los datos personales (nombre y apellidos) y dentro de otro, los datos postales (dirección, código postal, etc.), todo ello dentro de un mismo formulario:


<form action="http://www.example.com/store_info.php" method="post">
  <fieldset>
    <legend>Datos personales</legend>
    <label for="first_name">Nombre:</label> <input type="text" id="first_name" name="first_name" value="" />
    <label for="surname">Apellidos:</label> <input type="text" id="surname" name="surname" value="" />
    ...
  </fieldset>

  <fieldset>
    <legend>Datos postales</legend>
    <label for="address">Dirección:</label> <input type="text" id="address" name="address" value="" />
    <label for="city">Población:</label> <input type="text" id="city" name="city" value="" />
    ...
  </fieldset>

  <fieldset>
    <input type="submit" name="send" value="Enviar" />
  </fieldset>
</form>

Aunque con el ejemplo ya se puede intuir el uso del elemento legend, vamos a explicarlo un poco más en detalle. Con este elemento se etiqueta a un grupo de campos, se describe la función lógica de ese conjunto de datos.

Como hemos visto, sólo con el uso de estos elementos ya se dota de cierta estructura al contenido pero todavía es necesario utilizar elementos de bloque para dar estructura a cada uno de los campos. Para ello, vamos a ver como queda utilizando párrafos: form_paragraph_layout_unstyled.html

Hemos cambiado el encabezado h1 por el uso del elemento legend, con lo que hemos dotado de más semántica al título del formulario. De rebote, también hemos mejorado la accesibilidad ya que los lectores de pantalla podrán describir mejor los campos del formulario.
Hemos conseguido ordenar los campos para que sea más fácil rellenarlos.
El marcado HTML no puede ser más simple ni reducido y, a la vez, no puede tener más semántica.

¿Acaso ya hemos descubierto la forma más correcta de escribir el formulario en HTML? Pues, como casi todo, es relativo y dependerá de nuestras necesidades. Hay un pequeño inconveniente en esta distribución y por eso vamos a ver un ejemplo más.

Distribución basada en divisiones lógicas

El inconveniente tiene que ver con lo que puede ir dentro de un elemento p. Existe una limitación que, en algunos casos, puede ser importante: no podemos poner otros elementos de bloque dentro (sólo es posible insertar texto y algunos elementos en línea). Esta es la razón por la que, en lugar de utilizar el elemento p, utilizaremos el elemento div.

Ejemplo: form_div_layout_unstyled.html (este será el formulario que utilizaremos en el siguiente artículo de la serie para aplicarle estilos CSS y darle una apariencia más amigable).

La legibilidad se mantiene a la hora de rellenar el formulario.
El marcado HTML es casi tan mínimo como antes e igual de sencillo.
Podemos añadir elementos de bloque dentro de cada agrupación lógica de cada campo. Por ejemplo, si se quiere adjuntar una pequeña ayuda en línea para algún campo.


...
<fieldset>
  <legend>Datos postales</legend>

  <div>
    <label for="address">Dirección:</label>
    <input type="text" id="address" name="address" value="" />

    <p>Ejemplo: calle, número, piso, letra</p>
  </div>

  ...
</fieldset>
...

Bibliografía recomendada

Formularios web (I): Elementos básicos de HTML

2007-08-19T19:57:00.000+02:00

Los formularios en las páginas web sirven para obtener datos de los usuarios. Igual que a nadie gusta rellenar largos e interminables formularios en papel, debemos tener esto, aún más en cuenta, a la hora de diseñar para la web. Para ello, podemos seguir estas sencillas reglas:

Nunca se deben pedir más datos de los estrictamente necesarios. De esta forma evitaremos pesadez al usuario y nos ahorraremos espacio en nuestro sistema de almacenamiento de datos. A este consejo habría que añadir esta recomendación: nunca pedir datos al usuario hasta que no sean necesarios para la acción que está realizando. En una tienda del mundo real, a nadie nos preguntan el número de la tarjeta de crédito hasta que no vamos a pagar en la caja.
Proporcionar valores por defecto siempre que sea posible (para rellenar menos campos y mejorar la satisfacción del usuario: cuanto menos tenga que teclear, mejor).
En los campos que necesiten información específica, es buena idea proporcionar ayuda en línea que explique cómo rellenarlo, mostrando ejemplos reales o determinando rangos de entrada.
Si hay errores en el formulario, mostrar claramente dónde se han producido y cómo resolverlos. Para los valores que sí estén correctos, habrá que recordarlos para evitar que el usuario los tenga que volver a rellenar.
Si el número de campos a completar es alto, habrá que mostrar la información en grupos lógicos que tengan relación para que sea más fácil localizarla. Incluso puede ser buena idea descomponer un formulario grande en varias páginas, simulando el funcionamiento de un asistente. Si optamos por esta opción, la navegación entre las distintas páginas debe ser clara para permitir al usuario moverse de una a otra sin perder ningún dato.
No hay nada más frustrante para el usuario que llegar al final de un formulario y equivocarse de botón (por ejemplo, pulsar el botón Cancelar y observar que todo lo que había escrito desaparece como por arte de magia). Hay que separar (o hacer más grande, o poner en una posición predominante, ...) la opción principal (que es enviar los datos) de otras secundarias (como la de restablecer los campos o volver a otra página anterior) para evitar esta situación.

Esta lista podría seguir hasta casi el infinito. El diablo está en los detalles y la diferencia entre un sitio amigable y con un buen número de visitantes puede estar en cómo, cuándo y cuánta información pide a los usuarios. Un buen estudio sobre estos y otros consejos para el diseño de formularios, podemos encontrarlo en Best Practices For Form Design.

El objetivo de esta serie de artículos es presentar un ejemplo sencillo de formulario web y ver los diferentes pasos que hay que hacer para integrarlo en una página web. Más concretamente, los objetivos de cada uno de los artículos son los siguientes:

Elementos básicos de HTML (el presente artículo): breve introducción a algunos de los elementos disponibles en HTML para la construcción de los campos.
Agrupación de los campos con HTML: hay diferentes formas de distribuir y presentar los campos de un formulario en HTML. Veremos algunas de ellas junto con sus ventajas e inconvenientes.
Diseño con CSS: una vez estructurado el contenido en HTML, llega el momento de mostrar al usuario de la forma más amigable posible el formulario.
Programación del lado del servidor: es buena idea crear una librería de código (para PHP) para construir formularios HTML puesto que es una tarea repetitiva en cualquier proyecto web.

El ejemplo que nos va a servir para ir viendo cada una de las partes (HTML, CSS y programación), es la creación de un sencillo formulario de contacto. Contendrá 3 campos: el nombre, el correo electrónico (para que podamos responder al visitante) y un campo de texto libre en el que irá el comentario que nos quieran escribir.

Campo de texto simple

En primer lugar vamos a ver como se codificaría en HTML el campo para el correo electrónico:


Correo electrónico: 

Correo electrónico: <input type="text" name="email" size="35" value="">

En principio, esta sería la forma más básica (y totalmente funcional) de construir el campo de nuestro formulario:

El atributo type indica que es un campo de texto simple (que sólo puede contener una línea de texto).
El atributo name indica el nombre de la variable que contendrá el valor del formulario.
size indica el ancho del control en la visualización, en este caso, para que quepan 35 caracteres. Nada tiene que ver con el máximo número de caracteres que pueden introducirse en el control.
Por último, el atributo value sirve para indicar el contenido por defecto que mostrará el control.

Hemos visto la forma simple, pero vamos a introducir algunas mejoras en el marcado HTML:


Correo electrónico: 

<label for="email">Correo electrónico:</label> <input type="text" id="email" name="email" size="35" maxlength="35" value="" />

El elemento label sirve para relacionar un texto (que llamaremos etiqueta) con el campo al que hace referencia. Esto se hace en 2 fases: primero se marca en el atributo id del elemento input correspondiente el identificador del campo (que puede tener el mismo valor que el atributo name) y, después, indicar en el atributo for de label el identificador del campo al que se asocia. Con esta medida mejoramos el formulario en estos aspectos:

En semántica, porque dotamos de estructura lógica al texto que hace de etiqueta del campo.
En usabilidad, porque si se pulsa sobre el texto, el foco se situará sobre el control asociado.
En accesibilidad, al proporcionar la asociación implícita entre el texto y el campo. Alguien que ve el formulario en la pantalla asocia la etiqueta al campo por la cercanía de los elementos pero para quien no lo puede ver, esa pista, por sí sola, no es suficiente.

Hemos indicado, a través del atributo maxlength la cantidad máxima de caracteres que admitirá el campo. De esta forma, por más que lo intente, el usuario no podrá introducir más caracteres de los permitidos y se evita que luego halla efectos de truncado de la información (si hubiéramos permitido introducir más pero en la base de datos no caben, tendríamos que haber truncado los caracteres sobrantes).

Como último retoque, hemos cambiado la forma en la que se cierra el elemento input (<input ... />), añadiendo una barra al final. De esta forma conseguimos compatibilidad con XHTML si queremos usar un formato más riguroso, sin perder la compatibilidad con el HTML normal porque también acepta esta forma de cerrar los elementos vacíos. Por la misma razón, los elementos y atributos siempre deben ir en minúsculas y los valores de los atributos entre comillas.

Los valores de los atributos id y name no tienen por qué coincidir. Sólo hay que recordar que se puede repetir el mismo valor de name en un formulario pero no así el valor de id, que debe ser único para cada elemento en una misma página.

Otra posible forma de codificar el campo del correo electrónico en HTML sería esta:


<label>Correo electrónico: <input type="text" name="email" size="35" maxlength="35" value="" /></label>

Escribiendo el elemento input dentro del label no hace falta indicar explícitamente la relación entre ambos elementos (atributos id y for). Pero, aun siendo totalmente válida esta alternativa, no es recomendable usarla porque puede causar algún problema en ciertos navegadores y lectores de pantalla.

Campo de texto multilínea

Continuemos viendo como escribir el código del campo Comentario. La idea es que el visitante de nuestra página escriba todo lo que quiera sin problemas de espacio. Como hemos visto antes, el elemento input se nos queda un poco pequeño pues sólo permite una línea de texto. Existe otro elemento, llamado textarea, que se ajusta mucho mejor a nuestras necesidades: el usuario puede escribir en varias líneas y viendo más texto de vez, como si escribiera un correo.


Comentario: 

<label for="comment">Comentario:</label> <textarea id="comment" name="comment" rows="4" cols="40"></textarea>

Hemos utilizado la asociación entre etiqueta y control a través de los atributos for e id, como en el caso anterior.

Los atributos rows y cols sirven para dar dimensiones gráficas al control dentro de la página (4 líneas de alto y 40 caracteres de ancho).

En este elemento, el valor por defecto que se mostraría al visitante, debemos escribirlo como contenido de la etiqueta textarea. Por ejemplo, si quisiéramos mostrar un texto de muestra, tendríamos que escribir algo como esto:


Comentario: Texto de ejemplo

<label for="comment">Comentario:</label> <textarea id="comment" name="comment" rows="4" cols="40">Texto de ejemplo</textarea>

En cambio, si lo que queremos es que el campo esté completamente vacío, no debe haber ningún caracter extra (como un espacio o un retorno de carro) entre el cierre de <textarea ... > y el comienzo de </textarea>.

Botón de envío

Ahora necesitamos añadir un botón de envío para que el usuario pueda mandarnos sus datos a un lugar donde podamos almacenar la información.




<input type="submit" name="send" value="Enviar" />

Utilizando de nuevo el elemento input, cambiando el valor del atributo type por submit ya tenemos nuestro botón. Además, este valor indica que cuando se pulse el botón, se producirá el envío de los datos al lugar especificado por el atributo action del elemento form.

En este caso, el contenido del atributo value es lo que se mostrará como texto del botón, por lo que no es necesario añadir una etiqueta con el elemento label.

Elemento form

Todos los controles de formulario que hemos visto hasta ahora, tenemos que ponerlos dentro de otro elemento, denominado form, para indicar que todos los campos forman parte de la misma transacción de información y, también, para indicar el destino de esos datos.


<form action="http://www.example.com/store_info.php" method="post">
  <label for="name">Nombre:</label> <input type="text" id="name" name="name" size="35" maxlength="35" value="" />
  <label for="email">Correo electrónico:</label> <input type="text" id="email" name="email" size="35" maxlength="35" value="" />
  <label for="comment">Comentario:</label> <textarea id="comment" name="comment" rows="4" cols="40"></textarea>
  <input type="submit" name="send" value="Enviar" />
</form>

El atributo action establece el lugar a donde irán a parar los datos del formulario. Generalmente, indicaremos la dirección de un script donde recoger y procesar la información pero también se puede indicar una dirección de correo de destino para que los datos se envíen mediante correo electrónico. Sólo recomiendo esta opción si no se dispone de otra forma de envío de datos porque el funcionamiento depende mucho de los programas con los que cuente el usuario en su máquina para enviar el correo.

Según el método de codificación de datos indicado en el atributo method, la información tendrá que ser decodificada de forma diferente en el lado del servidor porque se enviará de distinta forma desde el navegador cliente. Para simplificar esta cuestión, diré que el método post es algo más seguro y permite enviar más datos en la transacción.

Antes de terminar, quisiera comentar el uso del atributo title dentro de los campos para simular una sencilla ayuda contextual para rellenar el control.


Correo electrónico: 

<label for="email">Correo electrónico:</label> <input type="text" id="email" name="email" size="35" maxlength="35" value="" title="Se requiere una dirección de correo válida" />

Aunque su uso no es totalmente eficaz, pues sólo aparece si nos posicionamos sobre el control y no es un buen sistema para textos largos, sin embargo puede servir si el mensaje no es muy largo, además de ser una solución accesible para los programas lectores de pantalla.

Para una información más detallada sobre otros elementos que se pueden agregar en los formularios (como listas despleglables o casillas de verificación), recomiendo la lectura de los siguientes enlaces:

Bibliografía recomendada

Pruebas de una web

2007-04-14T19:15:00.000+02:00

Hay muchas formas de probar una página (o un sitio) web. Disponemos de validadores automáticos que nos pueden dar una primera valoración del trabajo realizado y que también ayudan durante el proceso de desarrollo, para saber si vamos por el buen camino:

Pero estos validadores automáticos tienen algunas carencias, que sólo se pueden cubrir con otra serie de pruebas (manualmente en muchos casos). Dependerá de factores como el público al que está orientado nuestro sitio web, el realizar todas o algunas de las siguientes pruebas.

Navegadores

Las páginas web pueden verse en diferentes en muy distintos navegadores y en muchas posibles configuraciones. Como mínimo, será necesario probar en este subconjunto de navegadores:

Firefox

Este primer lugar en la lista no es por casualidad. Es un navegador en constante desarrollo, con un buen nivel de seguimiento de los estándares y que cuenta con una serie de herramientas (extensiones) que facilitan la realización de una página web.

MSIE

Es el más usado y con el que más cuidado habrá que tener, ya que sus diferentes versiones (5.5, 6.0, 7.0 entre otras) son muy diferentes entre sí. Dependerá de nuestro público objetivo el soportar más o menos versiones de este navegador. Seguramente, deberemos saltarnos algún estándar (CSS sobre todo) para adecuar nuestro trabajo a las particularidades de este cliente web. Esta es una de las razones por las que un validador automático no siempre es una buena medida de la situación.

Opera

Tiene menos seguidores que Firefox, pero tiene una mejor implantación de los estándares. Además, su versión para dispositivos móviles puede extenderse casi tanto como MSIE en los próximos años.

Safari

Es un navegador específico para Mac OS X. Esta en esta lista por 2 razones: porque cubre una parte importante de los usuarios de esta plataforma y (una razón más técnica) porque utiliza internamente otro motor de renderizado de páginas distinto de los anteriores, que también deberemos tener en cuenta (diferente motor => distintas reglas que pueden tener bugs y que tendremos que solventar).

Lynx

Es la nota exótica de esta lista. Pero no por ser exótica, está de más saltársela. Aunque su uso está relegado a unos cuantos geeks de sistemas Unix y Linux, tiene poderosas razones (prácticas) para estar aquí: nos da una buena aproximación a cómo se ve nuestra página en ausencia de CSS, imágenes, JavaScript y nos permite probar la navegación sin ratón entre los contenidos del sitio web.

Todas estas pruebas se pueden simular por separado con otras herramientas, pero con este navegador de sólo texto podemos llevar a cabo estas pruebas de una sóla tacada. Si no podemos acceder a una versión de este programa (y eso que la hay hasta para Windows), siempre podemos tener acceso a una simulación online.

Configuraciones de navegadores

Según la plataforma que utilice el usuario, el abanico de posibilidades de configuración de un mismo navegador puede ser extenso. Ante todo, para valorar el resultado de las siguientes pruebas, hay que ver si nuestra página se degrada elegantemente (graceful degradation). Es decir, como reacciona la página ante la pérdida de funcionalidad.

Sin imágenes

Si el cliente no dispone de una conexión rápida, puede que tenga desactivada la descarga de imágenes. Si es así, el contenido de nuestra página deber seguir siendo legible. Es una buena prueba para ver cómo se adaptan los textos alternativos de los elementos gráficos dentro del resto del contenido escrito.

Sin JavaScript

No es una situación tan extraña si recordamos que muchas personas, en su trabajo, por cuestiones de seguridad (que no pueden cambiar), tienen deshabilitado el soporte de JavaScript en sus navegadores. Así pues, ante esta circunstancia, la página debe seguir operativa, prescindiendo de la funcionalidad añadida que le daba JavaScript).

Esto, aunque ideal, no siempre puede cumplirse (sobre todo, en aplicaciones web). Por ello, al menos, se deberá mostrar un mensaje aclarando por qué la página no puede funcionar.

Sin cookies

Por las mismas razones que el apartado anterior, el soporte de cookies, por motivos de seguridad, no siempre está garantizado. Cómo reaccionar ante esto, dependerá del contexto de nuestro sitio web.

Sin plugin de Flash

Si gran parte de nuestro contenido se basa en el uso de Flash, puede que estemos en un grave problema si nuestros usuarios, o bien no tienen el plugin, o bien no tienen la versión adecuada. Habrá que verificar como de legible es nuestro contenido ante la ausencia de Flash.

Sin CSS

Aunque hoy en día esta circunstancia ya no es muy frecuente (hay muy pocas personas que todavía utilicen navegadores antiguos sin soporte para CSS), sí que es útil probar a leer y a navegar por el contenido sin estilo. De esta forma veremos si hemos utilizado correctamente los elementos HTML a la hora de construir la página (los encabezados, las listas, si no hemos utilizado tablas para maquetar, etc.).

Configuraciones de pantalla

Si diversos son los navegadores que nos pueden visitar, también son diferentes las propiedades de los monitores que usarán los visitantes.

Resolución

¿Qué resoluciones deberemos soportar: 800x600, 1024x768, 1280x1024, 1600x1200, ...? Y la lista sigue y sigue. Pero la respuesta es simple y a la vez complicada de resolver: todas ellas. O bien nuestra plantilla es lo suficientemente fluída como para adaptarse a las distintas resoluciones o bien cambiamos la plantilla dependiendo de la resolución (esto se puede hacer mediante JavaScript).

Sinceramente, creo que lo mejor y más pragmático es lo primero: hacer un diseño fluído que se adapte lo mejor posible a todas las resoluciones posibles. Con las demasiado pequeñas o las demasiado grandes tal vez el resultado no sea el más adecuado, pero para el resto de rangos, será óptimo (pero si no lo probamos, no lo sabremos).

Colores

Si difícil es hacer un diseño (en cuanto a disposición de los elementos), más difícil es aún conseguir una buena paleta de colores para ese diseño. Una buena paleta que consiga un buen contraste entre fondo y texto y que diferencie de un vistazo distintos elementos.

Una buena prueba para probar un contraste adecuado, es poner en escala de grises la página. Esto podemos conseguirlo cambiando nuestra configuración de escritorio o utilizando esta herramienta online para simular defectos de visión. Nos dará una buena medida de la accesibilidad de nuestra página (pensando en usuarios con problemas en la visión y para evitar que nuestros visitantes tengan estos problemas de visión).

También podemos hacer pruebas de otros problemas de visión (como el daltonismo), a través del servicio online de Vischeck.

Probar la página a 256 colores, hoy en día, no creo que sea necesario. Al igual que el número de usuarios con navegadores del siglo pasado, el número con configuraciones tan restrictivas, es muy pequeño. A no ser que sepamos, a ciencia cierta, que alguno de nuestros potenciales clientes pertenece a este reducido grupo, podemos prescindir de esta prueba.

Formato de impresión

¿Qué tal se imprimen nuestros contenidos? Aunque es más ecológico (y algunas veces más cómodo) guardar en formato electrónico una página web, en ocasiones, es interesante imprimir algunas páginas, o exportar a PDF.

Hay unas cuantas recomendaciones que conviene seguir para conseguir un buen formato de impresión, pero todas tienen un denominador común: la simplicidad. Se deberá prescindir de todos los elementos del diseño que no aporten nada al contenido principal de la página.

Sistemas operativos

Para cuidar el diseño de la página, habrá que elegir un conjunto de fuentes de letras adecuadas a los distintos sistemas operativos, porque no todas están en todos ellos. Habrá que probar estas elecciones en cada uno de los sistemas que hayamos optado por hacer nuestro desarrollo. Una forma de ahorrar en máquinas físicas (hardware), es hacer uso de máquinas virtuales.

Cada sistema operativo tiene sus propias herramientas de virtualización:

Microsoft Windows: Virtual PC, VMWare
Linux
Mac OS X: iEmulator

Otro aspecto a tener en cuenta en las diferentes plataformas, serán los plugins que tengan unas y otras. No todas soportan el uso de ActiveX (por ejemplo), o no todas poseen las mismas versiones de los plugins (como el de Flash).

Redes lentas

Puede que hayamos hecho un sitio demasiado recargado o que utilice demasiados ficheros. Una forma de probar si nuestro sitio es rápido (en cuanto a velocidad de descarga), es probándolo en una red lenta. Esto se puede conseguir utilizando un módem o un programa limitador de la red, como NetLimiter.

Dispositivos móviles

¿Está nuestra página preparada para ser vista desde un móvil? ¿Tiene que estarlo? La respuesta a estas preguntas, es un rotundo sí. Las ciencias adelantan que es una barbaridad y seguramente, dentro de poco tiempo (si no es ya mismo), la gran mayoría de nuestros visitantes lo harán a través de alguna clase de dispositivo móvil.

Debemos preparar nuestro sitio web para esta circunstancia y deberemos probarlo. La opción más económica es hacerlo a través de emuladores de dispositivos móviles. Cada fabricante suele tener disponibles en su web unos cuantos de los modelos que va sacando al mercado.

Lectores de pantalla

Otra forma de probar la accesibilidad de una página web, es leerla tal y como la leería un lector de pantalla para un usuario invidente.

Como estos dispositivos suelen ser bastante caros (como Jaws), la mejor forma de hacer nuestras pruebas será, una vez, a través de emuladores.

Uno de ellos se llama Fangs y es una extensión para Firefox.

Dos programas

2007-03-14T12:31:00.000+01:00

A veces uno descubre programas que se le acaban convirtiendo en casi imprescindibles. Sobre todo cuando se necesitan compartir datos entre Linux y Windows o entre el trabajo y casa.

Programas como OpenOffice portable, Firefox portable o Putty portable. Todos ellos descargables desde PortableApps y que pueden correr desde un lapiz usb sin dejar rastro en el ordenador en el que estás. Y que, como he dicho antes, puedes usar igualmente en Linux y en Windows (Putty tal cual no, pero para eso está ssh).

Aún así, he encontrado dos programas que no están en esa página y que utilizo sin parar desde que los encontré:

KeePass: Gestor de contraseñas. Después de probar varios de ellos tanto libres como 'pirateados', me quedo con este de lejos. Versión para windows y linux, tiene un campo de comentarios grande para cada entrada, generador de claves mediante aleatoriedad (del tamaño y complejidad que se quiera) y se pueden adjuntar archivos en las entradas. Lo uso principalmente para las claves del trabajo, pero también para las de casa.
TreeLine: Gestor de notas, outliner, no sé cómo llamarlo. Pero desde luego, de nuevo, otro que me ha enganchado. Sirve para casi todo. Es como una base de datos donde los datos pueden ser estructurados y buscados de la forma que mejor te convenga (viva el XML!!!). Hecho de menos el uso de etiquetas en vez de la forma de arbol, pero como es tan configurable, se las puedes poner igualmente en el registro/s que te crees. Adiós a las notas que pierdes o que no puedes encontrar, los papelitos por encima de la mesa, las 200 ideas diferentes apuntadas una entre otra en una hoja de cuaderno. Los cuadernos de notas no son en absoluto algo obsoleto, pero desde luego son menos versátiles que este tipo de aplicaciones. Imprescindible (creo yo) para programadores, administradores y demás geeks informáticos. Programado en python, con versión para Linux y Windows y permite cifrar el fichero de notas (algo creo que imprescindible para un programa portable de los de llevar en un pendrive).

Desde luego que existen programas on-line que permiten lo mismo. O incluso quizá más versátiles (como google notebook y su sistema de etiquetas o PassPack como gestor de claves on-line). Pero a mi no me gusta mucho dejar estas cosas en los servidores de otros. Mejor en mi disco local ;) por si acaso.

Por cierto, para ver cómo hacer TreeLine portable, buscarlo en esta página. Hay muchas instrucciones de cómo hacer aplicaciones de primeras no portables, portables.

Seguridad informática

2007-02-14T15:30:00.001+01:00

"La defensa necesita cubrir todas las vulnerabilidades. El atacante sólo necesita explotar una."

Mr_Marshall.

Leido en los comentarios de Kriptópolis.

Usabilidad y cartografía medieval

2007-01-28T18:58:00.000+01:00

El pasado día 18 de enero, asistí al laboratorio sobre cartografía medieval que impartió Javier Mendívil en Cadius Zaragoza. Mi visión particular de aquel acto, va a consistir en ver algunos problemas de usabilidad comunes entre mapas y páginas web, y mencionar directrices de cómo solucionarlos. Eso sí, quisiera agradecer a Javier, tanto los magníficos contenidos impartidos en el laboratorio, como los complementarios que iban como regalo para los asistentes.

Contenido denso

La apariencia de una página llena de texto y de imágenes sugiere que será difícil obtener la información que se está buscando. No es posible rastrear bien el contenido.

En un sitio web, esto es aún más problemático que en un mapa, puesto que el usuario simplemente decidirá que no merece la pena invertir esfuerzo en la búsqueda, y se irá a otra página.

Habrá que redactar contenidos más cortos, que vayan al grano, que hablen el mismo idioma que la clientela a la que está dirigido el contenido, y saber jugar con el espacio en blanco en el diseño para que los usuarios puedan centrar su atención en el rastreo de la información.

Diseño relleno

Muchas páginas web comenten el error de abrumar a los usuarios con elementos móviles, luces parpadeantes y enlaces mal estructurados.

No hay necesidad de poner más gráficos que los necesarios y a un tamaño manejable. No hace falta perder el tiempo y el espacio en decorar, sino en comunicar. Los sitios web deberían ir directos al negocio, que es lo que buscan los clientes.

Artilugios de interfaz gráfica de usuario de diseño propio

Algunos diseñadores de interfaz, prefieren no seguir las convenciones existentes para ciertos elementos de diseño, como campos de introducción de datos (cajas de texto, botones de radio, casillas de verificación) o las barras de desplazamiento. En muchas ocasiones por ser sitios construidos en Flash o por intentar diferenciar el diseño del sitio web.

Si algo no parece lo que es, seguramente no se percibirá como tal y no se usará correctamente. Esto se traduce en que si se están pidiendo datos al usuario, tal vez este no logre enviarlos, o que si se está cambiando la forma de una barra de desplazamiento, al no reconocerse como tal, no se utilice y se pierda contenido importante.

No mostrar quién está detrás de la información

Al igual que para dar credibilidad de una obra vale con una firma, para dar credibilidad y confianza a los usuarios de un sitio web, es conveniente añadir información sobre la compañía (o las personas) que están detrás.

Es muy común facilitar esta información en páginas tituladas Acerca de nosotros o Quiénes somos. En ellas debe figurar claramente como contactar y encontrar la compañía, la filosofía de la organización y, como información auxiliar, no estaría mal añadir algunos hechos relevantes en la historia de la empresa.

Legibilidad

La tipografía ofrece una idea sobre el sitio web y transmite información acerca de lo que el usuario puede hacer en él. Las distintas fuentes de letra pueden significar capricho o seriedad y el tamaño y el color pueden destacar el contenido.

Pero si el tamaño no es legible, ya sea por el tamaño o por la grafía, se convierte en incómodo y molesto, y el usuario desistirá de leer el contenido aunque le pueda resultar de interés.

Para contenidos en pantalla, es mejor utilizar letras sin serifa. Para titulares, puede utilizarse tanto letras con serifa como sin ella porque el tamaño será mayor y habrá menos problemas con la resolución. En tamaños pequeños, las letras con serifa se vuelven borrosas por el suavizado de los bordes dentados.

Si, por cuestiones de diseño, se ha elegido un tamaño menor al recomendable (12 puntos), siempre hay que dar la posibilidad de que el usuario pueda aumentar el tamaño, ya sea mediante alguna herramienta del navegador o proporcionando enlaces (o botones) en la página para agrandar el texto. Para que desde el navegador siempre se pueda cambiar el tamaño del texto, es mejor usar tamaños relativos.

Contraste entre texto y fondo

Leer en pantalla es mucho más costoso que leer en papel porque existe menos resolución para pintar las letras. En un libro podemos tener unos 3000 puntos por pulgada (dpi), mientras que en un monitor podemos haber 100 dpi como mucho (lo normal suele ser 72 dpi).

Los contrastes altos entre texto y fondo pueden hacer la lectura más fácil. Aunque lo mejor sigue siendo texto negro sobre fondo blanco, la norma a seguir es evitar el uso de colores similares, ya que el bajo contraste cansa la vista causa molestias. Tampoco es recomendable utilizar combinaciones de colores brillantes porque causan un efecto vibrante en los textos (como usar texto rojo sobre fondo azul).

Palabras clave resaltadas

Resaltar las palabras importantes de un texto atraen la atención del lector hacia áreas específicas. Sin embargo, resaltar frases completas o demasiado largas, ralentiza la lectura, porque enfatizar demasiados elementos, causa el efecto contrario: nada destaca, todo parece igual de importante.

El extracto del listado de problemas de usabilidad ha sido obtenido del libro Prioritizing Web Usability, escrito por Jakob Nielsen y Hoa Loranger, disponible en español en la colección de Anaya Multimedia.

Los elementos perdidos de HTML

2007-01-03T16:37:00.000+01:00

Soy una de esas personas que, cuando miran una nueva página web, no se fijan tanto en lo que se ve a simple vista como en el esqueleto que le da forma: el código fuente. Ahí es donde se puede apreciar la verdadera estructura del contenido y la semántica que se ha utilizado (la que se encontrarán los motores que indexen esa página web).

Bien es verdad que HTML tiene algunas carencias para marcar el contenido, que se están intentando solucionar con la redacción de XHTML 2.0 o HTML 5.0 (que todavía está más en pañales que XHTML 2.0). Pero también es cierto que, algunos elementos que sí posee, no son utilizados (en los casos en los que se deberían utilizar). Tal vez sea por desconocimiento o por usar algunos editores WYSIWYG (bien sean de escritorio como DreamWeaver o bien estén hechos en JavaScript como TinyMCE), pero no debemos olvidar que para darle un correcto significado al contenido, hay que marcarlo de la forma adecuada.

No debemos caer en la tentación de marcar en función de la presentación que luego los navegadores dan a esos elementos. Hay que recordar que siempre podemos cambiar la presentación gracias a las hojas de estilo en cascada (CSS).

Marcado de edición de textos

ins y del

Cuando estamos desarrollando un documento, hay cosas que no siempre se escriben bien a la primera, o bien luego hay que hacer algún ajuste o actualización. HTML nos permite marcar los cambios, ya sean añadidos o borrados, con las etiquetas ins y del. De esta forma, al igual que en otros editores de texto, de un vistazo, se pueden descubrir los cambios en el documento.

Además, estas etiquetas tienen 2 atributos que sirven para saber las razones del cambio (cite) y cuándo se realizó dicho cambio (datetime). El formato de este último atributo es un poco especial y riguroso. Está basado en esta plantilla: YYYY-MM-DDThh:mm:ssTZD

YYYY: año con 4 dígitos
MM: mes con 2 dígitos (01-12)
DD: día con 2 dígitos (01-31)
T: caracter separador entre fecha y hora
hh: hora con 2 dígitos (00-23)
mm: minutos con 2 dígitos (00-59); es información opcional
ss: segundos con 2 dígitos (00-59); es información opcional
TZD: zona horaria, Z para hora Zulú (la del meridiano de Greenwich) o desfase en horas y minutos (positivo o negativo) del huso horario correspondiente

Más información sobre la plantilla de datetime en ISO 8601 de la Wikipedia.

Ejemplo de uso de los elementos ins y del:
<p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit<ins cite="lorem ipsum..." datetime="2007-01-05T13:24+01:00">, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat</ins>. Ut wisi enim ad minim veniam<del cite="lorem ipsum..." datetime="2007-01-04T08:21:34-05:00">, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat</del>. Duis autem vel eum iriure dolor in hendrerit in ...</p>

bdo

Otro desconocido elemento para la edición de textos es bdo. En inglés, bdo es la abreviatura de bidirectional override, y si nos atenemos a esta definición, podemos adivinar su función: sobreescribir el tratamiento direccional del texto para el contenido que se encierre dentro del elemento.

Por si no ha quedado claro, intentaré explicarlo mejor. Uno de los atributos de la etiqueta html es dir, que sirve para indicar cómo se debe escribir (el navegador) el texto que contiene el documento, es decir, si se escribe de izquierda a derecha (ltr) o de derecha a izquierda (rtl).


<!DOCTYPE html
 PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="es" dir="ltr" lang="es">
...

Como se puede ver en el ejemplo, con el atributo dir se define la legibilidad de todo el documento pero, ¿qué ocurre si dentro de un texto que se lee de izquierda a derecha, necesitamos incrustar algo de contenido que está en otro idioma y además se lee al revés? Para eso existe el elemento bdo. Veámoslo con otro ejemplo:


...
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="es" dir="ltr" lang="es">
...
<p>Contenido en idioma español. Se escribe de izquierda a derecha.</p>
<p><bdo lang="zh-TW" dir="rtl">Contenido en otro idioma (chino tradicional) que se redacta de derecha a izquierda.</bdo><p>
...

Como se puede ver en el ejemplo, se ha definido un idioma y una dirección de escritura general para el documento (en la etiqueta html) y luego se ha marcado el texto en otro idioma (que si supiera chino, estaría correctamente escrito ;-) ) gracias a la etiqueta bdo.

Etiquetas de estilo basado en contenido

cite

cite sirve para indicar que el texto que contiene es una referencia bibliográfica. Junto con el elemento para enlaces (a), puede servir para hacer referencia a otro documento donde se encuentra la fuente que hemos citado.


<blockquote lang="en-GB">You can't always get what you want; but if you try sometimes, you just might find, you get what you need.</blockquote>

<p><cite><a href="http://en.wikipedia.org/wiki/You_Can't_Always_Get_What_You_Want">Rolling Stones</a></cite></p>

code

La etiqueta code indica que el texto que encierra es código fuente de programación. Esto hace que los navegadores utilicen (por defecto y a no ser que establezcamos lo contrario con CSS) una fuente monoespaciada (todos los caracteres tienen la misma anchura) para visualizar el texto.


<pre><code lang="en-US">
/**
* string numberToAlphabet(int $number)
*
* Converts an integer in an alphabetical string (1 <= $number <= 702)
*
* @author PHP manual, user contributes notes for chr() function
* @param int $number integer to convert
* @return string alphabetical string
* @access public
*/
function numberToAlphabet($number)
{
 return ($number-- > 26 ? chr(($number / 26 + 25) % 26 + ord('A')) : '') . chr($number % 26 + ord('A'));
}
</code></pre>

En el ejemplo, se ha encerrado el contenido de code dentro de la etiqueta pre por 2 razones:

code es una etiqueta para texto en línea (es decir, tiene [o debe] ir dentro de otra etiqueta de bloque distinta de body, que sólo debería contener otros elementos de bloque)
con el uso de pre se preservan los espacios y líneas en blanco del texto, necesarios para dar formato al código fuente

dfn

La etiqueta dfn se utiliza para marcar los términos (y no las definiciones) nuevos (o especiales) de un documento que necesitan la atención del lector. Como regla de buen estilo, sólo se delimita la primera aparición del término en el texto.
<p>El software libre es también llamado software de código abierto. La razón por la que se llama así es que, junto con el <dfn>programa objeto</dfn>, se distribuye el <dfn>código fuente</dfn> del mismo.</p>

Para definir los conceptos (como cuando se escribe un glosario de términos) existe otro conjunto de etiquetas:

dl: lista de definiciones
dt: término a definir
dd: definición del término


<dl>
 <dt>Programa objeto</dt>

 <dd>Instrucciones que se ejecutan directamente contra la máquina y que no son comprensibles por las personas.</dd>

 <dt>Código fuente</dt>

 <dd>Instrucciones escritas en un lenguaje de programación que el ser humano puede leer pero que no comprende directamente la máquina.</dd>
</dl>

kbd

kbd es la forma más indicada de indicar que un determinado texto es introducido desde el teclado (keyboard). Es muy útil para el caso de redactar manuales o cualquier otro tipo de documentación técnica.


<pre><samp>
C:\><kbd>c:\mysql\bin\mysql -uadmin -p mysql</kbd>
Enter password: <kbd>*********</kbd>
</samp></pre>

samp

Como se ha podido ver en el ejemplo anterior, en el que hemos hecho uso ya de la etiqueta samp (sample), esta sirve para mostrar la salida de algunos programas o ejemplos de código fuente (como los que estoy utilizando en este artículo).

var

La etiqueta var se utiliza para marcar texto que sirve de plantilla, es decir, para texto que no se debe introducir tal cual, sino que debe reemplazarse por otro a la hora de teclearlo. Como ejemplo, puede servir este extracto donde se combinan además otras etiquetas vistas anteriormente.


<p>Verifique su base de datos y usuario accediendo a la nueva base de datos con el nuevo usuario.</p>

<pre><samp>
C:\><kbd>C:\mysql\bin\mysql -u <var>new_user</var> -p<var>new_password</var> <var>new_database</var></kbd>
</samp></pre>

Notas finales

Para la redacción de este artículo he utilizado algunas deficiones y ejemplos que aparecen en el libro HTML y XHTML: La Guía Definitiva, original de la editorial O'Reilly pero traducido al español por Anaya Multimedia.

En los ejemplos expuestos se ha usado el punto de vista de quien codifica la página, por eso se muestra el código fuente necesario para marcar el contenido. Queda a disposición del lector la prueba de dichos ejemplos en su propio navegador para ver cómo se visualizan. Se ha optado por hacerlo de este modo porque no existen reglas fijas de presentación y estas pueden diferir entre diferentes agentes de usuario (navegadores web).

Actualización (2007-01-04):
Sólo un día después de la publicación de este artículo, me encuentro con esta guía de marcado semántico. Para quienes deseen completar esta lectura, se lo recomiendo encarecidamente: se habla también del correcto uso de los elementos más habituales (encabezados, párrafos, listas, ...) y hay más ejemplos sobre la adecuada utilización de las etiquetas de HTML.

Grub

2006-12-25T03:13:00.000+01:00

A veces, cuando uno toca lo que no debe o instala sistemas operativos que no respetan para nada el actual MBR, el resultado es que intentas arrancar y o bien te es imposible, o te arranca el bendito Windows. Últimamente he tenido que reinstalar GRUB en el arranque de mi máquina y nunca me acuerdo de cómo se hace, así que siempre tengo que acudir a Google a mirarlo. Pues bien, si me lo apunto aquí seguro que sabré dónde ir a buscarlo:

Arrancar con una Live-CD que disponga de GRUB (como Kubuntu/Ubuntu, Knoppix). O con cualquier distribución que entre sus opciones de arranque esté el modo rescate (rescue mode - F5 - linux rescue).
Ejecutar grub desde consola y en el intérprete de comandos de GRUB:

root (hd0,1) # en mi caso /dev/sda2
setup (hd0) # /dev/sda
quit

Y listos. Ya podemos reiniciar y sacar el cd. Tendremos el menú de GRUB tal cual estaba antes de liarla.