Saltar al contenido

Artículos, tutoriales, trucos, curiosidades, reflexiones y links sobre programación web ASP.NET Core, MVC, Blazor, SignalR, Entity Framework, C#, Azure, Javascript... y lo que venga ;)

17 años online

el blog de José M. Aguilar

Inicio El autor Contactar

Artículos, tutoriales, trucos, curiosidades, reflexiones y links sobre programación web
ASP.NET Core, MVC, Blazor, SignalR, Entity Framework, C#, Azure, Javascript...

¡Microsoft MVP!
viernes, 30 de junio de 2006
Hoy vamos a dedicar un poco de tiempo a resumir las etiquetas existentes en XHTML. Como comenté en el post anterior, han desaparecido las relacionadas con aspectos estéticos (por ejemplo, <font> ha sido repudiado) y ahora toman más sentido los tags que describen el contenido del documento desde un punto de vista semántico, delegando los aspectos visuales a las hojas de estilo (CSS).

A pesar de haberse reducido en número respecto a HTML4, siguen siendo bastantes, por lo que las dividiré en varios posts. En este sólo trataremos las estructurales, que componen el esqueleto básico de un documento XHTML y definen algunas de sus propiedades, y las de texto, que permiten adornar el contenido de un documento con información semántica.

Etiquetas estructurales
  • body, que indica el comienzo del cuerpo de la página.
  • head, que contiene la sección de encabezado de la página XHTML. Su contenido no será mostrado, y se utiliza principalmente para recoger aspectos genéricos, como el título y metainformación sobre el documento.
  • html, la etiqueta raíz del documento XHTML. Antes de ella sólo existirán las destinadas a indicar los tipos de documento.
  • title, que permitirá indicar el título de la página.

Estiquetas de texto

  • abbr, que permite señalar las abreviaturas e indicar su significado.
  • acronym, idem, con los acrónimos.
  • address, utilizado para indicar localizaciones o direcciones de contacto.
  • blockquote, marca una cita textual de otro documento, destacada como un bloque independiente.
  • br, que fuerza la ruptura de una línea en un texto. Es importante destacar que, a diferencia de HTML, este tag debe ir cerrado, es decir, escribirse como <br />
  • cite, también indicado para recoger citas, pero en la misma línea, sin necesidad de iniciar un nuevo párrafo.
  • code, ideal para incluir código fuente de programas, ejemplos, etc. Cuidado al mostrar código HTML, que los caracteres < y > no pueden ser incluidos directamente, sino a través de las correspondientes entidades, &lt; y >.
  • dfn, que permite definir términos cuando, por ejemplo, aparecen por primera vez en un documento.
  • div, una de las principales herramientas disponibles para estructuración de bloques que componen un documento. Todo lo que se incluya entre la etiqueta de apertura y de cierre será tratado como un bloque, al que se podrán aplicar atributos de forma conjunta. Por ello, en la práctica, cada área o grupo de elementos estructuralmente importante irá incluido en su propio div (p.e.: el menú de la web, el encabezado, el pie...).
  • em, que permite destacar (emfatizar) partes del texto. Normalmente es un énfasis light, y habitualmente es representado en cursiva; para destacar de forma más violenta, es conveniente usar el tag <strong>.
  • h1, h2... h6, indican que un texto es un encabezado de una sección posterior. Hay seis niveles de encabezado posibles.
  • kbd, utilizado para marcar texto que debe ser introducido por el usuario mediante teclado. Puede ser interesante en documentos técnicos o manuales on-line.
  • p, este sí que es el de siempre. Permite indicar el inicio y fin de los párrafos que componen un texto. Importante: debemos cerrarlo siempre, aunque HTML no nos obligara a ello.
  • pre, que indica que su contenido está preformateado; a efectos prácticos, todo lo incluido entre el <pre> y el </pre> será visualizado incluyendo los espacios, tabulaciones y rupturas de línea literalmente, tal y como hayan sido incluidas en el código.
  • q, otro tag que posibilita la inclusión de citas. La verdad es que, existiendo cite y blockquote, este resulta algo obviable.
  • samp, que permite incluir ejemplos de resultados o salida de procesos y programas.
  • span, que, como ocurría con la etiqueta <div>, se utiliza para delimitar porciones de contenido que pueden ser manipuladas, a nivel de presentación, conjuntamente. En cambio, <span> no fuerza el salto de línea, ni las separaciones presentes en el citado anteriormente, todo se realiza en la misma línea donde se encuentra.
  • strong, utilizado para resaltar su contenido, de forma "fuerte". En la práctica, es habitual que la representación visual se realice en negrilla.
  • var, usado para indicar que su contenido es un nombre de variable o de componente de un sistema software.

