En un ordenador de desarrollo recién instalado. Me ha arrojado un error:
Root composer.json requires php ^7.3 but your php version (8.1.0) does not satisfy that requirement
¿No se supone que si tengo la versión 8 de PHP ese requisito debería no dar un error?
Me crucé con esta consulta recientemente y me pareció interesante responderla ya que, probablemente, quien la realizó no sea el único con este problema u otro similar.
Claramente la respuesta a la pregunta ¿No se supone que si tengo la versión 8 de PHP ese requisito debería no dar un error? es un No rotundo. Vamos que si no fuese así la pregunta ni existiría pero bueno… tomémosla como una pregunta retórica y un buen disparador para este post.
Es más, cambiaré la pregunta por la que puse como título: ¿Por qué PHP 8 no satisface el requisito ^7.3 de composer?
Para responder a esta pregunta es necesario comprender qué significa el ^7.3 que está en el archivo composer.jon.
Antes de meterme en los detalles es importante saber que, en este contexto, esa expresión corresponde a un requisito de versión (Version constraint).
Cómo funcionan los version constraints de composer
Una de las características más potentes (¡y más confusas!) de composer es esta: la especificación de las versiones aceptables de cada dependencia.
Precisamente, el motivo de la creación de composer fue el poder evitar tener la versión X.Y.Z de una librería en desarrollo y luego, en producción encontrarte con la versión X+1.Y.Z y que todo explote misteriosamente.
La premisa en la que se basa composer es que las dependencias definen sus versiones utilizando versionado semántico. Si este supuesto no se cumple… difícilmente composer pueda hacer bien su trabajo.
Ahora, el modo de expresar estos requerimientos requiere prestarle bastante atención a los detalles.
Para comenzar, existen diferentes tipos de restricción.
La más simple de ellas es la exacta. Este tipo de restricción debe usarse cuando sabés exactamente qué versión de una dependencia querés usar. En este ejemplo sería algo como 7.3.33.
En un caso como este no hay dudas, el trabajo de composer es bien sencillo: descargar los archivos correspondientes al tag 7.3.33 del repo de php.
Un caso de uso más realista es aquel en que no sabés el número exacto de la versión si no un aproximado.
Sería algo como decir quiero usar una versión de php 7.3, el patch no me interesa demasiado.
Esto sería similar a decir quiero una versión que se encuentre entre la 7.3.0 y la última antes de la 7.4.0.
Para expresar dicha restricción podés usar la combinación de dos restricciones:
>=7.3
<7.4
En el caso de composer, estas se combinan usando un simple espacio en blanco, que se interpreta como un &:
>=7.3 <7.4
Un detalle importante: composer siempre responderá con la versión más reciente que pueda, es decir, aquella que satisfaga todas las restricciones solicitadas.
Qué significan los símbolos de las versiones en composer
Ahora sí, vamos a ir un poco más abajo y veamos cada uno de los símbolos que se pueden usar para especificar versiones.
>= y < se explican por si mismos creo.
Pero también existen ~, ^ y *… la cosa se complica, ¿no?
Intentaré ir del más simple al más complejo.
El * es un viejo conocido de quienes estamos en software. ¿Tal vez te suene de las experesiones regulares? Pues sí, es el comodín.
Esto significa que una restricción de tipo 7.3.* se interpreta como cualquier patch de la rama 7.3. Es decir, composer mapeará este valor al tag más reciente que encuentre en dicha rama.
El ~ es una forma abreviada de escribir una restricción tipo >= <.
El ^ se comporta casi como ~ pero es algo más estricto.
La idea tanto de ~ como de ^ es evitar problemas de incompatibilidad hacia atrás.
Esta es la clave para comprender el problema que está experimentando el protagonista de esta historia:
La restricción ^7.3 marca, ante todo, que el major de la versión de php a utilizar debe ser 7, el minor podría cambiar (y, por supuesto, también el patch).
Esto se debe a que, en cualquier salto de versión major es posible encontrar cambios que rompan compatibilidad hacia atrás.
Es por eso que composer no permitirá que inadevertidamente introduzcamos un cambio de infraestructura que ponga nuestro sistema en riesgo.
El sistema de restricciones de versiones es bastante complejo, si quieres conocer más sobre él te recomiendo ir directo a la fuente.
De hecho, si te encuentras en una situación como la que dio origen a este post, te recomiendo abrir ese documento en una ventana y tu composer.json en otra.
Te decidiste. Llegó la hora de incorporar el testing automatizado a tus proyectos.
Permitime que te felicite, es un gran paso hacia la generación de software de calidad superior.
Después de hacer la debida investigación hay pocas dudas: PHPUnit es la herramienta que debes conocer.
Para hacerte un poco más sencillo el camino, te dejo los lineamientos para dar tus primeros pasos.
Cómo instalar PHPUnit
Lo primero, como de costumbre, será instalar la herramienta.
Si vas al sitio de phpunit.de encontrarás algo como:
Nada mal para tener a mano pero, para empezar de cero… puede ser algo intimidante.
Antes de continuar, una advertencia: las versiones de phpUnit están bastante ligadas a las de php. Esto significa que, para asegurarte de elegir una versión que puedas utilizar, debes saber qué versión de php tienes instalada (O piensas instalar, por ejemplo, si utilizarás docker).
Seleccionar la versión de phpunit
Asumamos que, para arrancar, usarás el php instalado en tu propio host.
Un simple php -v alcanzará:
Pues bien, en este caso, la versión que más conviene utilizar es la 11, como puede verse aquí:
El siguiente paso: instalar la librería.
Instalar phpunit mediante el phar
La primera opción disponible es descargar el paquete cerrado (el archivo .phar) de aquí y hacerlo ejecutable.
Esta opción puede resultar útil si quieres dejar una única versión de phpunit disponible para todos tus proyectos.
Instalar phpunit usando composer
Por lejos, la forma que recomiendo (y utilizo) es hacerlo a través de composer.
De esta forma, la dependencia quedará circunscripta al proyecto en el que estás trabajando en este momento, a la vez que puedes compartir esta configuración con el resto de tu equipo.
Usa composer require --dev phpunit/phpunit ^11 y composer se encargará de todo.
Para verificar tu instalación usa el comando ./vendor/bin/phpunit --version
Si ves algo como
PHPUnit 11.4.4 by Sebastian Bergmann and contributors.
PHPUnit 11.4.4 by Sebastian Bergmann and contributors.
Estás listo para avanzar.
Cómo escribir un test con PHPUnit
Escribir un test de PHPUnit supone crear una nueva clase que extienda de TestCase:
<?php declare(strict_types=1);
use PHPUnit\Framework\TestCase;
final class MyTest extends TestCase
{
}
Para ejecutar tus tests puedes utilizar el comando ./vendor/bin/phpunit MyTest.php y obtendrás una salida como:
PHPUnit 11.4.4 by Sebastian Bergmann and contributors.
Runtime: PHP 8.4.1
There was 1 PHPUnit test runner warning:
1) No tests found in class "MyTest".
No tests executed!
Bastante razonable ¿no? Al fin y al cabo, se ha definido un TestCase pero ningún test dentro. Corrijamos eso.
Por convención, PHPUnit entenderá que cualquier método de una clase TestCase cuyo nombre comience por test debe ser ejecutado por él, es decir, lo próximo que deberías hacer es agregar un método como este:
<?php declare(strict_types=1);
use PHPUnit\Framework\TestCase;
final class MyTest extends TestCase
{
public function testSomething(): void
{
}
}
Al ejecutar este test verás algo como:
PHPUnit 11.4.4 by Sebastian Bergmann and contributors.
Runtime: PHP 8.4.1
R 1 / 1 (100%)
Time: 00:00.003, Memory: 8.00 MB
There was 1 risky test:
1) MyTest::testSomething
This test did not perform any assertions
/home/mauro/phpunit-poc/MyTest.php:6
OK, but there were issues!
Tests: 1, Assertions: 0, Risky: 1.
Es decir, se ha ejecutado un test, sólo que este test no ha verificado nada, es decir, no hay realizado ningún assertion.
Para que efectivamente aporte algo de información, dentro del cuerpo del test debe utilizarse alguno de los métodos assert* que provee phpUnit, por ejemplo:
<?php declare(strict_types=1);
use PHPUnit\Framework\TestCase;
final class MyTest extends TestCase
{
public function testSomething(): void
{
$this->assertTrue(true);
}
}
Y ahora sí, llegarás a una salida algo más parecida a lo deseable:
PHPUnit 11.4.4 by Sebastian Bergmann and contributors.
Runtime: PHP 8.4.1
. 1 / 1 (100%)
Time: 00:00.003, Memory: 8.00 MB
OK (1 test, 1 assertion)
Por supuesto que este test en la realidad no aporta mucho. Depende de vos hacer tests que sean relevantes para tu aplicación.
Ejemplo de un test con PHPUnit
Veamos un ejemplo algo más realista de lo que se puede hacer con phpUnit.
Imaginemos que tienes una función que, recibe una lista de números de teléfono y una lista de prefijos y retorna aquellos que comienzan por alguno de los prefijos indicados por el segundo argumento.
PHPUnit ofrece una cantidad de posibilidades realmente interesante pero, para no marearte con todo al comienzo te recomiendo continuar aprendiendo sobre dobles de test y sobre la configuración de phpUnit.
Pero… como todo en esta vida, la tecnología evoluciona y, para qué usar una herramienta menos potente cuando podríamos usar una más moderna, ¿no?.
Salvo que tengas muchas ganas de aprender algunas cosas y prefieras hacerlo todo a pulmón como hice yo en este repositorio (Bueno, en rigor de verdad no empecé de 0, usé unas cuantas librerías de Symfony y alguna otra cosita como Swagger-PHP para generar la documentación de OpenAPI pero aún así… le puse algunas horas de coding).
Ahora bien, si lo tuyo es ir directo a lo rápido y seguro no hay muchas dudas: API-Platform es lo que buscás.
Se trata de un framework basado en lo mejorcito que hay ahí afuera, se trata de definir tus modelos y… no mucho más.
Una API crocante en 10′.
Vamos por pasos:
Instalar el framework
Bueno… un pequeño pasito antes es instalar Docker y docker-compose, pero seguramente ya lo hiciste.
No te preocupes si ve un aviso algo tenebroso como este:
Nadie te está por robar todo el dinero de tu cuenta, simplemente se trata de que estás usando https para entrar a tu propio localhost y el browser no acepta el certificado autofirmado.
{
"@id": "/validation_errors/c1051bb4-d103-4f74-8988-acbcafc7fdc3",
"@type": "ConstraintViolationList",
"status": 422,
"violations": [
{
"propertyPath": "faction_name",
"message": "This value should not be blank.",
"code": "c1051bb4-d103-4f74-8988-acbcafc7fdc3"
}
],
"detail": "faction_name: This value should not be blank.",
"hydra:title": "An error occurred",
"hydra:description": "faction_name: This value should not be blank.",
"type": "/validation_errors/c1051bb4-d103-4f74-8988-acbcafc7fdc3",
"title": "An error occurred"
}
Control de acceso
El control de acceso se puede implementar de forma muy sencilla también: a través de la propiedad security del atributo #[ApiResource].
Basta con cambiar el encabezado por:
#[ApiResource(security: "is_granted('ROLE_USER')")]
class Faction
A la hora de desplegar la recomendación es usar el mismo docker compose que trae el framework. ¿Tenés dudas sobre este punto? Acá tenés un recurso que puede ser interesante.
Pues aquí bastará con tener algún servidor donde desplegar (Mi recomendación aquí es usar un sencillo Droplet de DigitalOcean), instalarle docker y crear un contexto especial, de modo de terminar lanzando un comando tipo:
docker compose -c prod docker-compose.yml up -d --wait
Ah! Casi olvido un detalle importante: modificar el archivo .env para que diga APP_ENV=prod en lugar de APP_ENV=dev.
Y listo. Bueno, luego vendrá, si corresponde, mover el DNS y demás pero eso será igual se trate o no de una API.
Qué más se puede hacer con API-Platform
La verdad es que mucho, pero no puedo meter todo en un único post.
Dejo algunas cosas que me parecen sumamente interesantes para que las investigues:
Scaffolding de clientes
Comunicación en tiempo real a través de Mercure
Generación de los modelos a partir de especificaciones OpenApi
¿Te convencí? Dejame tus preguntas en los comentarios.
Hace unos años, montar un entorno de desarrollo para una aplicación web PHP era una verdadera molestia:
Primero era necesario instalar Apache, luego MySQL, después configurar todo para que el Apache pudiera procesar correctamente los archivos PHP y generar la salida esperada, pasando en el medio por la configuración de MySQL y rogar que todo funcionara bien.
Y así pasábamos los días hasta que llegó XAMPP.
Qué es XAMPP
XAMPP fue, en su día, una verdadera revolución: un paquete único que contenía todo lo que podíamos necesitar para desarrollar cómodamente: click aquí, click allí y listo, a programar se ha dicho!
Si bien XAMPP simplicaba, y mucho, el montaje de un entorno local, en el fondo no se trataba de algo esencialmente diferente de lo que veníamos haciendo hasta el momento… sólo que mucho más rápido y cómodo.
El problema empezó cuando muchos programadores comenzaron a usarlo como si se tratara de una solución mágica y dejaron de lado comprender qué es lo que estaba ocurriendo tras bambalinas.
Craso error.
Error que se hace patente a la hora de subir el sitio al hosting. Es entonces cuando empiezan los problemas como:
Tengo este código que en localhost funciona perfectamente, que recibe los datos enviados mediante un formulario y saca los resultados mediante una tabla que se rellena automáticamente según los datos enviados. Resulta que cuando lo subo al servidor (hosting) no funciona y no da ningún tipo de error, simplemente no dibuja la tabla.
O:
tengo una pagina en php, en el servidor local funciona bien, es un login que al ingresar los datos dirige a una parte especifica de la web dependiendo el perfil, ahora si subo esto a mi hosting funciona perfectamente, pero si subo la web a otro dominio al ingresar los datos del login se queda la página en blanco. Ya intente que mostrara errores pero no me sale nada.
Hace algunos años habría recomendado usar máquinas virtuales para desarrollar. Hoy por hoy, existiendo Docker hay un nuevo ganador.
Qué es Docker
Docker es, ante todo, una plataforma de ejecución de aplicaciones basada en el concepto de contenedor.
La idea, muy resumida, es tener una única unidad (un paquete) que contenga en sí mismo todo lo necesario para ejecutar una aplicación.
De este modo, nos olvidamos de las pequeñas sorpresas que pueden encontrarse al llevar a un hosting un proyecto desarrollado en forma local.
¿Puede usarse Docker para desarrollos PHP?
¡Claro que sí!
Existen varias formas diferentes de usar Docker en proyectos PHP. En general, lo que se necesitará será una imagen que incluya el intérprete de PHP y, si se trata de una aplicación web, también un servidor.
XAMPP vs. Docker
Recapitulando un poco, como para que quede claro: XAMPP es un paquete de software específicamente diseñado para PHP, mientras que Docker es un sistema de manejo de contenedores genérico, es decir, no sólo puede usarse para PHP si no para cualquier lenguaje.
Por otro lado, con Docker es sumamente sencillo tener, en una misma máquina física, muchos procesos PHP corriendo diferentes versiones. Te reto a que intentes eso con XAMPP.
La desventaja, por llamarle de algún modo, de usar Docker en lugar de XAMPP es su dificultad para montarlo. Claro que, una vez que lo domines ésta desaparecerá.
¿Cómo reemplazar XAMPP por Docker?
Para reemplazar XAMPP por Docker se requiere contar con una configuración de Docker que incluya los servicios que XAMPP contiene (Además del propio Docker instalado localmente, claro).
Olvidarse del «te juro que en mi casa andaba!» es una bendición.
Claro que, para poder desplegar, primero hay que desarrollar. Y desarrollar implica, claro está, debuggear.
En PHP no contamos con un debugger incorporado a nuestros IDEs… afortunadamente existe XDebug.
El problema, sin embargo, suele ser la configuración que depende de dos factores que deben combinarse:
La instalación y configuración del lado del servidor.
La configuración del IDE para poder utilizarlo.
Existen muchas combinaciones posibles para realizar esta tarea, cada una con sus pequeñas particularidades. En este artículo me enfocaré en una de las combinaciones más populares por estos días:
VSCode sobre Ubuntu con un WebServer montado en Docker.
Lo que se necesita es agregar la definición del mapeo de directorios, desde el local al del servidor.
En este caso, el directorio en el servidor (en el contenedor Docker) es /var/www/html/, el cual debe ser conectado con el directorio app dentro de la raíz del proyecto.
Para usar el directorio del host, sin hardcodearlo, es posible usar la variable de VisualStudio workspaceFolder la cual contiene el directorio raíz del proyecto.
De modo que la configuración quedará de esta forma:
Venís trabajando sin descanso en una aplicación muy importante para entregar a un cliente.
Vas a buen ritmo, vas a llegar a la entrega sin mucho problema.
De pronto, te aparece la notificación de actualizar el sistema operativo y pensás: «Y… la verdad que no estaría mal… no puedo seguir toda la vida con la 1.0…».
Le das aceptar y, luego de unos minutos, cuando todo terminó te das cuenta de que la aplicación que andaba perfecta dejó de funcionar.
¿Eh?
¿Cómo puede ser?
Así como instintivamente tirás un php -v y comprobás que de 7.4 saltaste sin escalas a 8.1… y las cosas ya no son como antes.
¡Qué problema! Menos mal que es una situación hipotética ¿no?
Pues… no tanto. Esta historia es una adaptación libre de esta conversación que leí recientemente:
«se me actualizo php a la version 8 en Manjaro, y por ende se me descuadró todo, qué tengo que cambiar en el httpd.conf para que me funcione php8«
«Soy usuario de manjaro y me pasó lo mismo.Pero por suerte tenia dockerizado mis proyectos y no sufrí demasiado, deberías considerarlo«
Yo diría que suerte habría sido no tener que enfrentarse al problema.
Tener tus proyectos php dockerizados no es suerte, es una decisión.
Pensando un poco en esto empecé a preguntarme: ¿Cualquier aplicación php se puede dockerizar?
Qué significa dockerizar una aplicación PHP
Cuando se habla de dockerizar (me encanta este verbo) una aplicación, se hace referencia a hacer las adaptaciones necesarias para poder correrla sobre contenedores docker, tanto en un etorno de desarrollo como en uno de producción.
Estos ajustes dependen en gran medida de la naturaleza de la aplicación pero, a rasgos generales, se trata de:
Crear un Dockerfile (O al menos seleccionar una imagen pre-existente que sea compatible con las necesidades de la aplicación)
Cambiar, si las hubiera, referencias a localhost por otras que apunten a servicios dentro del ecosistema de docker
Crear una configuración de inicio de los servicios (Ya sea a través de Makefiles o similar o, mejor aún, a través de un archivo docker-compose)
En principio creo que no hay mucho más, pero si te parece que me olvidé de algo importante, por favor dejame un comentario abajo.
Qué se necesita para dockerizar una aplicación PHP
Para dockerizar una aplicación PHP se necesita, primero que nada, contar, tanto en local como en producción, con el motor y el cliente de docker.
Si se pretende usar docker-compose, también deberá estar presente en ambos lados.
Más allá de eso, es conveniente contar con un buen IDE, aunque no es imprescindible.
Técnicamente no se necesita nada más. Claro que saber lo que se está haciendo ayuda mucho.
Cómo dockerizar una aplicación PHP
Teniendo todo en su lugar el proceso es simple, aunque, dependiendo de la aplicación, puede ser más laborioso que en otros casos.
Relevamiento
Lo primero es entender cuáles son las dependencias:
¿Qué versión de PHP usás en producción?
¿Qué extensiones de PHP necesitás instaladas y habilitadas?
¿Qué otros servicios de infraestructura se usan con tu aplicación? ¿MySQL? ¿Redis?
¿Qué versiones?
¿Cómo está la configuración del webserver?
¿Cómo está la configuración de PHP?
¿Qué permisos sobre archivos necesita la aplicación para funcionar?
Con las respuestasa a estas preguntas podrás darte una idea de lo que requerirás en tu imagen docker.
Instalación de las herramientas
Si no las tienes disponibles, el próximo paso será instalar las herramientas necesarias (docker engine, docker client y docker-compose al menos).
Adaptación de la aplicación
Luego deberás preparar la aplicación:
Reemplazar referencias a servicios externos (Bases de datos, colas de mensajes, etc…) de IPs o nombres conocidos en el host a nombres conocidos dentro de la red de Docker
Reemplazar rutas absolutas por relativas
Reemplazar enlaces simbólicos por archivos concretos
Creación de los archivos de Docker
Es muy probable que tu aplicación tenga algunos requisitos específicos que no encuentres en una de las imágenes disponibles en el dockerhub. No te preocupes, siempre podés tomar una imagen lo más parecida posible a tus necesidades para usar como base y agregar tus cambios particulares.
Si el sistema es suficientemente complejo (si requiere de otros componentes de infraestructura), es conveniente definir también un archivo docker-compose.yml para mayor comodidad.
Pruebas y ajustes
Una vez hayas pasado por los pasos anteriores será cuestión de probar la aplicación y validar que todo funciona.
Los comandos exactos dependerán de cómo hayas armado los archivos de configuración, pero será algo así como:
docker build . -t mi_php
docker run -it mi_php
O, si usas docker-compose:
docker-compose up --build
Una vez estén levantados los servicios podrás entrar a http://localhost:8000 (Asumo que el puerto 8000 está mapeado al 80 en el contenedor) y ya podrás verificar que toda la aplicación funciona.
Por qué dockerizar tus aplicaciones php
Si te parece mucho trabajo, tenés razón, dockerizar una aplicación PHP puede ser molesto, especialmente cuando lo tienes que hacer por primera vez pero, si queda bien, es muy probable que no tengas que volver a hacerlo por mucho tiempo y, a la vez, tu aplicación quedará blindada ante cambios en el ambiente, tanto local como de producción.
Me llegó esta pregunta que me pareció interesante compartir:
Estoy usando PHPStorm, y como sólo me pide el intérprete cuando trato de ejecutar en el navegador, todavía no lo he instaldo, quisiera saber si ya es mejor instalar el Xampp, si es recomendable y en caso de que no lo sea ¿por que?
Por si no sabés de qué se trata XAMPP, es un paquete que trae, todo lo que típicamente se requiere para desarrollar con PHP:
Necesitás trabajar con diferentes proyectos a la vez.
Son estos los momentos en te das cuenta que el salvavidas estaba hecho de plomo.
Cuál es el problema con XAMPP
La sencillez que aporta XAMPP lo hace la opción más difundida entre los desarrolladores menos experimentados. Pero esa sencillez tiene un costo.
El primero de los problemas es que, al ocultar la complejidad real que implica montar un servidor, se propicia el efecto «¡Te juro que en mi casa andaba!». Como no sabés realmente qué tenés instalado es difícil verificar que el hosting tenga lo mismo (Más detalle de qué es exactamente lo que deberías mirar acá).
El segundo de los problemas es que hace muy difícil trabajar en diferentes proyectos donde cada uno tiene requerimientos de infraestructura diferentes (Por ejemplo, versiones diferentes del intérprete de PHP).
Por supuesto que, si sos conciente de estas limitaciones y sabés trabajar con ellas XAMPP puede ser una opción aceptable.
Qué usar en lugar de XAMPP
Las opciones son varias, hay algunas mejores que XAMPP y otras peores:
En general, docker es la mejor opción cuando se trata de montar entornos locales ya que es muy simple luego llevarlos a producción y/o compartir con tu equipo.
Pero bueno, es cierto también que dominarlo no es una tarea muy sencilla.
Si recién estás empezando (Y quiero decir que apenas estás dando tus primeros pasos), está bien que uses XAMPP pero es importante que tengas la idea de migrar lo antes posible.
Todo lo que querías era hacer una prueba sencilla. Como para comprobar por tus propios medios, si todo lo que te dijeron de Docker era realmente así y en cambio… tenés que ponerte a escribir archivos de texto inentendibles.
Te tengo buenas noticias: hay varias herramientas muy simples que podés usar para generar los dichosos Dockerfile.
Te presento algunas.
Devilbox
http://devilbox.org/ te permite crear un entorno moderno y altamente personalizado con soporte para LAMP sobre docker.
Su instalación es sencilla:
git clone https://github.com/cytopia/devilbox
cd devilbox
cp env-example .env
docker-compose up
Y listo.
En tus manos un LAMP con Redis, Memcached, MongoDB, phpMyAdmin y un montón de herramientas de administración disponibles en http://localhost para hacer todo bien fácil.
Ah, y claro, si querés ver qué hay detrás de la magia, el archivo docker-compose.yml está a tu disposición en el directorio donde clonaste el repo.
PHPDocker
https://phpdocker.io/ es un sitio donde podés, a través de un wizard, configurar la imagen Docker que querés generar:
Una vez tenés todo donde debe estar descargás el archivo comprimido, lo descomprimís en el directorio que más te guste, docker-compose up y, voilá, tu entorno php Dockerizado está disponible con todos los condimentos que hayas seleccionado.
Sail
Sail es una herramienta perteneciente al framework Laravel. Si creas una nueva aplicación desde cero no tendrás más que ejecutar ./vendor/bin/sail up dentro del directorio raíz de tu proyecto para comenzar.
Una vez descargado y configurado todo podrás entrar en http://localhost y disfrtuar de tu nuevo entorno de trabajo con Docker.
Y, como siempre, el archivo docker-compose.yml estará allí para investigar/modificar.
Y un par más…
Un par de herramientas más que vale la pena conocer son:
Deck: una aplicación de escritorio basada en electron.js con la que puedes crear un ambiente entero para desarrollo. La iba a incluir en este listado pero al probarla falló la instalación… tal vez más adelante cuando esté más madura la agregue.
Después de horas frente a la pantalla, incontables tazas de café y miles de bugs resueltos, por fin llegará el merecido descanso… sólo falta hacer la demo para el cliente.
Es que si no se hace el cliente no podrá dar su visto bueno y sin él… difícil que haga el último pago :p
Podrías hacer un despliegue completo en su servidor pero… ¿y si algo sale mal?
O peor, ¿qué tal si sale todo bien y el código ya está fuera de tu control?
¿Cómo hacer para que otra persona vea tu trabajosin entregarle el código?
Existen varias opciones según cuál sea tu modo de trabajar.
Para este artículo asumiré que desarrollas en un servidor local (XAMPP o similar).
Usar un servidor de pruebas
Una opción perfectamente válida es utilizar un servidor intermedio en el cual puedas desplegar tu código.
Idealmente este servidor será tuyo, con lo cual no tendrás que entregar tu código en forma prematura.
La principal desventaja de este método es que puede tener un costo asociado: el del hosting.
Por otra parte, preparar este espacio puede no ser una tarea trivial y hacerlo cada vez que tengas que realizar una demostración puede ser una pérdida de tiempo significativa.
Abrir temporalmente el acceso a localhost
Otra opción que puede resultar mucho más económica y sencilla es abrir temporalmente el acceso a tu computadora a través de internet.
Existen diversas herramientas que puedes utilizar para asociar un nombre de dominio a tu dirección IP, de modo de evitarle a tu cliente tener que tipearla en su navegador.
No es una mala opción, aunque puede ser un poco compleja de administrar (amén de requerir la instalación y ejecución constante de un cliente).
Otra posiblidad bastante más atractiva es utilizar ngrok.
Se trata de una utilidad muy sencilla que te permite levantar un túnel hacia tu computadora y pasarle a tu cliente una URL a la cual conectarse.
Basta con ejecutar un comando como ngrok http 80 para obtener una pantalla como esta:
Información de ngrok ejecutándose
Aquí puedes ver claramente cómo la dirección http://7da0fd4f278a.ngrok.io apunta al puerto 80 en mi computadora local.
Sólo se necesita ingresar a http://7da0fd4f278a.ngrok.io para ver lo mismo que yo veo usando http://localhost.
No está mal, ¿cierto?
Nada de FTP, nada de crear servidores temporales ni cosas parecidas.
¿Lo más interesante? Al terminar la prueba sólo se necesita dar Ctrl+C y asunto finalizado.
Terminó la demo y terminó el acceso remoto.
Simple, rápido y económico (o BBB si lo prefieres :))
Adelante, la próxima demo que vayas a hacer no te compliques, crea ahora mismo una cuenta en ngrok, configura el cliente y olvídate del problema de los despliegues temporales
Apuesto que te habrás topado con la necesidad de emitir reportes en PDF alguna vez, ¿cierto?
Por ejemplo para generar facturas electrónicas.
De por sí es un tema integrarte con los webservices del fisco (Léase AFIP, SUNAT, DGI, DIAN, etc…) y cuando pensás que todo está resuelto, te encontrás con que falta subir otra colina más: generar los benditos pdfs.
Seguro habrás pensado:
«Tiene que haber una librería que permita hacer pdfs con PHP»
Y tenés razón… y a la vez no.
¿Cómo?
Pues… es que no existe una librería si no unas cuantas… y las diferencias entre una y otra no siempre están disponibles a simple vista.
Casi podríamos decir que elegir la librería para generar pdfs es un proyecto en sí mismo.
Así que, para ayudarte a tomar esta decisión te voy a presentar un cuadro con las opciones más conocidas y sus características principales para que puedas analizarlas en conjunto y elegir la más conveniente para tus circunstancias particulares.
Comparativa entre librerías para hacer PDF con PHP
Si estás en un ambiente de hosting compartido lo principal es verificar si la versión qué versión de php tienes y qué extensiones están disponibles.
Luego debes entender qué buscas priorizar: la facilidad de implementar la librería o la eficiencia en el uso de los recursos.
La mejor librería para generar PDFs de alto contenido gráfico
Si necesitas generar PDFs con grandes detalles gráficos (Inclusión de imágenes de fondo por ejemplo), lo más probable es que te convenga inclinarte por una librería simple como domPDF, mPDF o html2pdf.
El problema que tienen estas librerías es que se vuelven poco eficientes cuando se trata de generar muchos archivos en poco tiempo.
La librería más rápida para generar PDFs con PHP
Si el principal requisito de tu aplicación es la velocidad de procesamiento tu mejor opción es PDFLib.
Dado que se trata de una extensión de php, su velocidad difícilmente pueda ser superada por algún competidor escrito en PHP.
Claro que esta velocidad viene con un precio: se trata de una librería paga y, si estás en un ambiente de hosting compartido, puede ser complejo instalarla.
Otras herramientas para generar PDF desde PHP
Algunas otras herramientas que, si bien no son exactamente librerías de php, pueden servirte para generar PDFs en tus aplicaciones:
Como puedes ver, la elección de la herramienta ideal no es sencilla pero vale la pena hacer un poco de investigación y, sobre todo, comprender la necesidad específica para determinar cuál es la opción más conveniente.
Coméntame cómo ha sido tu experiencia y qué tuviste en cuenta para elegir la librería que usaste 😉
