Infosofía := 0×69AEE7

Una de las confusiones que se suele presentarse a la hora de diseñar CSS es saber la diferencia entre los distintos selectores. CSS cuenta con los siguientes

• Selectores de tipo
• Selectores descendentes
• Selectores de clase
• Selectores de ID

Veamos exactamente que es un selector:
[css]p { font-size: 12px; }[/css]

Esto se denomina una regla CSS. p es un selector y lo que se encuentra dentro de los paréntesis es una declaración (puede haber más de una declaración). Una declaración está formada por dos elementos: propiedad y valor; la propiedad en éste caso sería font-size y el valor sería 12px.

El selector de tipo, índica que se apliquen las declaraciones a todas las etiquetas del documento. Este selector es el menos restrictivo
Por ejemplo:
[css]h4 { color: blue; }[/css]

Aplicado al siguiente código html
[html]

soy un h4

soy otro h4

¡Somos todos del mismo color!

[/html]
Salida

Como se puede ver en la salida sólo se aplico el estilo a todas las etiquetas que coincidieron con el selector.
En el siguiente ejemplo aplicaremos el mismo estilo a dos etiquetas, CSS nos ayuda a simplificar la notación, para no definir dos veces las mismas declaraciones.
[css]strong, em{color:green;}[/css]

Notar que los selectores están separados por coma

que lo aplicaremos a
[html]

Soy un strong verde

soy em verde y también un strong verde

[/html]
Salida:

Con esto logramos que todas las etiquetas strong y em en la página tengan el mismo estilo.

Los selectores descendentes sólo aplica las declaraciones cuando coincide el selector y el anidamiento de etiquetas especificado. Veamos un ejemplo para aclarar las cosas
[css]p strong {color:red;}[/css]

Notar que los selectores están separados por espacios

Y tengamos el siguiente código HTML
[html]

Tengo una parte strongpero ¡no es rojo!

Sólo dentro de mi es rojo

[/html]
Salida

No se aplico el estilo en h5, porque el selector descendente especifica que el estilo se aplique dentro de p, o sea se aplica el estilo al selector más a la izquierda y que se encuentre contenido en el selector de la derecha. Sólo dentro p cumple con el anidamiento especificado en el selector de descendencia.

A través de los selectores de clase podemos referenciar etiquetas especificas de la página que no lo podríamos lograr con los anteriores selectores. Una situación sería la siguiente:

Marcar con amarillos 3 etiquetas strong. Donde por lo menos una deben encontrarse dentro de cualquier etiqueta.

En está situación no podemos usar los selectores de tipo, ya que nos indica que sólo marquemos 3 strong, ni los selectores de descendencia porque los encabezados se pueden encontrar dentro de cualquier etiqueta.
Para solucionar dicha situación deberemos definir un selector de clase, estos se aplican a todas las etiquetas con el valor del atributo class igual al selector. Un mismo elemento puede tener una o más class.
[css].amarillo{color:yellow;}[/css]

Notar el signo punto al inicio del selector

Que aplicaremos al siguiente código
[html]

Tengo un strong pero no es amarillo

Tengo un strong y es amarillo

puedo ser amarillo en cualquier parte

Falta un ultimo strong

[/html]
La salida sería

Con el selector de clase podemos aplicar el estilo a una o más etiquetas determinadas.

Y por último tenemos el selector de ID, cumple la misma función que el selector de clase. Pero para aplicar dicho estilo se utiliza el atributo id de las etiquetas. Veamos como se define
[css]#unico{color:#6947a7}[/css]

Notar el signo almohadilla al inicio del selector

Y lo aplicamos en el siguiente código
[html]

soy el único strong de la página con este color

No puedo ser de ese color

Tampoco lo puedo ser

[/html]
Salida

Como se puede ver, estos dos selectores se comportan de manera muy parecida ¿Cuál es entonces la diferencia entre un selector de clase y uno de id? La diferencia es sútil y radica en que un selector de clase puede aparecer una o más veces en una misma página, en cambio un selector de ID sólo puede aparecer una sóla vez en la página, debido a que se utiliza el atributo id de la etiqueta, y en una misma página no pueden haber dos etiquetas con el mismo valor de id. Por lo tanto el selector de ID se utiliza para que aparezca una vez en la página, por ejemplo definir el estilo de la etiqueta body; por el contrario el selector de clase aparece varias veces en la misma página, como vimos en el ejemplo de los tres encabezados.

