Posts Tagged servidor web
Ruby on Rails – Layouts y Hojas de Estilo
Posted by Xavi in Programación Web on 12/09/2011
Casi todas las aplicaciones web tiene una característica en común (y nótese que he dicho CASI TODAS, no todas) y es que la mayoría de sus páginas responde a un mismo modelo. Esta similitud entre páginas de la misma aplicación no ha pasado por alto a los responsables de desarrollo de frameworks y, actualmente, buena parte de éstos ya incorporan diferentes herramientas que nos ayudan a lidiar con la repetición de código HTML que estas similitudes comportan.

El nombre escogido bajo el cual se gestionas la repetición de componentes y estructuras entre páginas de una misma aplicación es “layouts”
Layouts
Ruby on Rails (o RoR, un acrónimo que es posible que use de aquí en adelante) tiene un sistema de gestión de layouts muy sencillo que se aprende en un periquete. Evidentemente, detrás de este sistema básico se esconde la posibilidad de profundizar en la funcionalidad y realizar tantas piruetas como se quiera con la gestión de los layouts de nuestra aplicación.
Durante la generación de la aplicación, de hecho, ya tenemos una primera pista de por dónde van a ir los tiros pues dentro de la carpeta app/views podemos encontrar un subdirectorio llamado layouts.
Con un poco de experiencia en el desarrollo web (y más concretamente en Java
) el primer impulso que uno podría tener sería el de pensar: “Oye, seguro que en el controlador puedo definir que layout quiero utilizar asignando el nombre del fichero a una variable o llamando a un método”. Sería lo normal… es a lo que nos han estado acostubrando desde pequeños… pues esta vez no nos hará falta; si no se quiere profundizar mucho en el tema, RoR nos permite utilizar un layout simplemente creando un fichero HTML con pedazos de Ruby embebido que se llame como el controlador que lo va a usar.
Por ejemplo, si tenemos un controlador llamado CondemorController (el archivo se llamará condemor_controller.rb) simplemente con tener un archivo, con las características que comentábamos en el párrafo anterior, llamado condemor.html.erb en la carpeta de layouts éste último será usado por el controlador para generar la página web de respuesta.
A todo esto, los primeros de la clase ya estarán pensado: “pues que co*azo de sistema, mi aplicación utiliza el mismo layout para todos los controladores”. Los que hayáis pensado esto, (podéis mandarme 50 euros y) os perdonaré, básicamente porqué yo mismo lo pensé cuando empezaba a trastear on RoR, pero esta gente se ha adelantado, se ha adelantado y permite que definamos un layout por defecto. En caso de no encontrar un archivo de layout que corresponda al controlador que está preparando la respuesta, se utiliza el layout por defecto de la aplicación para mostrar la respuesta al usuario.
Si lo pensamos bien, este método nos ofrece una gran variedad de combinaciones sin que esto conlleve un aumento en la complejidad de nuestra solución. Por un momento pensad la flexibilidad de este mecanismo para la creación de landing pages personalizadas o simplemente la creación de páginas especiales (como manuales o foros de ayuda) que no siempre necesitan ceñirse a la misma estructura que el resto de la aplicación. Es muy potente y muy simple, y la simplicidad a la hora de gestionar este tipo de estructuras nos puede ayudar mucho a aumentar nuestra productividad.
Hojas de estilos
Una herramienta básica en el uso de los layouts son las hojas de estilo. Las hojas de estilo (CSS) nos aportan una gran flexibilidad a la hora de definir el estilo gráfico de nuestras páginas web y bien aplicadas pueden hacer magia
En RoR, las aplicaciones tienen un directorio llamado public dónde se deberían almacenar todos sus contenidos estáticos (CSSs, JSs, imágenes y otro tipo de contenido estático). En un primer momento podríamos pensar que, simplemente sabiendo como vamos a desplegar la aplicación, tendríamos suficiente en poner un path relativo en la etiqueta HTML para cargar los archivos CSS y listos; pero, imaginaros que el despliegue de la aplicación acaba siendo en un servidor con unos configuración un tanto peculiar, o que esperábamos que el domino apuntase a la carpeta public y de golpe apunta a la raíz de la aplicación (esto no debería pasar nunca… ehemmm). Para solucionar los problemas que podrían ocasionar situaciones como la anterior tenemos una función que nos permitirá cargar una hoja CSS sin tenernos que preocupar por la ubicación final de los ficheros de la aplicación. Esta función se llama stylesheet_link_tag y a continuación os escribo un pequeño ejemplo de como podría utiilzarse en un archivo de layout:
...
<head>
<title>Aplicación con estilo</title>
<%= stylesheet_link_tag “style”, :media => “screen” %>
</head>
<body>
...
NOTA: El archivo que se carga con esta función es style.css y se encuentra en la carpeta public de la aplicación.
En el ejemplo podemos ver como el uso de la función no representa un gran esfuerzo en comparación con los quebraderos de cabeza que puede ahorrarnos. Dadle una oportunidad.
Y con esto terminamos una entrega más de este pequeño paseo por Ruby on Rails!
Me estoy divirtiendo mucho con este mini-proyecto y espero estar en situación de anunciaros la disponibilidad del software dentro de poco; ahora mismo tengo que acabar de añadir las cabeceras de la licencia y avanzar un poco más en el desarrollo, bueno, bastante más para poder ofrecer algo funcional, para que engañarnos
Seguid atentos!
Consejo del dia #1
Cuando tu proveedor de hosting hace algo bueno por ti sin que hayas reclamado nada y sin intertar cobrarte más, hazle caso en todo, pero todo todo. Es decir… si te mandan un correo del estilo:
“Estimado colaborador,
Como nos mola cantidad lo que haces en nuestros servidores, hemos decidido darte un mejor servicio sin que tengas que reclamarlo, ni cobrarte más, sólo porqué nos caes bien. Para ti nada va a cambiar…
… pero si algun dia quieres hacer una ofrenda a los dioses sacrificando un gusano verde fluorescente mientras haces el pino y te comes una piruleta de wasabi, nuestros servidores lo agradecerán.”
Si recibes esto ya puedes salir a buscar un gusano verde fluorescente, una piruleta de wasabi y alguien que sepa hacer el pino, porqué si no lo haces, tu proveedor se va a poner triste y se va a vengar.
Tú simplemente hazles caso, siempre (que no te cobren más).
Por cierto, el proveedor de hosting que ha hecho algo bueno para mi sin pedírselo es Hosting24.com. Eso sí… la piruleta de wasabi era bastante picante.
Modificar la cantidad de memoria disponible para Tomcat
Posted by Xavi in Linux, Programación Web on 14/12/2009
El rendimiento por defecto de un servidor Tomcat 6 es, normalmente, bastante bajo. Hace un par de días estaba realiando unas operaciones de recuperación de una aplicación en la que estamos trabajando y el servidor tardó varias horas en finalizar unas operaciones bastante básicas. Normalmente estas operaciones, al tomar tanto tiempo, se dan por perdidas en algún tipo de “deadlock” y se abortan (a no ser que se tenga el conocimiento de que van a durar tanto); pero a mi se me quedó la aplicación abierta en segundo plano (lo se… soy un desastre) y al final terminó las operaciones.
Al observar este comportamiento, recordé que había unos parámetros de configuración del Tomcat que modificaban el tamaño inicial y máximo de la pila de Java para un proceso y me puse a rebuscar entre las configuraciones de los diversos servidores con Tomcat a los que tenía acceso para recuperar esta pequeña “customización”.
Para modificar el tamaño inicial y máximo de la pila de Java para Tomcat (6) debemos modificar el archivo catalina.sh dentro del directorio bin en la raíz del directorio que contiene la instalación del Tomcat. La línea para añadir es la siguiente:
JAVA_OPTS="$JAVA_OPTS -Xms64M -Xmx1024M"
NOTA: Es importante que esta línea se añada furea de cualquier IF-ELSE del documento. Yo siempre lo añado justo antes de una línea comentada que pone Execute The Requested Command entre guiones, pero esto ya es a gusto del consumidor
El número que va después de -Xms es el tamaño inicial de la pila y el que va después de -Xmx es el tamaño máximo de ésta. La “M” sólo es para indicar que las dimensiones se están dando en MegaBytes. Dependiendo de los recursos de los que goza la máquina dónde tengamos el Tomcat estos parámetros deberán cambiar pero, por norma general, seguro que conseguimos una mejora en el rendimiento de nuestro servidor de aplicaciones Java.
Tomcat 6 en Ubuntu
Posted by Xavi in Linux, Programación Web on 03/11/2009
Este es un post corto para poner de manifiesto un opinión basada en la experiencia profesional que he recogido trabajando con este servidor de aplicaciones y Ubuntu (versiones 9.04 y 9.10)

