Si Ud. tiene que mantener un servidor web o si mantiene al menos una página web, tiene que pensar en su oferta a la red y tiene que dedicar algunos pensamientos en la aproximación al lector / usuario de sus páginas web.
Bien, no voy a decirle cómo se codifica HTML ni como tiene Ud. que diseñar sus páginas. Sólo le daré algunos puntos dónde Ud. puede encontrar información más avanzada.
Debería echar un vistazo a
http://www.w3.org/
para la especificación más reciente del lenguage HTML.
Eche un vistazo a la lista al final de este artículo, encontrará más consejos, dónde leerlos.
Muchos usuarios se conectan a Internet vía líneas de modem de baja velocidad. Un rango de velocidad de 14.400 bps a 28.800 bps es una obra de arte para "sitios privados". En Europa, están creciendo sistemas RDSI, pero una velocidad de 64.000 bps no es muy rápida en comparación con (hagámoslo simple - una ethernet de 10.000.000 bps). Y una ethernet de 10 Mbps no es realmente una conexión de LAN de alta velocidad hoy en día.
Así como Ud. se da cuenta que muchos usuarios no poseen este acceso rápido a la red, debería tener en cuenta el aumentar la relación entre información y bytes. Optimícelo a 1:1 (si puede). Debería usar gráficos en sus páginas web siguiendo la tendencia multimedia, pero recuerde siempre los objetivos de su página y de los gráficos que va a introducir. Si la mayoría de sus usuarios se conectan a través de una línea de modem pequeña y los gráficos sólo sirven para razones estéticas o para hacer efectos llamativos, haría mejor quitándolos de sus páginas, o (al menos) rehacerlas al tamaño de fichero más pequeño posible y usar la mejor compresión. A sus usuarios les gustará.
Recuerde siempre: ciertamente a nadie le gusta un efecto llamativo que dura unos 3-5 minutos después del mensaje de texto.
En un servidor de web, normalmente existe al menos una tarea de servidor ejecutándose. Si esta tarea lee una petición de un cliente http, se duplica a sí misma (en Linux esto se llama ramificación)
N. del T.: fork=ramificacióny la nueva copia sirve la petición mientras que la original mantiene la escucha para nuevas peticiones. Una vez acabada la petición, la copia desaparece. (De hecho, algunos servidores - como el apache - siempre conservan por defecto cinco copias del servidor en espera preparadas para peticiones en paralelo al servidor maestro, por razones de velocidad.)
Algunos visualizadores de web como las series del Netscape Navigator hacen muchas peticiones en paralelo sobre el mismo servidor, lo que incrementa la carga del servidor dedicada al mismo usuario. Estos visualizadores, por ejemplo, cargan la página HTML y la analiza sintácticamente durante la carga y distribuye nuevas peticiones para otra información como gráficos embebidos, ficheros de applets, ficheros de sonido o cualquier otro dato adicional codificado con mime. Por el contrario, los visualizadores 'simples' piden y cargan un fichero tras otro, lo que mantiene la relación de carga por usuario del servidor lo más baja posible.
Muchos usuarios prefieren visualizadores que usan la técnica de multipetición como el Netscape Navigator, porque traen una visión general más completa sobre la página requerida antes de que lo haga una petición simple del visualizador.
En mi opinión esto es porque muchos diseñadores de páginas introducen la información embebida dentro de los gráficos, rechazando los visualizadores de sólo texto.
Entonces, (como mantenedores de servidores) el problema es nuestro, ya que la mayoría de los usuarios lanzan multiples peticiones sobre servidores externos dentro de la carga de la misma página. Podemos limitar esto limitando el software del servidor a no servir más peticiones que "x" desde el mismo sistema al mismo tiempo. Pero, ¿cómo conseguir este "x"? No es fácil calcularlo, y es necesaria mucha experiencia personal en su servidor para representarlo. Pero, le daré algunos consejos. Tenemos que tener en cuenta el ancho de banda de nuestra conexión, el tamaño de memoria de nuestro servidor, alguna impresión sobre el rendimiento de la cpu/disco de nuestro servidor y... bueno, eso es suficiente para la primera ojeada. Debería echar un vistazo a la memoria que utiliza una sola tarea del servidor. Entonces piense cuantas de ellas se podría tener en memoria a la vez. Piense qué porcentaje de sus páginas web podrían permanecer en la caché de disco de su servidor. Optimice el total de tareas del servidor de web contra el tamaño del caché del disco y estará realmente cerca de su "x" personal. Además, puede presentar otros trabajos que posea el servidor. Por ejemplo, si su sistema también presta servicio por ftp, debería limitar el máximo número posible de conexiones para conservar un mínimo de espacio para la tarea del servidor de ftp. Si su servidor de web también presta algunos servicios de base de datos, haría mejor apartando algunos ciclos de cpu y también reducir su "x". Juegue algo con estos valores y pruébelos. Y (!) lea el siguiente capítulo sobre la escritura de macros CGI, lo que también conlleva rendimiento del servidor y (dependiendo de los CGI) cantidad de memoria.
(por escribir, lo siento) descripción general sobre ventajas/desventajas y consejos sobre qué usar y cuando.
Uh, un tema realmente difícil para ser descrito en una frase corta. No intento confundir sus ideas ingeniosas de diseño. Tampoco voy a hacer que se incline por mis estrategias personales de diseño. Sólo me gustaría añadir uno o dos dictámenes a las ideas de arriba sobre carga y ancho de banda del servidor.
Numerosas investigaciones sobre el comportamiento humano en interfaces de usuario y presentaciones en pantalla han publicado resultados interesantes. Existen algunos factores simples que uno debería tener en cuenta al diseñar páginas WWW.
¿Sabía esto? Si desea obtener más información sobre esto, busque en las guías de estilo GUI y en los resultados de investigaciones ergonómicas realizados por muchas universidades y compañías de software (incluida MS).
Hum, existen algunos. De hecho, se tienen noticias de que son muchos. Pero como yo ya hice todo lo que pude, no los he probado todos. Pero realmente espero con ilusión y curiosidad leer los informes que Uds. me envíen.
vi y vim son perfectamente aptos para escribir codigo HTML... (no me caliente la cabeza con esto) porque el código HTML sólo utiliza caracteres de texto ASCII. No quiero dar pie a otra guerra de editores. Aquellos que conocen el vi/vim y lo usan diariamente pueden utilizarlo también para código HTML. Puede hacer que el vi/vim le ayude a desarrollar código HTML creando algunas macros para el vi/vim. Pero como esto no es un VI-COMO, dejaré este hecho aquí solo. Sólo tenga en cuenta que es posible usar el vi/vim para editar HTML (al menos para algunos cambios cortos). Si Ud. ya sabe como programar el vi/vim, ciertamente también sabrá como abstraer HTML. Si no lo sabe, bueno, no se preocupe.
(por escribir, lo siento)
(por escribir, lo siento)
Ah, existen algunas referencias de un paquete llamado phoenix, basado en tkWWW, pero no he sido capaz de hacerlo funcionar en mi sistema. Creo que era un problema con mi versión del tcl/tk pero nunca lo sabré. No dediqué mucho tiempo con ellos, así que, quizás funcionen ambos en su sistema. Solamente vaya y pregunte en archie. Quizá, pueda mandarme un mensaje si tiene éxito.
Si Ud. echa en falta aquí su editor de HTML favorito, escríbame un mensaje. Quizás añada algunas referencias a páginas web acerca editores de HTML para Linux. Mándeme algunas bonitas URL.
¿ Conceptos, ideas, consejos ? Bueno, debería leer el grupo de noticias
comp.graphics. Y puede visitar
http://www.w3.org/pub/WWW/Graphics/.
GIF (Formato de Intercambio de Gráficos)
N. del T.: GIF = Graphics Interchange Formatfue introducido en 1987 por Compuserve, Inc. y revisado en 1989. Usa un algoritmo LZ, el cual es la causa fundamental de los derechos de autor de E.E.U.U. o de la ley de patentes. Deberían existir algunos problemas legales al usar este formato gráfico en internet (a pesar de que casi todo el mundo lo hace).
Gif es un buen formato para imágenes pequeñas con gráficos de estructura simple tales como gráficos de computador o iconos.
Gif posee algunas ventajas como que es uno de los formatos gráficos más extendidos (si no el más) en sistemas de conexión directa:
Las desventajas son:
El "Joint Graphic Experts Group" (JPEG), Grupo de Expertos en Gráficos Unidos", hizo el diseño para el formato gráfico jpeg/jpg/jiff. Este formato está basado en una transformación discreta de coseno (DCT) y en una compresión en código Huffmann. JPEG funciona con una perdida significativa de información, lo que puede hacer que sus imágenes aparezcan algo menos coloridas o con menos definición. El factor típico de compresión está entre 1:5 y 1:50. (Por encima de 1:10 cualquiera puede ver aparecer los artefactos a través del ciclo de compresión/descompresión.)
JPEG es un buen formato para fotografías, gráficos grandes e imágenes realmente complejas.
Las ventajas son:
Las desventajas son:
Portable Network Graphics (PNG), Gráficos de Red Portables, (el nuevo
formato en la red). PNG está favorecido por el consorcio W3. Para una
información más detalada visite
http://www.w3.org/pub/WWW/TR/WD-png.html
y
http://www.w3.org/pub/WWW/Graphics/PNG/Overview.html.
Encontrará aquí una especificación técnica, alguna información para
programadores, etc. PNG es un formato ideal que sustituye al GIF. La
página principal del PNG está en
http://quest.jpl.nasa.gov/PNG/.
Para los usuarios, PNG podrá tener
algunas ventajas y algunas desventajas. Aquí están:
En cuanto a las ventajas:
N. del T.: true color = color verdadero, incluyendo un elemento transparente
En cuanto a las desventajas:
PNG es soportado actualmente en Linux por los siguientes programas: ImageMagick (Versión >=3.7), GhostScript 4.0, Gimp, PovRay 3.0, el paquete netpbm. Para xv 3.10a existe un parche no oficial.
(por escribir, lo siento) netpbm, xv, ghostscript, gimp, ImageMagick, CorelDraw sobre Wine :-)))
Ahora existen muchas cosas especiales más allá del alcance de HTML e Image. Hay Applets escritas en páginas de Java y JavaScript y muchas cosas más.
No hay nada que añadir sobre Java en general, sólo lea la sección de Java en el capítulo de Netscape Navigator de este COMO y la descripción general sobre Java Applet contra las macros CGI en este COMO. Además, también puede leer el COMO JAVA de Linux, realmente bueno y compacto. Para programar en Java, por favor refiérase a libros verdaderamente buenos en este tema.
ActiveX es todavía, en el momento de escribir esto, un hijo de Microsoft. Microsoft proclamó que lo difundiría al dominio público o al menos en el consorcio ActiveX.
ActiveX no tiene nada que ver con el sistema X Window ni con XFree.
Deriva del sistema OLE de Microsoft e IBM. Después de difundir las especificaciones, habría una adaptación a Unix. Pero, tenemos que esperar hasta entonces. Nada para Linux, por el momento.