En el próximo post seguiremos enumerando y describiendo brevemente más tags pertenecientes al estándar XHTML 1.1., que nos permitirán definir enlaces hipertexto, listas, incluir objetos y muchas cosas más.

lunes, 26 de junio de 2006
Voy a intentar recoger de forma muy resumida los aspectos que he visto más interesantes para iniciarse con XHTML, sobre todo aquellos que marcan la diferencia respecto a las técnicas tradicionales basadas en HTML estándar o algunos de sus dialectos.

Comenzando por donde hay que hacerlo normalmente, por el principio: ¿qué es XHTML? Así al vuelo, podríamos definir el eXtensible HyperText Markup Languaje es una reformulación de HTML en XML. Es decir, una formalización del habitual lenguaje de marcas, utilizando unas normas sintácticas más estrictas, e introduciendo al mismo tiempo una fuerte separación entre los aspectos semánticos de una página Web, que será lo que recojan las páginas, y su presentación, descritas mediante CSS.

Recordemos que la semántica hace referencia al significado del contenido, independientemente del formato en que esté presentado. Esto implica, por ejemplo, que en XHTML no podremos utilizar la etiqueta <font color="blue"> para poner en azul un texto (¡esto es presentación!); sí podremos, por ejemplo, indicar que una porción del texto es importante con la etiqueta <em> o <strong> y más tarde, en la hoja de estilos, indicar que las cosas importantes queremos que aparezcan en negrita, en azul, o como sea. La buena noticia es que, dado que no se pueden usar las etiquetas habituales de formato, el conjunto de éstas se reduce considerablemente.

En cuanto a la sintaxis, deberemos acostumbrarnos a escribir siempre los tags en minúsculas; XHTML, como XML que es, es sensible á este aspecto del código. Los que estábamos acostumbrados a escribir las etiquetas siempre en mayúsculas para distinguirlas del resto, vamos a tener que ir cambiando de hábitos.

También es imperativo el cierre de todas las etiquetas; como en XML, toda etiqueta de apertura tiene que tener su correspondiente etiqueta de cierre. Es decir, nada de:

<img src='zxc.gif'>

Esto deberá convertirse, a partir de ahora en:

<img src='zxc.gif'></img>

Por suerte, los señores que inventaron el XML debían sufrir dolores en las articulaciones, por lo que decidieron que esto podría simplificarse así:

<img src='zxc.gif' />

(El espacio justo delante de la barra de cierre es a propósito, parece ser que hacerlo de otra forma causa problemas en navegadores antiguos).

Hay algún otro aspecto sintáctico adicional, como la conveniencia de sustituir caracteres especiales por su entidad correspondiente (como el ">", que debe ser sustituida por "&gt;"), el uso obligatorio de comillas para los valores asignados a los atributos, y algún otro, pero, en general, lo dicho hasta el momento es lo más importante (aparentemente al menos).

El siguiente ejemplo muestra un documento XHTML válido completo:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="es">
<head>
<title>El saludo habitual</title>
</head>
<body>
<p>¡Hola, mundo!</p> </body></html>

Destacan los siguientes detalles:

  • Tal y como se define en la primera línea, se trata de un documento XML. Esto quiere decir que deberá ser bien formado según las reglas generales de este lenguaje. Si, por ejemplo, olvidamos cerrar un tag, el documento no será válido y, por tanto, podría no ser representado.
  • A continuación se define el tipo de documento, XHTML 1.1 en este caso, y la DTD o definición del tipo de documento que permitirá detectar su validez respecto a ésta; por ejemplo, un documento no sería válido XHTML 1.1 si introdujéramos un tag <img> dentro de otro, lo cual no tiene sentido. Por cierto, se está trabajando en la versión 2.0, pero se prevé que no estará lista hasta 2007.
  • La siguiente línea define el elemento raíz del documento, con la etiqueta <html>. Se incluyen, además, referencias al espacio de nombres (xmlns) e idioma (xml:lang) utilizado. El primero de ellos debe tener fijo el valor http://www.w3.org/1999/xhtml, cualquier intento de modificarlo causará un error de validación; el segundo, podrá, obviamente, variarse en función del idioma del contenido.
  • Las siguientes son ya bastante habituales, definiendo el contenido del documento.