Cuando trabajeis con Tomcat 6 bajo Ubuntu, seguid estos pasos:
- Eliminad TODO rastro de OpenJDK
- Instalad el paquete de Java de Sun (sun-java6-jdk en mi caso)
- Descargad el Core de la página oficial de Tomcat
- Descomprimid el paquete y ubicad los archivos en la carpeta /usr/share/tomcat6
Siguiendo estos pasos en lugar del facílisimo “sudo apt-get install tomcat6″ tendremos una instalación de Tomcat completamente “compacta”. En el momento que deseáramos llevarnos esta instalación de Tomcat a otra máquina sólo necesitaríamos copiar los archivos y comprovar que en la máquina destino tenemos una versión compatible de Java.
Para arrancar el servidor tendremos que ejecutar como root ‘startup.sh’ en el directorio ‘/usr/share/tomcat6/bin/’ y para pararlo ‘shutdown.sh’ en el mismo directorio.
Disfrutad de vuestro Tomcat 6
Lighttpd y la vida después de Apache
Posted by Xavi in Linux, Programación Web on 18/02/2009
La programación de sitios web dinámicos en PHP va casi siempre asociada al servidor Apache pero, en ocasiones, se puede recurrir a alternativas para mejorar el rendimiento de las aplicaciones web. En el presente artículo explicaremos la instalación del servidor Lighttpd en un sistema Ubuntu 8.10 para proyectos en PHP (compatibles con el Zend Framework).

