Etiqueta: Infraestructura

  • Cómo instalar librerías de composer en un hosting compartido

    Cómo instalar librerías de composer en un hosting compartido

    Una pregunta que me han hecho en repetidas oportunidades es cómo usar composer en un ambiente de hosting compartido.

    Personalmente, siempre prefiero usar mis propios servidores tipo VPS, precisamente para evitar este tipo de problemas, pero… si no queda otra, veamos qué se puede hacer.

    Cómo instalar dependencias si tenemos acceso ssh

    Existen algunos hostings compartidos que permiten algún tipo de acceso vía ssh (o similar).

    Si este es el caso, puede que hasta tengamos composer ya instalado… claro que la versión que podremos encontrar puede ser algo añeja y, como el servidor lo administra otro, tendremos que poner un ticket de soporte y rogar para que se actualice.

    Si tenemos suerte, podremos ejecutar composer y actualizar nuestras dependencias directamente en el servidor como si estuviéramos en un ambiente controlado por nosotros mismos… si esto no funciona podemos intentar la sigueinte opción.

    Cómo instalar dependencias en un hosting compartido si no tenemos acceso ssh

    Este es ciertamente el caso más común: no hay posibilidad de hacer ssh al servidor.

    Claro que, de alguna forma, nuestro código debe llegar al hosting… para eso lo contratamos a fin de cuentas, ¿cierto?

    Pues en este escenario lo que podemos hacer es preparar lo que vamos a subir al servidor en un directorio especial y luego subirlo.

    La idea de hacer esto en lugar de subir directamente lo que tenemos en nuestro directorio de trabajo es:

    1. Minimizar la transferencia (para disminuir el tiempo que insumirá la subida)
    2. Minimizar la cantidad de espacio que ocuparemos en nuestro espacio de hosting
    3. Evitar subir información sensible que sólo debería estar disponible en nuestro entorno de desarrolllo

    Cómo preparar la subida

    Idealmente nuestro código estará versionado (Usando git, svn o similar).

    Si este es el caso, lo que podemos hacer es generar un nuevo directorio local mediante un clone o checkout (depende de cuál sea el controlador de versiones que usemos).

    Una vez que tengamos el código descargado será tiempo de instalar las dependencias.

    Lo ideal sería subir siempre una copia limpia de nuestro sistema. Si esto no es posible, al menos deberíamos eliminar los contenidos del directorio vendor de nuestra aplicación para no acumular dependencias que ya no sean necesarias.

    Cómo actualizar las dependencias usando composer

    Independientemente de cuál sea el lugar donde ejecutaremos composer, el comando que debemos ejecutar es:

    composer install --no-dev -o

    Con este comando sólo se instalar las dependencias necesarias en producción y se optimizará el autoloading (dando mejor performance a nuestra aplicación).

  • Cómo llevar los cambios de una base de datos de desarrollo a producción

    Cómo llevar los cambios de una base de datos de desarrollo a producción

    Cuando tenemos una aplicación en producción (Es decir, siendo utilizada por usuarios reales) es muy común que nos encontremos con necesidades que no han sido cubiertas por el desarrollo original.

    Esto puede deberse a diversos factores como la falta de análisis, una pobre comprensión de la problemática a encarar o simplemente al hecho de que la realidad va cambiando conforme pasa el tiempo.

    Independientemente de cuál de éstas haya sido, cuando se detecta una necesidad que el software no cubre se requiere realizarle modificaciones para adaptarlo al nuevo escenario.

    Algunas veces los cambios en el código vienen de la mano de cambios en la estructura de la base de datos utilizada para dar soporte a la aplicación.

    Y ahí comienzan los problemas 🙂

    En un ambiente de trabajo profesional es muy común contar con diferentes entornos de ejecución.

    Al menos deberíamos tener dos:

    • Desarrollo (Donde trabajamos y los datos no son precisamente valiosos)
    • Producción (Donde trabajan los usuarios y los datos son sagrados).

    Parte de nuestro trabajo será realizar las modificaciones al código de la aplicación, probarlo y eventualmente desplegarlo en el servidor de producción.

    Para llevar el control de los cambios realizados sobre el código existen muchos sistemas de control de versiones, como por ejemplo Git o Subversion.

    Utilizar uno de estos sistemas simplifica mucho conseguir la perfecta sincronización entre el código que ejecutamos en nuestro entorno de desarollo y el de producción, pero… ¿cómo hacemos para que la estructura de la base de datos también esté sincronizada?

    Actualizar la base de datos manualmente

    El enfoque más simple consiste en aplicar los cambios a la base en forma manual.

    Esto significa entrar al servidor de bases de datos (Usando phpMyAdmin por ejemplo) y ejecutar los comandos que dejen la base en el estado deseado.

    Para usar esta estrategia no se necesita mucho más que buena memoria o buenas notas.

    Claro que la desventaja de este mecanismo es que es sumamente riesgoso y propenso a errores.

    Utilizar scripts SQL

    Otra opción más interesante es generar los scripts SQL que se utilizan durante el desarrollo y almacenarlos como parte del código, de modo de aprovechar el versionado de la propia aplicación.

    Este enfoque es mejor que el anterior ya que disminuye el riesgo de ejecutar comandos diferentes en cada ambiente y, de ese modo, minimiza las chances de terminar con estructuras de bases de datos distintas.

    Uno de los problemas que aún no resuelve este enfoque es cómo determinar de un modo simple cuáles cambios ya han sido aplicados y cuáles no.

    Versionar la base de datos

    Un enfoque alternativo es el uso de alguna herramienta para el versionado de la base de datos.

    En este esquema los cambios en el ambiente de desarrollo no se realizan escribiendo SQL, si no mediante código.

    Liquibase

    Liquibase es una herramienta basada en conjuntos de cambios (changeSets) descriptos usando diferentes lenguajes posibles (SQL, XML, Json o YAML).

    Una vez definidos los cambios que deben realizarse se utiliza el ejecutor de los cambios que es el encargado de verificar el estado actual, traducir los nuevos cambios a SQL e impactarlos.

    Migraciones de Doctrine

    Otra herramienta similar (y mi favorita :)) es el mecanismo de migraciones de Doctrine.

    Las migraciones son una parte de este gran ORM que describen los cambios que deben realizarse a la base de datos.

    Una gran ventaja de este mecanismo sobre Liquibase o similares es que todo el código se escribe utilizando puro PHP y al momento de ejecutar la migración queda a cargo de Doctrine realizar la traducción a SQL.

    Notas finales

    Como siempre, cuanto más automatizada sea nuestra operación más confiable será ya que podremos realizar tantos ensayos como necesitemos hasta contar con un mecanismo correcto.

    La contracara de utilizar una herramienta como esta es que es un camino de una sola vía: si no mantenemos la disciplina de escribir todos nuestros cambios del mismo modo nos vamos a encontrar con más problemas de soluciones… aunque, en la realidad, una vez que domines una de estas técnicas dificulto que quieras volver atrás 🙂

  • Cómo acelerar un sitio desarrollado con PHP

    Cómo acelerar un sitio desarrollado con PHP

    Por qué invertir en acelerar un sitio web

    La primera pregunta que uno se haría ante esta situación es: ¿para qué molestarse? 🙂

    Es decir, cualquiera preferiría un sitio rápido antes que uno lento, ¿cierto?

    Pero… ¿para qué sirve realmente tener un sitio más rápido?

    Bueno pues hay dos respuestas inmediatas:

    1. Mejor experiencia de usuario
    2. Mejor posicionamiento orgánico

    Ambas redundan en beneficios muy palpables para los dueños de los sitios: clientes más satisfechos y mayor afluencia de potenciales clientes.

    Qué factores influyen

    Muy bien, ahora que estamos de acuerdo en que tener un sitio rápido es beneficioso tenemos que comprender qué factores influyen en la velocidad de carga.

    La realidad es que son muchos y, lamentablemente, unos cuantos están fuera de nuestro control, pero igualmente analicémoslos un momento.

    Toda la interacción con un servidor web se basa en:

    • Una traducción de un nombre de dominio en una dirección IP
    • El establecimiento de una conexión entre el cliente y el servidor
    • El envío de información desde el cliente hacia el servidor
    • La resolución del pedido por parte del servidor
    • El envío de información desde el servidor al cliente
    • El rendering del lado del cliente

    Como puede verse, un factor decisivo será la velocidad de la red subyacente en esta comunicación (Lo que se conoce como ancho de banda) pero definitivamente no es el único.

    De modo que existen medidas que pueden tomarse para mejorar el tiempo del lado del cliente (frontend) y otras tantas del lado del servidor (backend).

    Cómo acelerar el frontend de una aplicación Web

    Acelerar el frontend implica minimizar:

    • La cantidad de pedidos al servidor
    • La cantidad de información intercambiada en cada pedido
    • El tiempo que insume el rendering

    Un típico cuello de botella lo encontramos en el tamaño de las imágenes u otros archivos estáticos (JavaScript, CSS, etc…).

    Reduciendo estos es posible ganar mucho.

    Una herramienta muy útil para medir estos cuellos de botella es GTMetrix

    Cómo acelerar el backend de una aplicación Web

    Y luego está la otra cara de la moneda: el servidor.

    ¿Qué podemos hacer para que nuestro servidor responda más rápido?

    Nuevamente, tenemos que saber a dónde apuntar nuestros cañones.

    Usualmente una aplicación web consiste en:

    • Un webserver
    • Una base de datos
    • Algún script

    En nuestro caso asumiremos que se trata de PHP, aunque los principios aplican para cualquier lenguaje.

    Es muy probable que la parte más compleja de optimizar sea el código de la aplicación.

    Principalmente porque lograr el mismo resultado usando mejor código requiere mucho análisis y, sobre todo, mucho testing para asegurarnos de no romper nada en el camino.

    Hay unas cuantas mejoras que pueden hacerse desde la infraestructura que son muy simples y aportan mucho. Por ejemplo:

    • Distribuir la carga a través de un CDN
    • Enviar el contenido comprimido
    • Usar algún minificador de CSS/JS
    • Usar un caché agresivo en el webserver
    • Usar PHP vía PHP-FPM

    Y luego hay otras herramientas que complementan al servidor web como ser los cachés de memoria (APC, Memcached, Redis, etc…)

    También vale la pena investigar qué consultas pueden estar trabando la base de datos, por ejemplo usando el MySQL slow query log e intentar mejorarlas.

    Y por último, si sospechamos que el código está haciendo de las suyas podemos usar un profiler como XDebug para orientarnos sobre dónde poner la lupa.

    Conclusión

    En definitiva, acelerar un sitio web lento es perfectamente posible pero también bastante laborioso.

    Siempre debe primar un criterio de costo/beneficio para saber cuando se ha alcanzado una velocidad aceptable y ya no vale la pena el esfuerzo de seguir mejorándolo.

  • ¿Es posible hostear una aplicación PHP en Windows?

    ¿Es posible hostear una aplicación PHP en Windows?

    Un amigo me contactó por un problema que estaba enfrentando su equipo técnico: están desarrollando una aplicación PHP que necesitan hostear sí o sí en un servidor Windows.

    Actualmente tienen un IIS montado en su servidor y la duda era, primero si era posible servir PHP desde IIS o si era necesario usar un servidor Apache y, en tal caso, si era necesario compilarlo desde 0 (Algo que estaba fuera del alcance de dicho equipo).

    Mi primera impresión ante esta situación fue de sorpresa. Ciertamente, Windows no sería mi elección en cuanto a servidor (En general prefiero mantenerme alejado de Windows, pero especialmente para el caso de servidores soy bastante estricto).

    Yo optaría por alguna distribución de linux (Probablemente basada en Debian como para hacer las cosas sencillas, pero en DistroWatch siempre se encuentran sorpresas interesantes) y, de ser posible iría con un VPS montado en DigitalOcean.

    Ahora bien, intentaré responder las preguntas de a una.

    ¿Puede IIS servir PHP?

    Sí.

    De hecho, Microsoft tiene un sitio especialmente dedicado al tema en https://php.iis.net/

    Un pequeño detalle es que este sitio ha quedado algo desactualizado… habla de la versión 5.3 de php :p, pero se pueden seguir estas instrucciones para actualizar la versión a alguna más moderna.

    ¿Puede Apache instalarse en Windows?

    Sí.

    El webserver Apache está escrito en lenguaje C con lo cuál, puede crearse una versión especial para cualquier plataforma que tenga un compilador de ese lenguaje (Tal es el caso de Windows).

    ¿Es necesario compilar Apache desde cero para instalarlo en Windows?

    No.

    Apache puede ser instalado directamente descargando los binarios (sólo que no los podrás obtener del sitio oficial del proyecto que sólo tiene el código fuente).

    Un par de lugares donde podés conseguir los binarios de Windows:

    Y si te interesa el «paquete completo» podés usar alguno de los que viene ya con MySQL y PHP:

    Sí es cierto que al compilar el Apache vos mismo tenés más control sobre lo que instalás en tu servidor (¡Pero también podés hacer mucho lío si no sabés lo que estás haciendo!).

    Conclusión

    Es perfectamente posible hostear una aplicación PHP en un servidor Windows. Las opciones son muchas y, como de costumbre, no existe una que sea universalmente mejor que las otras, será cuestión de evaluar tus posibilidades y decidir cuál es el mejor camino.

  • Qué se necesita para poner online una aplicación PHP

    Qué se necesita para poner online una aplicación PHP

    Una pregunta que parece algo obvia, ¿no? Lo que se necesita para poner en línea una aplicación PHP es un hosting. No hay mucho más que decir al respecto, ¿cierto? Pues… tal vez convenga hilar un poco más fino.

    Si bien en sus inicios PHP se utilizaba exclusivamente para la creación de aplicaciones web, hoy en día abarca un abanico mucho más amplio.

    En este artículo me centraré en la infraestructura mínima necesaria para poner en línea una aplicación web desarrollada con PHP.

    Qué debe tener un servidor para hostear una aplicación PHP

    Lo primero que debemos comprender es que, para que una aplicación web esté en línea, independientemente del lenguaje en que esté desarrollada, se requiere:

    1. Que el código esté disponible en alguna computadora conectada a Internet (El Servidor)
    2. Que dicha computadora cuente con algún software capaz de recibir peticiones a través de Internet (El WebServer) instalado y funcionando
    3. Que la dirección IP de esa computadora sea conocida en forma pública (o fácilmente averiguable)

    En el caso de PHP un requisito adicional es que esté presente en el servidor un software capaz de interpretar y ejecutar el código (El intérprete).

    Existen muchas combinaciones diferentes de software que se encargan de esto, entre las más conocidas podemos encontrar:

    Incluso es posible utilizar el Internet Information Server si el sistema operativo del servidor es Windows.

    Luego será necesario configurar el servidor web de modo que ciertas peticiones sean derivadas al intérprete de php (A diferencia de otras que simplemente deben ser servidas enviando el contenido de los archivos solicitados).

    Esta configuración es diferente según el paquete de software con que se cuente.

    Qué servicios aparte del hosting se necesitan para poner online una aplicación PHP

    Usualmente, cuando se desea poner un sitio en línea, se busca que los visitantes accedan al mismo a través de una dirección sencilla de recordar (Lo que se conoce como un dominio), sin embargo, para que la computadora cliente pueda conectarse a la computadora servidor es necesario conocer su dirección IP.

    Para ello existe un servicio adicional: el DNS.

    De modo que, para que nuestro sitio esté disponible al público será necesario, además de registrar un dominio, configurar el DNS para que realice esa traducción.

    Luego, dependiendo de las necesidades específicas del sitio que queremos montar, es probable que sea necesaria la instalación de algún software de gestión de bases de datos (Como MySQL, PostGre o alguno similar).

    Respecto de la computadora que actuará como servidor, existen diferentes opciones (de diferentes costos y requisitos técnicos).

    Se puede usar una computadora personal propia, contratar espacio en un servidor compartido, comprar una computadora y dejarla en un proveedor que garantice la alimentación y conectividad, usar un servidor virtual… en fin, las opciones son muchas.

    ¿Te cuesta decidir? Este post puede ayudarte.

  • Cómo determinar la versión de PHP de un sistema

    Cómo determinar la versión de PHP de un sistema

    Una de las primeras tareas que debemos encarar cuando realizamos una auditoría de código de un sistema es detectar la versión de PHP que se está utilizando.

    Es importante saberlo para darnos una idea de qué tanto mantenimiento se ha realizado sobre el código y hasta cuánto se puede mejorar apalcándonos en las últimas características disponibles (O qué tan costoso será incorporarlas debido a refactors y demás).

    Hay diversas formas de encarar esta tarea. Nombraré algunas:

    Qué nos dice el webserver

    Una forma muy sencilla es realizar una petición al servidor web y analizar los encabezados de la respuesta.

    Ejemplo:

    No hace falta ser muy perspicaz… si el webserver tiene instalada la versión 5.3.29… el código a lo sumo está desarrollado usando esa versión.

    Si bien no es una información 100% certera, nos da una buena primera aproximación a lo que nos estamos enfrentando.

    Esta técnica, sin embargo, tiene un par de inconvenientes:

    1. Depende de que el código esté publicado en algún webserver (Suposición bastante lógica si lo que estamos viendo es una aplicación real)
    2. Depende de que la configuración del webserver no sea muy segura (En general, es preferible no mostrar este tipo de información a entidades externas de propósitos poco claros…).

    Tal vez composer pueda ayudarnos

    Si tenemos la suerte de encontrarnos con un proyecto hecho usando composer tal vez encontremos la solución dentro del archivo composer.json:

    O composer.lock:

    A hurgar se ha dicho

    Pero si realmente queremos saber para qué versión se escribió el código… nada mejor que analizar el código mismo.

    ¿Qué es lo que estamos buscando? Evidencias de uso de construcciones que sólo se hicieron disponibles a partir de cierta versión.

    En el caso de PHP, la evolución que ha tenido el lenguaje en los últimos años hace bastante simple esta tarea.

    Por ejemplo, a partir de la versión 5.4 apareció una característica muy popular: la definición de arreglos en forma literal ( $a = [1, 2, 3] ).

    Basta con encontrar un punto del código donde se utilice una definición como esta para decir que el código está escrito para un intérprete versión mayor o igual que 5.4.

    De la misma forma en que se agregan características al lenguaje en forma constante, también se quitan aquellas que ya no se consideran seguras.

    Esto significa que, si encontramos usos de características que han quedado obsoletas en una determinada versión, el código debe estar escrito pensando en una anterior.

    Para saber qué es lo que debemos buscar basta con leer las guías de migración de versión que se encuentran en php.net (Por ejemplo, acá están las indicaciones para migrar de 4 a 5 y acá de 5.6 a 7.0).

    Por qué es importante

    Saber en qué versión se encuentra un sistema nos permitirá, por ejemplo, evaluar un hosting antes de contratarlo.

    Por otro lado, siempre es preferible usar la última versión disponible del lenguaje a la hora de programar y saber que tenemos entre manos un sistema viejo nos dará una idea del esfuerzo que conllevará ponerlo al día (Y tal vez lo mejor sea re-escribirlo por completo).

    ¿Conocés alguna otra forma de determinar la versión de PHP utilizada en un sistema?

  • Backups de tu MySQL almacenados en Google Drive

    Backups de tu MySQL almacenados en Google Drive

    Cuando una aplicación entra en producción (si no antes), resulta clara la necesidad de realizar backups.

    Aunque tu código sea una obra de arte digna del Louvre, lo realmente importante son los datos que generan los usuarios.

    Por más que estés usando hostings virtualmente irrompibles (Como Digital Ocean), nunca podés ser demasiado precavido.

    Hay varias formas de resolver este problema, voy a nombrar algunas (De más fácil a más compleja).

    Cómo hacer backups usando MySQL WorkBench

    Desde la pantalla principal (Una vez conectado a un servidor)

    Arriba a la izquierda encontrás el menú «Management»:

    De ahí tenés la opción «Data Export»:

    Eso te lleva a la pantalla de selección de los objetos que vas a querer exportar:

    Seleccioná la base de datos y las tablas:

    Importante: seleccioná la opción «Export to self contained file»:

    De otro modo, la exportación se hará a un archivo por tabla (Lo que simplemente complicará el proceso de restauración).

    Por último, debés iniciar el proceso de exportación:

    Y listo! Lo que obtendrás será un archivo con las instrucciones SQL para crear tu base de datos tal y como está en tu servidor:

    Este proceso es simple pero tiene dos inconvenientes principales:

    1. Es un proceso manual (Es decir, alguien debe acordarse de hacerlo)
    2. Sólo funcionará si tenés disponible una terminal gráfica (O acceso remoto usando una, lo cual es algo poco usual).

    Cómo hacer backups usando MySQLDump

    Una herramienta que viene dentro del paquete MySQL es MysqlDump.

    Se trata de una sencilla utilidad de línea de comandos cuyo objetivo es simplemente realizar volcados (dumps) de bases de datos.

    Si alguna vez usaste el cliente de línea de comandos de MySQL (el comando mysql), la forma de utilización de mysqldump no debería resultarte ajena: se especifica el servidor, la base de datos y algunas opciones más:

    Y se obtienen las sentencias sql requeridas para crear una base de datos igual que la que tenemos ahora:

    Claro que… no es muy útil tenerlo todo en la pantalla, ¿cierto?

    ¡A no preocuparse! Basta con redireccionar la salida standar y estás listo:

    Y si querés hacer algo realmente bueno podés usar un poco más de la magia de POSIX y hacer algo como:

    Y terminar con un archivo comprimido con la fecha de hoy como parte del nombre como para identificarlo rápidamente.

    Este enfoque sigue siendo manual pero:

    1. No requiere de consola gráfica (Es más probable que no tengas problemas para usarlo en tu servidor)
    2. Es fácilmente scripteable

    El último punto es lo que permite justamente sacar de la ecuación a los humanos:

    Cómo automatizar los backups de la base de datos

    Si conocés la utilidad cron te habrás imaginado ya que la verdadera potencia de este esquema está en la realización automática (y periódica) de los backups.

    Así que, si te tomás el trabajito de crear un script con el comando como el que estaba antes:

    Le das permisos de ejecución:

    chmod +x backup.sh

    Y lo ponés dentro de un cronjob:

    Ya te podés olvidar de entrar a hacer los backups al servidor.

    No está mal, ¿cierto? ¿Qué falta? ¡Ah! Sí… ¿dónde deberías guardar los backups?

    Cómo almacenar los backups en Google Drive

    Si llegaste hasta acá debe ser que te interesa mucho tener bien resguardada la información de tus clientes.

    La frutilla del postre es, aparte de realizar los backups en forma automatizada, almacenarlos en algún lugar seguro (Distinto de tu hosting).

    Existen varias alternativas, pero una bastante al alcance de cualquiera es usar una cuenta de Google o Office 365.

    Con este script guardamos los backups de las últimas 5 semanas en nuestra cuenta de Google (Todo gracias a la ayudita de un cliente de GoogleDrive para línea de comandos).

    #!/bin/bash
    backup_dirs='/var/lib/mysql'
    today=`date -I`
    backup_gdrive_path='/opt/backups/'
    
    tar -zcf ${backup_gdrive_path}/prod-${today}.tgz $backup_dirs
    old_backups=`ls -1r $backup_gdrive_path | awk 'NR <= 5 { next} { print }'`
    
    if ! [ "$old_backups}x" == "x" ]; then
     for f in $old_backups; do
     rm -f ${backup_gdrive_path}/$f
     done
    fi
    
    cd $backup_gdrive_path
    drive push -no-prompt -quiet
    drive emptytrash -no-prompt -quiet

    Y por supuesto… ¡no olvides ponerlo como cronjob!

    Y ahora sí, tenés todo lo necesario para montar un sistema de backups remotos automatizados para tu sitio.

  • Qué es un CDN y por qué deberías usarlo

    Qué es un CDN y por qué deberías usarlo

    CDN significa Content Delivery Network o Red de Distribución de Contenidos.

    Se trata de conjuntos (por lo general bastante grandes) de servidores sincronizados entre sí y preparados para servir contenido estático desde diversos puntos del planeta.

    Su objetivo principal es el de disminuir el tiempo de carga de una página web (Algo que siempre viene bien).

    Este objetivo se logra combinando varios factores. Entre ellos:

    1. Aprovechando el paralelismo de los pedidos HTTP: Al tener el contenido distribuido en diversos servidores (en lugar de tener el código php y los archivos estáticos en el mismo) el cliente puede lanzar varias peticiones en paralelo por un lado y, por el otro, el pobre servidor al que llegan todos los visitantes de tu sitio puede delegar parte de la carga, lo cual a su vez hace todo el proceso más ligero.
    2. Sirviendo el contenido estático desde la locación física más cercana a cada cliente. Parte de la magia del CDN es tener la capacidad de identificar velozmente cuál es el nodo que responderá con menos latencia (Generalmente el que se encuentre más próximo al cliente).

    Qué se puede almacenar en un CDN

    Cualquier recurso estático (html, javascript, imágenes, etc…) es susceptible de ser almacenado en un CDN. De hecho, la mayoría de las librerías populares de javascript (Como jQuery por ejemplo) tienen sus propios CDNs que podés usar para cualquier proyecto, basta con hacer un include como este:

    <head>
    <script src="https://ajax.googleapis.com/ajax/libs/jquery/3.2.1/jquery.min.js"></script>
    </head>

    De esta forma, en lugar de usar un archivo de jQuery alojado en tu propio servidor, usás la capacidad instalada de Google.

    Otra ventaja de usar un CDN (En realidad esto no es particular del CDN si no de cualquier fuente conocida) es que muy probablemente el cliente ya haya descargado el archivo que tu sitio necesita para funcionar, aún cuando se trata de la primera visita (Otra optimización de performance que realizan los navegadores).

    Alternativas

    CloudFlareExiste una gran cantidad de empresas que ofrecen servicios de CDN, te dejo acá algunas que yo he usado en proyectos propios:

    En cuanto a su funcionalidad están todas bastante cerca, el factor que suele inclinar la balanza es el precio… ahí CloudFlare es un claro ganador ya que ofrece un muy buen paquete gratuito.

    ¿Qué opinás? ¿Vas a implementar un CDN en tu próximo proyecto?

  • Cómo autenticar usuarios vía HTTP usando PHP

    Cómo autenticar usuarios vía HTTP usando PHP

    La autenticación a nivel de HTTP se activa mediante la configuración del webserver.

    Es el nivel más bajo de autenticación que puede tenerse en un entorno web, ya que lo que va a verificar es que el cliente que solicita un determinado recurso (URI) tenga acceso a él, antes de hacer ningún otro tipo de verificación.

    De lo que estoy hablando es de lo que sucede cuando querés ingresar a un sitio, por ejemplo http://localhost y, en lugar de ver el contenido del sitio, se abre una ventana como esta:

    Por lo general, no es mucho lo que puede validarse (No hay posibilidad de ofrecer diferentes niveles de acceso ni nada parecido), con lo cual, no es algo que suela utilizarse en entornos de acceso público.

    La forma de configurar este tipo de acceso depende del web server que uses.

    En el caso de Apache, la forma de lograrlo es:

    1. Crear un archivo de autenticaciones (Usando la utilidad htpasswd por ejemplo).
    2. Dentro de la configuración del servidor, definir un bloque para el DocumentRoot:
     <Directory "/var/www/html">
       AuthType Basic
       AuthName "Restricted Content"
       AuthUserFile /etc/apache2/.htpasswd
       Require valid-user
     </Directory>
    1. Reiniciar el servidor (O, menos drástico, recargar la configuración).

    A partir de este momento, cualquier usuario que desee ingresar a tu sitio tendrá que identificarse (Ante el webserver).

    Otra forma de usar este tipo de autenticación (que no depende de la configuración del webserver), es hacerlo a través de PHP:

    La clave aquí es el uso de la función header (y conocer algunos detallitos del protocolo HTTP :)).

    Básicamente se trata de un script que será invocado dos veces:

    La primera será la que solicite las credenciales y la segunda será la que valide (Lo mismo que podrías hacer si hicieras un login clásico, con la diferencia de que la segunda llamada se produce automáticamente al completar los datos).

    El código es este:

    <?php
    if (!isset($_SERVER['PHP_AUTH_USER'])) {
        header('WWW-Authenticate: Basic realm="My Realm"');
        header('HTTP/1.0 401 Unauthorized');
        echo 'Este texto se ve si el usuario cancela';    
    } else {
        echo "<p>Hola {$_SERVER['PHP_AUTH_USER']}.</p>";
        echo "<p>Tu password es {$_SERVER['PHP_AUTH_PW']}.</p>";
    }

    El if está para validar si estás en la primera llamada o en la segunda. Las claves de la variable de $_SERVER se completan automáticamente con lo ingresado por el usuario.

    Esta forma puede ser más conveniente ya que te permite independizarte del WebServer con el que estás trabajando (Y por lo tanto, cambiarlo será más sencillo).

    Por último, una forma de acceder al sitio sin pasar por el formulario es pasar las credenciales como parte de URL:

    http://user:password@localhost

    ¿Qué forma de autenticación usas en tus aplicaciones?

  • Cuál es el mejor hosting para PHP y Mysql

    Cuál es el mejor hosting para PHP y Mysql

    Tu aplicación está lista para abrirla al mundo, ¡felicitaciones!

    Ahora hay una pregunta ineludible: ¿dónde la vas a alojar?

    Es tentador usar un hosting compartido y que otro se encargue de la infraestructura, ¿no? Más aún si es gratuito… pero ¿qué pasa cuando se necesita algo más?

    No es para nada raro enfrentarte a situaciones como estas:

    «Tengo una aplicación muy sencilla alojada en hostinger. Iba bien hasta ayer que se cayó la web y resulta que tengo un ataque DDos y claro no puedo monitorear ni nada por que no tengo acceso ssh al servidor«


    «Mi proveedor de hosting me ha bloqueado todo acceso al cpanel y página web por tener el disco lleno, ahora me obliga a adquirir un plan superior para darme acceso al cpanel»


    «Durante meses estuvo funcionando bien hasta que los que me proveen el servicio de hosting se les ocurrio cambiar el servidor, a partir de ahí las variables $_SESSION llegan vacias a las otras paginas.»

    Claro que montar tu propio servidor tampoco es un paseito.

    Lo primero que tenés que pensar en esto es si vas a ser capaz de darle soporte (Qué pasa si se cae el Apache en la mitad de la noche por ejemplo).

    Después está el tema de qué le vas a instalar.

    ¿Sos un fanático del composer?

    ¿Necesitás Memcached?

    ¿APC?

    ¿Cronjobs?

    Otro tema importante es qué consumo de recursos tiene tu aplicación.

    ¿Qué tanto tráfico vas a tener?

    ¿Qué tanta memoria necesitan tus scripts para correr cómodamente?

    Como de costumbre, no existe una respuesta única y universal, cada alternativa tiene sus ventajas y desventajas.

    Ventajas de usar un servidor compartido

    1. Costo (El abono suele ser más económico, aunque algunas VPS como DigitalOcean tienen planes super interesantes)
    2. Soporte técnico incluido (Como siempre, no todos los proveedores te van a dar el mismo nivel de soporte, pero siempre vas a tener algún tipo de soporte ante inconvenientes)
    3. Actualizaciones a cargo del proveedor (No te vas a tener que preocupar por actualizar paquetes)

    Desventajas de usar un servidor compartido

    1. Actualizaciones a cargo del proveedor 🙂 (No, no es un chiste, si bien esto te libera de responsabilidad, te resta flexibilidad ya que para instalar cualquier paquete vas a tener que pedir permiso… ¡y puede ser que te lo nieguen!)
    2. Disponibilidad de recursos errática (Dependés de qué tan bien o mal se comporte el resto de las aplicaciones que compiten con la tuya por el uso de los recursos compartidos lo cual puede impactar negativamente en la experiencia de tus usuarios)
    3. Dificultad para ajustar la configuración de php (No siempre tendrás acceso a modificar el archivo php.ini por ejemplo).

    VPS o hosting compartido: cómo decidir

    Salvo que te encuentres en alguna de estas situaciones:

    • Tu proyecto es muy chicos
    • Tu sitio es mayormente estático
    • No sabés (ni querés aprender) cómo administrar un webserver con algún esquema de monitoreo automatizado

    La mejor opción será siempre ser dueño de tu servidor, aunque implique algo más de trabajo al comienzo, instalando una herramienta como monit vas a poder dormir tranquilo 🙂

    Así que ya sabés, en tu próximo proyecto, dale una oportunidad al VPS.

    De hecho, si no tenés mucha experiencia administrando tus propios servidores, un proveedor que puede resultarte sumamente interesante es Cloudways que ofrece un modelo híbrido:

    Para una gran cantidad de cosas se comporta como un hosting compartido, en el sentido de las herramientas simples que te brinda, pero en realidad opera como un VPS, o mejor dicho, como varios a la vez.

    Usando Cloudways podés tener un sistema multicloud a muy bajo costo y con muy poco esfuerzo de administración.

    Vale la pena conocerlo. Probalo.