El próximo día iré incorporando las etiquetas disponibles y comentando su utilidad. Hasta entonces.

sábado, 24 de junio de 2006
Después de algunas semanas fuera de juego por motivos (labora-persona)les, vuelvo a la carga. Ahora, con un poco más de tiempo libre, voy a aprovechar para tocar algo de XHTML.

Hasta el momento, para el desarrollo de sistemas web orientados a entornos locales (Intranets) con agentes de usuario controlados, me ha bastado con el conocimiento de HTML y Javascript. Sin embargo, desde hace ya algún tiempo, vengo siguiendo con mucho interés la fuerte (y lógica) acogida de los estándares W3C en este campo, debida a la necesidad evidente de evitar tecnologías (sean lenguajes o de cualquier otro tipo) propietarias, demasiado sujetas al dictado de sus titulares, y que han sido propiciados sin duda por la gran acogida y expansión de navegadores alternativos a IE provenientes del mundo del software libre, así como de dispositivos desde los que se puede acceder a la red, y la gran conciencia existente respecto a la accesibilidad de sitios webs, promovida también por la W3C a través de WAI (Web Accesibility Initiative).

Y ha llegado el momento. Está claro que después de tantos años trabajando deaquellamanera, estandarizarme un poco va a costar algo de trabajo, pero, ¿quién dijo miedo? Como de costumbre, utilizaré este espacio para recoger lo que vaya aprendiendo sobre el tema, y las conclusiones a las que vaya llegando. Mi objetivo será, en un breve periodo de tiempo, disponer de soltura suficiente como para poder desarrollar sistemas web completamente acogidos al estándar, utilizando XHTML para recoger el contenido de las páginas y CSS para la definir presentación.
viernes, 9 de junio de 2006
Esta mañana he recibido un correo electrónico invitándome a probar Google SpreadSheets, el último invento de los laboratorios de esta compañía. Como Googligan convencido, en cuanto he tenido ocasión, he saltado a comprobar cuánto de cierto hay en lo que se ha estado comentando en Internet durante los últimos días.

En la actualidad Google SpreadSheets se publica en forma de test limitado, es decir, se trata de una versión beta (bastante avanzada, todo sea dicho) a la que no se puede acceder sin disponer de una invitación, la cual es posible solicitar desde la misma Web. A mí me ha tardado tres o cuatro días desde el momento en que rellené el formulario de solicitud.

Vale, pero comencemos por el principio: ¿qué es Google Spreadsheets? Podríamos definirlo como una hoja de cálculo completamente on-line, una especie de Excel preparada para funcionar en un navegador, sin necesidad de descargar ni instalar software alguno, y, en principio, de uso gratuito. Pinta bien, ¿eh?

Desde el punto de vista de un usuario habitual de la hoja de cálculo de Microsoft, el primer contacto con la herramienta es impresionante. Estéticamente, muy limpio (se nota que usa Ajax, permítaseme el chiste fácil ;-). El manejo, sencillísimo, y más aún si se ha utilizado Excel, puesto que los mecanismos de interacción son muy similares a los de esta popular aplicación. La velocidad, bastante buena; en las pruebas que he realizado, con hojas de cerca de 2.500 celdas con fórmulas enrevesadillas encadenadas unas a otras, en ningún momento he notado retrasos que pudieran impedir el trabajo con ellas de forma fluida.

En cuanto a las funcionalidades, salvando la ausencia de gráficas, no he echado en falta nada de lo que utiliza habitualmente un usuario de nivel bajo y medio de Excel, entre los que nos encontramos la mayoría: fórmulas, formatos, ordenaciones, e incluso operaciones con archivos. Bien es cierto que no alcanza la gran cantidad de opciones que tiene Excel, pero desde luego, las principales sí que las incorpora.

El almacenamiento se soluciona completamente en el servidor. El usuario no tiene por qué guardar nada en su disco duro, todo quedará almacenado en su carpeta de las máquinas de Google. Respecto a esto, habrá que ver si los usuarios nos podemos acostumbrar a que nuestros archivos se encuentren guardados en Internet, lo que, para un mortal, equivale a decir "no tengo ni idea de dónde están mis ficheros". Por ello, es importante destacar que importa y exporta archivos XLS directamente y, por lo que he podido comprobar, no lo hace nada mal, incluso con fórmulas y formatos relativamente complejos.