Lighttpd es un servidor web más ligero que Apache que aporta un plus de rendimiento muy conveniente en según que entornos. El primer paso que vamos a describir se debe realizar sólo en el caso de que tengamos instalado un Apache 2 en el servidor.
Eliminar Apache 2 del servidor
Para eliminar este servidor del equipo podemos recurrir a la linea de comandos o al gestor de paquetes Synaptic. Para la línea de comandos deberemos ejecutar la siguiente orden y aceptar que nos desinstale todas las dependencias:
sudo apt-get remove apache2.2-commonPara el gestor Synaptic tendremos que localizar el paquete apache2.2-common, marcarlo para eliminar y aplicar junto con las dependecias también.
NOTAS:
- Seguramente nos pedirá desinstalar el paquete php5 de las dos formas, pero no pasa nada, después ya volveremos a instalar el interprete para este lenguaje.
- Si desinstalamos el paquete apache2 realmente no estaremos eliminando el servidor porque se trata de un meta-paquete que puede ser eliminado sin ninguna repercusión para los paquetes asociados.
Instalar el servidor Lighttpd
Para instalar el servidor yo recomiendo usar la linea de comandos (si se deseara utilizar Synaptic se tendrían que instalar los mismos paquetes que vamos a instalar a través del terminal pero buscándolos uno a uno).
Los paquetes que vamos a instalar son lighttpd, php5-cgi y lighttpd-doc (siempre que queramos la documentación de soporte para el servidor, mi recomendación es instalarla, nunca está de más…); lighttpd y lighttpd-doc son paquetes del servidor web mientras que php5-cgi será el paquete para interpretar las páginas dinámicas en PHP. Veamos el comando para instalar estos paquetes a la vez:
sudo apt-get install lighttpd lighttpd-doc php5-cgiNOTAS:
- Después de este paso aún no podremos ejecutar páginas PHP, nos faltan unos pequeños pasos que veremos a continuación.
- Si nuestra aplicación en PHP requiere acceso a base de datos tendremos que instalar los paquetes correspondientes (php5-mysql, php5-odbc…), en el caso de que necessitáramos manipular imágenes, instalaremos otros paquetes como por ejemplo php5-gd. En resumen, php5-cgi sólo nos proporciona un interprete básico de archivos PHP, para extenderlo existen muchos paquetes pero no los vamos a tratar en este post.
- Si intentamos visualizar una página PHP al final de este paso es posible que el servidor nos devuelva un error 403 FORBIDDEN. Para solucionarlo sólo tienes que seguir leyendo…
Activar PHP en Lighttpd
PHP debe ser activado en el archivo principal de configuración del servidor Lighttpd. Este archivo se llama lighttpd.conf y se encuentra en /etc/lighttpd/ para editarlo con Gedit por ejemplo tenemos que ejecutar el siguiente comando en el terminal:
sudo gedit /etc/lighttpd/lighttpd.conf* si estamos sin un entorno gráfico podemos editarlo con vim, pico o nano.
En el archivo de configuración vamos a tener que añadir el módulo fast-cgi (mod_fastcgi) nos va a tener que quedar una sección parecida a esta:
server.modules = (i tenemos que añadir nosotros una nueva sección como la siguiente (la podemos introducir justo después del paréntesis para cerrar la sección anterior):
"mod_access",
"mod_alias",
"mod_accesslog",
"mod_compress",
"mod_rewrite",
"mod_redirect",
"mod_evhost",
"mod_fastcgi",
# "mod_usertrack",
# "mod_rrdtool",
# "mod_webdav",
# "mod_expire",
# "mod_flv_streaming",
# "mod_evasive"
)
fastcgi.server = ( ".php" => ((NOTAS:
"bin-path" => "/usr/bin/php-cgi",
"socket" => "/tmp/php.socket"
)))
- Si necessitamos reescribir las URLs de las peticiones al servidor nos tenemos que asegurar que no estén comentadas (sin el ‘#’ delante) las lineas “mod_rewrite” y “mod_redirect”.
- El path “/usr/bin/php-cgi” puede depender de la instalación de los paquetes de PHP. Para asegurarnos podemos ejecutar el comando ‘whereis php-cgi’ y comprovar que nos arroja la misma ruta que hemos escrito en el archivo de configuración.
- Se pueden encontrar más opciones de configuración del modulo de PHP en la página oficial del servidor web aquí.
Setear un servidor virtual en Lighttpd
Se pueden setear servidores virtuales en Lighttpd de forma muy simple modificando el mismo archivo de configuración que en el apartado anterior (/etc/lighttpd/lighttpd.conf). Para setear un servidor virtual con la dirección “direccionaleatoria.com” y directorio base “/home/user/proyecto” tendremos que añadir una sección al final del archivo de configuración como la siguiente:
$HTTP["host"] == "direccionaleatoria.com" {NOTAS:
server.document-root = "/home/user/proyecto/"
}
- Igual que con el módulo PHP, se pueden encontrar más opciones de configuración avanzada de servidores virtuales en la página oficial del proyecto Lighttpd aquí.
Definir reglas de reescritura de URLs para el Zend Framework
Lighttpd puede ejecutar de forma eficiente proyectos realizados bajo el framework PHP de Zend siempre que se definan correctamente las reglas de reescritura de las URLs. Para conseguir esto debemos añadir las siguientes lineas al archivo de configuración:
url.rewrite-once = (Podemos conseguir que esta reescritura sólo afecte a un servidor virtual si añadimos estas lineas dentro del apartado correspondiente. Si queremos que la reescritura sólo afecte al servidor virtual que hemos seteado en el paso anterior la sección del servidor virtual debería ser la siguiente:
".*\?(.*)$" => "/index.php?$1",
".*\.(js|ico|gif|jpg|png|css)$" => "$0",
"" => "/index.php"
)
$HTTP["host"] == "direccionaleatoria.com" {NOTAS:
server.document-root = "/home/user/proyecto/"
url.rewrite-once = (
".*\?(.*)$" => "/index.php?$1",
".*\.(js|ico|gif|jpg|png|css)$" => "$0",
"" => "/index.php"
)
}
- Estas normas de reescritura se pueden encontrar en los foros oficiales del Zend Framework aquí.
Y con estos breves pasos… muy breves!!! Ya tenemos una aplicación web PHP (con Zend Framework o no) corriendo bajo Lighttpd, provadlo y me contais si corre más que en Apache.

Comentarios recientes