1. Rutas relativas y absolutas#

En el ejemplo “Demo2”, la ruta es relativa, ya que apunta dentro del mismo host. Esto se puede verificar al inspeccionar el código:

• Si apunta al mismo dominio, es relativa.
• Si apunta a otro servidor, es absoluta.

Las rutas relativas son preferibles para mantenimiento y portabilidad, mientras que las absolutas se usan para referencias externas.

1
cd /var/www/html
2
cat style.css

Si cambiamos el nombre del archivo y el navegador aún lo muestra, significa que está sirviendo desde cache. Esto puede ocultar errores (por ejemplo, archivos 404).

Con Firefox Developer Tools → More Tools → Style Editor, podemos ver el contenido real, incluso si el archivo fue borrado o renombrado. Los códigos más comunes son:

• 200: Recurso encontrado.
• 404: Archivo no encontrado.

💡 Consejo: en desarrollo, usa no-cache para forzar la recarga real del archivo y evitar confusiones.

2. Organización del proyecto#

Para mantener orden y claridad, se recomienda crear directorios separados:

• /images/ → para imágenes
• /css/ → para estilos
• /js/ → para scripts

Esto evita rutas confusas y facilita el mantenimiento, incluso si se usan rutas absolutas.

Objetivo: que la aplicación funcione correctamente en todos los navegadores estándares (como Mozilla), garantizando al menos un 95% de compatibilidad.

3. Uso de logs y análisis de tráfico#

Los archivos de error y acceso de Nginx permiten entender cómo los usuarios interactúan con el sistema:

1
cd /var/log/nginx
2
sudo cat error.log
3
sudo apt install goaccess

Con GoAccess, podemos ver estadísticas en tiempo real:

• Errores 404, 500, tráfico y carga por minuto.
• Permite estimar la demanda (por ejemplo, 1000 hits / 5 minutos).
• Muestra navegadores, IPs y patrones de acceso.

4. Despliegue con Nginx, Puma y Passenger#

Para entornos de producción, se recomienda usar Nginx como proxy inverso y Puma como servidor de aplicaciones Ruby on Rails:

1
# Ejemplo de configuración
2
passenger_enabled on;

Sin embargo, Passenger requiere compilación con cada actualización. Por eso, la mejor práctica actual es usar Puma con Nginx como balanceador:

• Nginx atiende las peticiones HTTP.
• Puma ejecuta la aplicación Ruby on Rails.
• Ambos trabajan de forma segura y aislada.

Ventajas:

• Aislamiento entre entornos (cada aplicación usa sus gemas).
• Mayor seguridad (sin permisos privilegiados).
• Menos dependencias y mejor mantenimiento.

5. Puertos y seguridad#

En otros servidores (como Java), las aplicaciones suelen correr en el puerto 8080, mientras que Nginx escucha en el 80 y redirige al puerto interno.

⚠️ Nota: los puertos inferiores a 1024 pueden ser explotados; por seguridad, es recomendable usar puertos superiores en producción.

6. Cache y entorno de desarrollo#

Ruby on Rails, por defecto, no usa cache en desarrollo, precisamente para evitar errores causados por archivos almacenados en el navegador. Esto permite ver cambios al instante y detectar problemas en rutas, hojas de estilo o vistas.

Glosario#