Otro detalle que muestra el nivel del producto es su implementación de la idea de trabajo colaborativo, aspecto éste donde destaca sobre sus competidores tradicionales, al menos hasta el próximo movimiento de ficha de Microsoft. Lejos de montar una infraestructura de checkin/checkout o control de versiones, han optado por la comunicación asíncrona. En otras palabras, es perfectamente posible que varias personas se encuentren a un mismo tiempo tocando la misma hoja de cálculo, a la vez que pueden estar comentando la jugada en un pequeño chat integrado en el mismo entorno. De hecho, si una de ellas modifica el contenido de una celda, el resto de participantes verán, en pocos segundos, este cambio reflejado en la hoja sobre la que están trabajando.

Esto, que puede parecer relativamente sencillo en aplicaciones de escritorio, se complica bastante en un entorno desconectado como es la web. Es curioso, mientras se está usando mantiene una conexión activa con un servidor de Google, entiendo que será el canal de recepción de datos y notificaciones:

C:\>netstat find "google"
TCP JMA:2678 05178618550233449.spreadsheets.google.com:http ESTABLISHED


Para los ases del botón derecho del ratón, y más concretamente de la opción "Ver código fuente", sin duda es una decepción. Una página web simple, de unos 3K, que no hace más que referenciar una librería javascript almacenada en un archivo externo de unos 170k, que es en realidad la que hace la magia. Las fuentes están ahí, aunque a la vista de su contenido, deduzco que han sido 'ofuscadas' para dificultar su comprensión, y que gran parte de los procesos se llevan a cabo en servidor, que devuelve el HTML de la porción a actualizar en cada momento.

En fin, en mi opinión, una auténtica maravilla, y una nueva prueba de que Google apuesta por una nueva forma de trabajar, totalmente on-line y basada en Web, como ya lleva demostrando desde hace bastante tiempo.

Y por cierto, dado que uno de los fuertes de Google es el análisis de contenidos para la presentación de publicidad altamente dirigida, ¿aplicarán esta idea a SpreadSheets? Por ejemplo, ¿nos aconsejará entidades bancarias si estamos introduciendo en la hoja de cálculo un plan de tesorería en el que aparecen números rojos? Si estamos consultando un presupuesto de hardware recibido en formato de hoja de cálculo, ¿será capaz de recomendarnos productos similares, o incluso más económicos, que los que estén reflejados en él? La verdad es que las posibilidades son infinitas, tantas como utilidades damos a las hojas de cálculo.
viernes, 2 de junio de 2006
Desde hace años tengo asumido que un gran porcentaje de mis visitas a casas ajenas terminan en una revisión del equipo informático local. Pero no, no soy de esos que rehúyen este tipo de compromisos sociales; todo lo contrario, aunque a veces resultan algo insulsos ("ven a ver mi ordenador nuevo", "instálame la impresora", "no tengo espacio en el disco duro", "al escribir no me sale la eñe"...), otras me lo paso estupendamente, encontrándome con todo tipo de escenarios y retos. Son especialmente interesantes las relacionadas con virus, troyanos y especímenes varios de la fauna digital.

Hace poco, en casa de un familiar, convocado al grito de "ven a ver el ordenador que le pasa algo raro", me encontré con un panorama genial. Se trataba de un troyano (una pena, no recuerdo el nombre) descargado de algún sitio web de oscuras intenciones que se le había colado hasta el mismísimo tuétano.

Los síntomas visibles, básicamente, eran el secuestro absoluto del navegador (Internet Explorer): las página de inicio y búsqueda apuntando hacia un extraño sitio web, lanzamiento de ventanas popup publicitarias cada pocos minutos, y una serie de cuadros emergentes bastante llamativos alertando sobre problemas de seguridad en el sistema. Qué irónico.

"Estos malditos troyanos han secuestrado a Helena.
¡Vayamos a la guerra!"

Visto el panorama, puse a funcionar la artillería que muy prudentemente tenía instalada la máquina: Ad-Aware, Microsoft Antispyware (beta por entonces), Norton Antivirus, y Spybot.
Nada, como si le hubiera leído algo de Homero, ni puñetera cuenta. "¡Enhorabuena, tienes un último modelo", le dije a mi pariente.

"Los griegos reunieron cien mil hombres,
que en mil barcos marcharon hacia Troya"