Esto cuatros selectores pueden combinarse entre sí y dar una amplia variedad de forma de especificar elementos en los documentos. Les dejo un último ejemplo para mostrarles lo muy complejo que se puede volver una notación de selectores
[css]
p#directo strong.especial em a#video { … }
[/css]
Las declaraciones se aplicarán sólo a un link que tenga el valor id igual a video y que se encuentre dentro de un elemento em, que a su vez se encuentre dentro de un elemento strong con el atributo class igual a especial, el cual se encuentra dentro de un elemento p con el atributo id igual a directo.

Como no dedicarle un post a uno de los mejores juegos de la historia (¿O acaso me equivo?), algo que marco definitivamente el rumbo de mi vida (y las de varios) jaja. Para todos aquellos nostálgicos les dejo una de esas canciones que te hacen vibrar el alma al escucharla. ¡Disfruten!



Para aquellos de que no esten al tanto de esta fantástica aventura le recomiendo visitar el siguiente sitio. En el pueden encontrar una buena introducción a este fantástico juego

Leyendo descubrí esta fantástica herramienta llamada ApacheBench que viene junto a Apache. Con ella podemos determinar la performance de nuestro servidor. Como dice el man de apachebench: “Especialmente te muestra como muchas solicitudes por segundo es capaz de servir tu instalación de Apache”. Mediante la salida de está herramienta podremos saber cómo configurar correctamente el módulo MPM que tengamos compilado. El modulo MPM que tengamos compilado por default depende del sistema operativo

Para saber que MPM tiene nuestro servidor, ejecute

 #apache2ctl -l
...
mod_logio.c
prefork.c
http_core.c
…

A ver veamos un poco de teoría para saber como funcionan MPM. Un servidor web pre-forking, no maneja hilos para atender a las solicitudes. En cambio las solicitudes son tratas de una manera similar a como lo hacía Apache 1.3, creando un nuevo proceso hijo por cada una. La ventajas de esto es que si surge un problema con una solicitud, esta no afecta al resto, ya que cada proceso hijo es independiente del resto y maneja una única solicitud, por lo tanto ganamos en estabilidad. Una desventaja es que perdemos escalabilidad. La creación de procesos es muy lenta, comparada con la de hilos, por lo tanto para tratar varias solicitudes simultaneas este modelo no es muy adecuado. También es importante notar que todos los hilos de un mismo hilo comparten sus recursos, logrando que los hilos sean más “livianos” que los procesos. Por ejemplo un servidor web threaded, maneja varias solicitudes en un solo proceso hijo, por cada solicitud el proceso hijo le asigna un hilo, de esta manera dentro de un hijo hay varios hilos, si uno tiene un problema afecta al al hijo y a todos sus hilos.

En el archivo de configuracion de apache (/etc/apache2/apache2.conf) tenemos la siguiente configuración de MPM

    StartServers          5
    MinSpareServers       5
    MaxSpareServers      10
    MaxClients          150
    MaxRequestsPerChild   0

Ahora haremos una prueba con apachebench, haremos 100 solicitudes concurrentes y en total 200 solicitudes y veremos como responde el servidor

ab -n 200 -c 100 http://localhost

la salida es

Completed 100 requests
Finished 200 requests

Server Software:        Apache/2.2.4
Server Hostname:        localhost
Server Port:            80

Document Path:          /
Document Length:        153 bytes