Era el momento de ponerse el casco, agarrar el escudo y lanzarse al campo de batalla cual griego micénico furibundo, contra todo troyano viviente. Aunque no hay que precipitarse: lo primero, observar al enemigo.

"La ciudad de Troya estuvo sitiada cerca de diez años"

Lo que me llamó la atención en primer lugar era que estaba bastante bien hecho, lo que que me hizo reflexionar sobre el desperdicio de habilidades de determinados individuos. Deberían dedicar su tiempo y conocimientos a creaciones más útiles y menos nocivas.

El bichillo, como es habitual, se escondía en el registro de aplicaciones de arranque, es decir, se cargaba con el sistema operativo y consistía en tres ejecutables, con nombres similares a los procesos propios de Windows (como svchost.exe, winlogon.exe, spoolsv.exe...) a los que cambiaba la denominación levemente (scvhost.exe, winlogon.dll, spoolsvc.exe...) para que pasaran desapercibidos.

Estos tres ejecutables se encontraban en el disco duro, en el directorio Windows\System32, lo cual dificultaba aún más su localización, pero lo peor de todo es que no se podían eliminar: al estar cargados en memoria, los archivos siempre se encontraban en uso. Además, funcionaban de la siguiente forma:
  • se protegían entre sí: si alguno de ellos dejaba de funcionar (por ejemplo, matando el proceso), uno de los otros dos volvía a lanzarlo. Supongo que cada proceso vigilaba a los otros dos, formando así una cadena difícil de romper.
  • protegían las entradas el registro del sistema mediante las cuales se lanzaban al iniciar Windows. Era curioso: tal y como las cambiaba en el registro, ellos volvían a dejarlas como estaban en pocos segundos.
  • protegían la página de inicio del navegador, así como la de búsqueda. Al modificarlas ocurría como en el caso anterior, raudos acudían a restituir los valores oportunos.
  • protegían la desinstalación de complementos del navegador. La criatura también se instalaba aquí, tomando el control en el momento de abrir el Internet Explorer.

"Troya tenía unos muros inexpugnables"

Durante la primera fase, realicé varios intentos de anulación básicos, que más que nada fueron útiles para poder conocer mejor a mi contendiente. De hecho, todas las características que he comentado en la lista anterior las fui descubriendo conforme intentaba anular sus funcionalidades. Digamos que durante esta fase, siempre ganó él.

"Durante el tiempo del asedio, los bandos rivales
se hostigaban continua y salvajemente"

Estaba claro que había que recurrir a herramientas más sofisticadas. Dado que que era imposible utilizar software de eliminación de engendros de este tipo puesto que era demasiado reciente y aún no existían soluciones (vacunas) específicas, opté por descargar dos magníficas herramientas de Sysinternals: Process Explorer y Autoruns. La primera de ellas permite visualizar los procesos activos en la máquina con un nivel de detalle muy superior al provisto por el Administrador de Tareas de Windows. La segunda, permite acceder de forma muy sencilla a las zonas del registro del sistema donde se definen las aplicaciones que cargan de forma automática al iniciar el sistema operativo.

Después llegué a la obvia conclusión de que la clave estaba en anular los tres procesos centrales. Si conseguía pararlos, podría quitarlos tranquilamente del registro e incluso eliminar los archivos del disco duro. Pero claro, debía parar los procesos, tarea difícil por la protección a tres bandas que tenían implementada.

Dado que el programador del invento detectaba cuándo determinado módulo dejaba de estar en memoria para volver a lanzarlo, pensé que sería una buena idea probar a suspenderlos, es decir, paralizar su ejecución. Efectivamente, era el camino hacia la solución: al suspender el proceso, éste seguía estando en memoria, y por tanto los otros dos no detectaban nada anormal. Así, una vez estaban los dos primeros congelados, el tercer módulo pudo ser matado sin oponer resistencia alguna. Y después, a matar los otros dos. Ya tenía la memoria limpia.

"Ulises tuvo una gran idea. Construir un caballo de madera,
en cuyo interior se escondían varias decenas de soldados griegos"

A partir de ahí, todo fue mucho más sencillo. Con ayuda del software Autoruns limpié el registro de entradas en las secciones oportunas, haciendo que no se intentara ejecutar nada al arrancar, eliminé el complemento cargado en Internet Explorer y, por último, hice desaparecer para siempre los archivos del disco duro.

"Una vez llegó la noche, los soldados salieron del caballo y
abrieron las puertas a sus tropas, que invadieron y saquearon la ciudad"