Concurrency Level:      100
Time taken for tests:   0.117805 seconds
Complete requests:      200
Failed requests:        0
Write errors:           0
Total transferred:      82205 bytes
HTML transferred:       31365 bytes
Requests per second:    1697.72 [#/sec] (mean)
Time per request:       58.902 [ms] (mean)
Time per request:       0.589 [ms] (mean, across all concurrent requests)
Transfer rate:          679.09 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    9   8.2      6      18
Processing:     6   37  18.5     41      61
Waiting:        3   35  18.1     39      59
Total:         22   47  11.8     53      70

Percentage of the requests served within a certain time (ms)
  50%     53
  66%     54
  75%     55
  80%     57
  90%     60
  95%     61
  98%     61
  99%     62
 100%     70 (longest request)

Un parámetro a tener en cuenta es Request per second, que en este caso dio 1697.72. Variando los valores de las directivas MPM, por ejemplo MaxClients, y ejecutando nuevamente apachebench, el valor de Request per second crecerá o bajará en función del cambio.

Bueno después de realizar una llamada al “Servicio Técnico de speedy” (0800-333-7733 opción 0). He podido solucionar lo que comenté en un post anterior. Al preguntar a qué se debía esto, obtuve la siguiente respuesta: “para solucionarlo debemos ‘regenerar el servicio’ (¿?), así que tiene que mantener apagado su modem hasta que le avisemos”. La cuestión, es que no me explicaron el por qué no podía entrar a otros sitios por el puerto 80. Una vez que hicieron la “regeneración” (aproximadamente 40 segundos), volví a prender el modem y probé conectarme con otro servidor con speedy (hogareña) y pude. La pregunta que cabe ahora es: ¿Por qué desde un principio no brindaron el servicio con “regeneración” y tuvieron que esperar hasta que me quejara? Sólo espero que está regeneración dure mientras tenga el servicio y no termine cuando refresque la dirección IP… Cualquier cosa voy postear si sucede

Una persona mal intencionada que quiera tirar abajo nuestro sitio web, debe contar con información, esta puede ser obtenida de varias formas, pero mientras mayor sea el esfuerzo que deba realizar en conseguirla menor será su ganas de atacar.

Algunas versiones de Apache 2 por defecto trae activada una directiva que informan sobre el servidor. Por ejemplo, al contar con información del número de versión de Apache, tiene a su disposición todas las vulnerabilidades reportadas. En base a esto y ganas de hacer daño es cuestión de tiempo para bajar el sitio. Por lo cual no se recomienda que esté activada está directiva, sólo en el caso de que Apache se utilice como un servidor proxy y de esta manera poder determinar qué proxy causa un error.

Vamos a ver como desactivar esta información que suministra Apache. La explicación se basa en Debian y Apache 2. La directiva ServerSignature, agrega un pie en las páginas generadas detallando número de versión, nombre y puerto por el que escucha el servidor. Es importante notar que los detalles del número de versión mostrado en éste pie es controlado a través de la directiva ServerTokens, a partir de la versión 2.0.44 de Apache.

ServerSignature puede tomar los siguientes valores: On, Off, EMail. EMail, además de mostrar información detallada por ServerTokens, muestra el valor de la directiva ServerAdmin.

ServerTokens puede tomar los siguientes valores

Nos vamos a

#cd /etc/apache2
#vi apache2.conf

Nota:Puede ser que la gestión de la configuración del servidor se encuentre en varios archivos y no sólo en apache2.conf. La ruta en dónde pueden encontrarse estos archivos se obtiene a través de las directivas Include dentro de apache2.conf. Por defecto podemos encontrar el resto de los archivos en /etc/apache2/sites-available. En éstos archivos también tenemos que modificar los valores de ServerSignature.

Buscamos la directiva ServerSignature y la establecemos en Off.

# Optionally add a line containing the server version and virtual host
# name to server-generated pages (internal error documents, FTP directory
# listings, mod_status and mod_info output etc., but not CGI generated
# documents or custom error documents).
# Set to "EMail" to also include a mailto: link to the ServerAdmin.
# Set to one of:  On | Off | EMail
#
ServerSignature Off

Reiniciamos Apache para que tome la nueva configuración

#/etc/init.d/apache2 force-reload

Con esto desaparecerá el pie de página

Podemos comprobar que información está suministrando el servidor, a través del encabezado devuelto en las solicitudes HTTP^[1]

# telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET / HTTP/1.1
HTTP/1.1 200 OK
Date: Wed, 26 Dec 2007 21:57:51 GMT
Server: Apache/1.3 (Debian) PHP/5.2.1
Last-Modified: Tue, 27 Nov 2007 02:16:58 GMT
ETag: “1390096-7b7-ace83a80″
Accept-Ranges: bytes
Content-Length: 1975
Connection: close
Content-Type: text/html; charset=UTF-8
…

Dentro del encabezado HTTP, se esta mostrando información detallada, tenemos que minimizarla, esto lo hacemos modificando el valor de la directiva ServerTokens

# ServerTokens
# This directive configures what you return as the Server HTTP response
# Header. The default is 'Full' which sends information about the OS-Type
# and compiled in modules.
# Set to one of:  Full | OS | Minor | Minimal | Major | Prod
# where Full conveys the most information, and Prod the least.
#
ServerTokens Prod

Ahora si hacemos un telnet aparecera^[1]

# telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET / HTTP/1.1
HTTP/1.1 200 OK
Date: Wed, 26 Dec 2007 21:57:51 GMT
Server: Apache
Last-Modified: Tue, 27 Nov 2007 02:16:58 GMT
ETag: “1390096-7b7-ace83a80″
Accept-Ranges: bytes
Content-Length: 1975
Connection: close
Content-Type: text/html; charset=UTF-8
…

[1] También podríamos utilizar NetCat, para obtener sólo el encabezado de la solicitud HTTP. Donde a NetCat le pasamos la dirección IP del servidor (localhost) y el puerto por el que está escuchando (80). Después de presionar enter utilizamos el método de solicitud HEAD.

# nc localhost 80
HEAD / HTTP:1.0

HTTP/1.1 200 OK
Date: Thu, 17 Jan 2008 21:00:51 GMT
Server: Apache
Last-Modified: Tue, 27 Nov 2007 02:16:58 GMT
ETag: "1390096-7b7-ace83a80"
Accept-Ranges: bytes
Content-Length: 1975
Connection: close
Content-Type: text/html; charset=UTF-8

Realmente estoy cansado del pésimo servicio que brinda Telefónica. Sumando un plus a todas las calamidades del servicio, telefónica se toma la cortesía de filtrar o dropear conexiones al puerto 80 entre usuarios de speedy. Por ejemplo si un usuario de speedy levanta un servidor web y alguien quiere entrar a su sitio (siendo él usuario de Speedy), no puede, pués las solicitudes al servidor web nunca llegan, por lo que el navegador queda esperando una respuesta que nunca arribará… He realizado prueba a ver si telefónica había puesto un proxy transparente, ya que hubo un gran escandalo en España debido a la “alta calidad” que brindaba el proxy; pero en la prueba no aparece ningún proxy. Pueden probarlo entrando en este sitio (¡¡tener cuidado si hay un proxy propio en su red!!). Por lo tanto supongo que deben estar dropeando las solicitudes. Es por esa razón que para poder entrar a infosofía se debe especificar el puerto 8089. Ya que si dejaba al servidor web escuchando por el puerto 80 no podría darle cobertura a usuarios de Speedy.

Creería que la mejor manera de erradicar esta absurda medida es llamar a speedy y quejarse de está injusticia (0800-333-7733). Algo que todavía no puedo comprender es ¿Cuál es el motivo de que no se puedan recibir solicitudes de usuarios de Speedy por el puerto 80?, acaso ¿Porque colapsará la subred de telefónica? ¿Se habrán olvidado de limpiar alguna vieja regla de iptables XD?… Sólo queda esperar a ver si se soluciona esto.

Realmente es deplorable la administración de la UTN-FRM, especialmente en la carrera de sistemas de información. Hay cosas que no se pueden comprender que sucedan en una facultad. A veces me pregunto: ¿Será todo tan complicado? o más bien ¿Son tan incompetentes para realizar de forma correcta su propio trabajo? Algo que ya viene de larga data es el momento para la inscripción a las mesas de examenes, especialmente durante la época que se está cursando o terminando de cursar. Dejando de lado todos los percances que puede traer acarreados la inscripción a través de la “autogestión” disponible en su sitio web, que he comentado en un post anterior. Vale aclarar es que el sitio web es un fiel reflejo de lo que está sucediendo en la facultad.

Volviendo con el tema de la inscripción a las mesas de exámenes, algo que es muy molesto, es que uno tiene que cumplir durante todo el cursado con lo que le exigen, tanto los profesores como también la facultad. Pero al finalizar el cursado cuando uno exige su derecho a rendir en una mesa de examen, los profesores/facultad no cumplen con sus DEBERES, por citar uno, cargar/pasar las notas… Entonces cuando uno intenta inscribirse a rendir una mesa (a través del sitio es el único medio) nos aparecen “agradables” ventanitas donde “autogestión” trata de explicar el posible “problemas” por el cual no podemos inscribirnos. Digo “agradable” (por favor notar las comillas sobre la palabra XD) porque en la facultad no nos explican las cosas “agradablemente”. Cuando uno quiere encontrar el problema de porque no se puede inscribir en la mesa, todas las respuestas convergen en: “No se han cargado las notas al sistema”. Luego de eso según a la persona a la que se esté cuestionando, las respuestas bifurcan. Hagamos un par de ejemplos:

• Si se le pregunta del problema al bedel de sistemas, responde: “El profesor todavía no pasa las notas”
• En cambio si se le pregunta al profesor en cuestión: “Hemos pasado las notas, pero todavía en bedelía no las han cargado”

Dentro de esté ámbito divergente, donde la propia administración de la facultad está involucrada, se encuentran los alumnos, los cuales terminan siendo los únicos perjudicados de este cruel sistema de incompetencia. Un ámbito dónde lo menos que se trata de hacer es de solucionar el problema.

Una persona desde afuera diría que todo se podría solucionar si se aplicará la jerarquía, donde el/los que tiene mayor jerarquía (léase jefe de departamento) coordine o solucione estas divergencias. Es ahí cuando nos encontramos, por nombrar a alguien, con el Ingeniero Vázquez Alejandro. Según RAE, ingeniero es una persona que logra conseguir o lograr cosas con ingenio, pero en el citado caso, o RAE tiene una definición muy alejada de la realidad o el jefe de departamento no realiza correctamente su oficio o no es merecedor del cargo que ocupa.

Espero que algún día esta bochornosa forma de actuar para con los alumnos encuentre su fin. Ya que esto viene siendo desde años y por más que hayan diferentes decanos o jefes de departamento, ninguno puede encontrar la solución a ésto (y muchos más problemas).

Una moraleja de todo esto, es que el antiguo decano de FRM, fue el Ingeniero Julio César Cleto Cobos, nuestro “flamante” vicepresidente de la República Argentina. Alguien quien llegó a ser gobernador de Mendoza y actual vicepresidente, se debio destacar por su (gran) capacidad de “solucionar” problemas. Pero ni el mismo Cobos solucionó los problemas administrativos de una “carrera” de facultad, lo que le espera a los problemas administrativos de un PAÍS… Bueno ese es otro tema :D.

La siguiente explicación tiene en cuenta cualquier distribución basada en Debian y apache 2.

Apache 2 a diferencia de Apache 1, no trae un modulo propio para limitar el ancho de banda. Este es un modulo con dicha funcionalidad que probe.

Notar que este paquete hace conflicto con apache 1.3…Una vez bajado el modulo del sitio lo descomprimimos

tar xzvf mod_bw-0.8.tgz

Luego dentro del directorio del modulo descomprimido, ejecutamos apxs. Apxs es una herramienta para compilar dinámicamente, instala modulos a partir del código fuente creando un DSO y cargandolo dinámicamente en nuestro servidor. Para instalarlo debemos ejecutar

apt-get install apache2-prefork-dev

Hay que notar que existen varias versiones de apxs2, la versión correspondiente para nuestro servidor es según con que módulo de MPM fue compilado, suena complicado pero no alarmase. Para saber con que MPM está compilado su servidor ejecute el siguiente comando

apache2ctl -l

La salida de dicho comando mostrará los modulos que tiene compilado. Mi servidor tiene compilado prefork.

...
mod_logio.c
prefork.c
http_core.c
…

Dentro del directorio descomprimido mod_bw esta el archivo fuente del modulo (*.c), entonces para compilarlo hacemos:

apxs2 -i -a -c mod_bw.c

La opción -i instalar el módulo, -c compilarlo y -a activarlo. Dentro de la salida de dicho mensaje podemos encontrar el siguiente mensaje. Hasta ahora vamos bien

Libraries have been installed in:/usr/lib/apache2/modules

Vamos y verificamos en /usr/lib/apache2/modules si se compilo, debería aparecer como mod_bw.so.

Luego vamos a /etc/apache2/httpd.conf, y ordenamos a Apache que cargue el modulo, utilizamos la directiva LoadModule

LoadModule bw_module /usr/lib/apache2/modules/mod_bw.so

Nota: LoadModule relaciona el nombre de un módulo con una librería que tengamos instalada. En el comando anterior relacionamos el nombre bw_module con la librería mod_bw.so, la cual se encuentra en /usr/lib/apache2/modules.

luego reiniciamos apache para que tome la configuración

/etc/init.d/apache2 force-reload

vamos a /etc/apache2/sites-available

y editamos default o el archivo que tengan sobre su sitio habilitado

Activamos el modulo y forzamos que las solicitudes sean procesadas por él.

BandWidthModule On
ForceBandWidthModule On

Después agregamos las directivas para limitar el ancho de banda, un ejemplo sería:

<Directory "/uploads">
BandWidth all 8096
MaxConnection all 7
</Directory>

Expliquemos un poco cada directiva

BandWidth toma dos parámetros. El primero es de dónde se origina la conexión, la dirección ip, por ejemplo:

192.153.2.0/24
192.153.2.0/255.255.255.0
all

El segundo parámetro indica la velocidad disponible para el origen. Si el parámetro toma el valor 0, el origen no tiene limite de velocidad. La velocidad está expresada en bytes/s.

8 bits = 1 Byte
1024 Bytes = 1 KB
1024 KB = 1 MB
…

El modulo permite varios tipos de directivas interesantes para restringir en función de diferentes parámetros, ahora voy a describir las más interesantes. Todas están directivas, junto con su explicación y ejemplos se pueden obtener del archivo txt que está con el modulo.

Algo que han agregado en la versión 0.8, es la capacidad de limitar de acuerdo al agente del origen de la conexión, un ejemplo sería:

BandWidth "u:^Opera/9(.*)" 10240
BandWidth "u:^Lynx/2.8(.*)" 10240

Toma dos parámetros, el primero hace referencia al agente, y el segundo limita

Algo interesante que tiene este modulo es la capacidad de limitar en función de la extensión del archivo, por ejemplo:

LargeFileLimit .avi 500 10240

El primer parámetro hace referencia a la extensión afectada, también es posible poner .*, afectando a todos. El segundo parámetro es el tamaño mínimo de (los) archivo(s) para que limite. Y el último hace referencia a la velocidad permitida. Estos dos últimos valores se expresan en bytes/s.

Se puede limitar el número de conexiones simultaneas, aquí va un ejemplo de la directiva:

MaxConnection all 30

Toma dos parámetros, el origen de la conexión que puede tomas los mismos valores que en el parámetro de la directiva BandWidth. Y el segundo define el máximo número de conexiones de ese origen. Algo que han agregado en la versión 0.8, que se pude limitar el número de conexiones limitadas según el agente, por ejemplo:

MaxConnection "u:wget" 5

Por último, algo que encontré muy interesante es la capacidad de limitar ciertos directorios, aquí les pongo un ejemplo

<VirtualHost *>BandWidthModule On
BandWidth all 16384
LargeFileLimit .png 5 4096
<Directory “/download”>
LargeFileLimit .png 5 1024
</Directory>

Creería que eso es todo. Como dije al principio del artículo, todas las explicaciones y ejemplos se encuentran en la documentación del modulo

Acá les dejo una explicación de las dos formas en que se puede generar contenido dinámico en documentos web. Ya que he notado que varias personas no comprenden bien la diferencias de las dos formas. Ninguna forma es “superior” a la otra, sino que se complementan. Hay varias ocasiones donde es necesario usar ambas formas para poder solucionar un determinado problema.

Contenido dinámico del lado del servidor:

Por ejemplo imaginen el siguiente escenario, se está llenando un formulario para ser un usuario de un determinado sitio web. Al enviar el formulario, se envía un mensaje al servidor, pero no para solicitar un archivo de regreso. Sino, se debe pasar los valores del formulario a alguna aplicación del servidor para que lo procese. Por ejemplo se podría disparar una consulta a una base de datos, para verificar que el nombre de usuario indicado en el formulario no está asignado. Entonces aquí tenemos una generación de contenido dinámica, porque según los datos del formulario se generará distintos contenidos, por ejemplo si el nombre de usuario ya está registrado se podría mostrar una página indicando que dicho nombre ya está usado, o en cambio si los datos fueron correctos generar una página felicitando al nuevo usuario. Hay varios lenguajes para escribir estos programas: Perl, PHP, JSP, ASP.

Contenido dinámico del lado del cliente:

Hoy en día está muy de moda colocar “efectos” en las páginas. Uno que es muy usado es que cuando se presiona un botón (o se pasa por arriba de este) ocurre algo, por ejemplo, cambia de color o se abre una etiqueta que nos indica a que hace referencia ese botón, etc. Como se puede ver todo ese contenido dinámico es en respuesta a la interacción con el usuario y no es necesario para nada el servidor de donde se solicitó la página. Para generar esos efectos es necesario tener comandos incrustados dentro de la página y que actúen en función de lo que hace el usuario. Un lenguaje muy popular para esto es Javascript.

Como se puede ver la diferencia entre ambas es muy rígida, pero a través de la tecnología AJAX, es posible unir las otras dos y que interaccionen de una manera más flexible ofreciendo una mayor calidad al usuario, un mayor grado de interactividad.

Algo que hay que destacar es que AJAX en sí no es una tecnología ni un lenguaje de programación, es más bien la unión de varias tecnologías. AJAX es una técnica de desarrollo web.

Una explicación sómera de como se utiliza AJAX (sin entrar en detalles técnicos) podría ser el caso en que se busca una palabra en la barra de Google, al colocar la primera letra, el servidor despliega una lista de sugerencias de palabras que empiezan con esa letra. Al colocar una segunda letra se vuelve a mostrar otra lista de sugerencias.

Aquí se puede ver que para obtener la lista se necesita información del servidor y la lista está en función de la interacción que tiene el usuario con la página. De aquí que unimos las dos tecnologías y damos una apariencia de mayor fluidez al usuario, primero por que la página no se refresca completa, sino, la lista de sugerencias y segundo una comunicación más rápida con el servidor, porque no tiene que traer toda una página, sino una pequeña lista.

El otro día hablando con unos amigos estudiantes de la UTN-FRM [Nota: su mayor densidad de alumnos se encuentra en la carrera "Ingeniería de Sistemas de Información”]. Salio el tema sobre el pésimo servicio que ofrece la “autogestión” (un programa dentro del sitio web que gestiona la inscripción a materias o mesas de exámenes de los alumnos), y que si eres uno de eso “raros” que usa navegadores como Firefox XD, te las ves feas al entrar a la autogestión (o mejor dicho, ves fea la página ;)), no quiero ni pensar con Lynx… Realmente es muy pobre el programa y la página, entrar a inscribirse es toda una odisea, porque el diseño de la autogestión es espantoso… También deja mucho que hablar la página principal de la facultad. Toda persona con conocimientos mínimos en HTML sabe como es su estructura básica, ni hablar de un ingeniero, un ser superior el cual tiene conocimientos superiores a una persona normal. Además todo ingeniero siempre está muy apegado a los estándares, por lo tanto el fruto de su trabajo debe estar conforme a los estándares a los que se apega. Pero no es así con su sitio web. Sin entrar en detalles sobre los HORRORES que se pueden encontrar en el diseño de la página (ni hablar de la autogestión), respeten por lo menos la estructura básica de un documento HTML (salvo que quieran tener algo mal formado como ahora), o sea, <!DOCTYPE…><html><head></head><body></body></html>….