Bucles en PHP: do, while, foreach y for

Hoy vamos con una lección de PHP básico: el uso de los distintos bucles existentes en este lenguaje de programación. Esencialmente tenemos cuatro bucles, por lo que no es muy difícil aprendérselos. Lo curioso es que muchas veces la gente hace un mal uso de ellos, os lo digo yo que en los últimos meses casi he trabajado más sobre código de otros (plugins de CMS, terminar trabajos a medias) que creando el mío.

Empezamos por el bucle for. Este debe usarse cuando queremos ejecutar una instrucción o bloque de instrucciones un número conocido de veces. Es decir, si sabes que tienes que repetir una instrucción exactamente, por ejemplo, diez veces entonces usa for. La sintaxis sería for(inicialización; condición de terminación; incremento) pero mejor te la explico en un ejemplillo:

for($i=0; $i<10; $i++){
    echo 'Voy a imprimir esto 10 veces y esta es la '.$i;
}

Es habitual ver a programadores usando el for de forma abusiva e inadecuada.

El siguiente bucle a comentar será el while. En este caso el código de este bucle se ejecuta si una condición dada es cierta y se repite mientras esta sigue siendo cierta. Es decir, si no se da la condición antes de entrar ya no se ejecuta, y se se entra se hará hasta que la condición deje de darse, evaluándola en cada iteración. Debemos usar este bucle cuando no sepamos con exactitud la cantidad de veces que tiene que ejecutarse el bucle, pero sí el valor que queremos alcanzar. La sintaxis es while(condición). Un ejemplo:

<?php
$i=0;
$precio = 50;

while( $precio < 5000)
{
   $precio*2;
   $i++;
}
echo ("Hemos doblado el precio  ".$i." veces hasta superar los 5000");
?>

Parecido, pero no igual, es el bucle do-while. La diferencia es que este se ejecuta siempre al menos una vez, aunque la condición de salida no se cumpla a la entrada. Es decir, en el ejemplo anterior entró en el bucle porque la variable precio era menor de 5000, pero en caso de un do-while habría entrado y ejecutado el código al menos una vez aunque hubiéramos inicializado la variable con un valor superior a 5000. La sintaxis es do{código}while(condición). Veamos un ejemplo simple donde lo diferenciamos del while:

$i=5;
while($i<4)
{
   echo 'Esto no se va a imprimir porque no va a entrar';
}

do
{
    echo 'Aunque la condición es la misma, esto se imprimirá al menos una vez';
}while($i<4);

Finalmente tenemos el foreach, pensado para iterar dentro de arrays. En este bucle lo que hacemos es recorrer todos los elementos de un array. La sintaxis es foreach(array as valor). Es el bucle que debemos utilizar siempre para este propósito. Un ejemplo donde imprimimos los nombres de una serie de frutas:

$frutas = array('melón','limón','fresa','manzana');
echo 'Existencias:'
foreach($frutas as $fruta){
   echo $fruta;
}

Con esto ya estarían repasados los cuatro bucles. Existen, además, dos sentencias que pueden usarse para romper/modificar el flujo natural del bucle: break y continue.

La sentencia break fuerza la salida de un bucle, saltando a la siguiente línea tras el mismo. Su uso natural es para las condicionales switch/case, si bien a veces se ve dentro de bucles. Por cuestiones de elegancia y comprensión del código se recomienda no usarlo. El ejemplo sería:

while( $i < 10)
{
   $i++;
   if( $i == 5 )break;
}

En cuanto a continue se utiliza con un condicional antes y lo que hace es saltarse las instrucciones cuando se cumpla esa condición, pero sin salir del bucle. Por ejemplo imaginemos que queremos recorrer una serie de números pero imprimir sólo los pares:

$i=1;
while($i<10)
{
  if($i % 2 != 0) continue;
  echo $i;
}

El código del ejemplo no haría nada cuando se cumpliera la condición, y cuando no se cumpliera imprimiría el valor.

En fin, con esto ya damos por terminada la lección sobre bucles en PHP. Espero que haya sido de ayuda a alguien. Y recordad, usad cada bucle cuando sea necesario, no de forma indiscriminada.

PHP prepared statement (consulta parametrizada) con MySQLi

Si bien en el pasado ya vimos como hacer una consulta parametrizada en este blog de una forma primitiva (fue un artículo antiguo y a día de hoy no lo haría así ni lo recomiendo, por lo que quedaos con este) o haciendo uso de PDO, toca ahora ver cómo hacerlo con MySQLi.

¿Por qué usar MySQLi y no PDO? En fin, todo depende del caso. PDO nos permite abstraernos del SGBD, con sólo cambiar un parámetro en la creación nuestro código funcionará en Postgres, MySQL, Oracle… MySQLi, en cambio, sólo funciona con MySQL. En principio parece que no hay ningún motivo para usar MySQLi, pero si nos metemos en temas de rendimiento veremos que MySQLi va a penalizar menos el rendimiento de la página que PDO. Es decir, trabajando con MySQL nuestra web requerirá menos recursos usando MySQLi que PDO. Si por lo que sea estás con un proyecto que estás seguro de que no a tener que migrarse de SGBD, si sabes positivamente que se va a usar MySQL durante mucho tiempo, entonces MySQLi es tu opción.

Entonces ¿cómo hacemos una consulta parametrizada con MySQLi? Bueno, veamos como se hace una SELECT que recogería unos datos de la BD vinculados a un id del que disponemos en nuestro PHP?


$mysqli = new mysqli ("servidor", "usuario", "password", "nombre_base_de_datos"); //creamos el objeto MySQLi<code>
</code>

if($mysqli->connect_errno){ //comprobamos que no haya errores de conexión

die( 'La cagaste, esto no va'); //mensaje de error

}

if(!$prepared_st = $mysqli->prepare("SELECT * FROM tabla WHERE id = ?")){//creamos el statment y controlamos los errores

die("La cagaste again"); //mensaje de error

}

&nbsp;

//ahora toca vincular el parámetro id a la consulta

$id=5;

if(!$prepared_st->bind_param("i",$id)){ //vinculamos el parámetro

die("Fallito en la vinculación");

}

if(!$prepared_st->execute()){//ejecutamos la consulta

die("Fallo en la ejecución");

}

$resultado = $prepared_st->get_result(); //recogemos resultado

$prepared_st->close(); //cerramos el prepare

$mysqli->close(); //cerramos la conexión a la base de datos

Bueno, toca una pequeña explicación de bind_param: como veis en este caso recibe dos parámetros. El primer parámetro de bind param siempre es una cadena donde le pasamos una serie de letras que identificarán los tipos de datos que le vamos a proporcionar luego con las variables. Es decir, en el ejemplo le decimos primero que le va a llegar un entero, y luego pasamos la variable de ese entero. Si quisiéramos pasar un entero y una cadena (en se orden) el primer parámetro sería «is» y luego irían la variable entera y la variable cadena. El orden es fundamental.

Finalmente recogemos el resultado (para usar get_result() tienes que tener instalada la extensión mysqlnd, si no tendrás que usar bind_result()), que podemos convertir a array con las funciones fetch_array o fetch_assoc según convenga. En cualquier caso en la web de php.net tenéis más información con la que trabajar. Para el resto de operaciones CRUD la cosa va siendo similar: consulta, vinculamos parámetros, ejecutamos, recogemos resultado si procede.

Configurar servidor Apache para que nos muestre los errores de nuestro PHP

Un poco de sistemas y un poco de PHP mezclado en esta entrada, porque aunque sean tareas muy básicas no está demás comentarlas.

Lo primero es decir que esto NUNCA debe hacerse en un servidor de producción, JAMÁS. Es decir, esta configuración es una ayuda para el programador, por lo que lo recomendable es hacerlo en el servidor de desarrollo/local. Mostrar los errores en producción supondrá una debilidad en la seguridad de la página, así que recuerda: Sólo para desarrollo.

Apache Foundation

Una vez dicho esto, comentar también que si instaláis Apache en un servidor Linux, o si utilizáis XAMPP en Windows, por defecto vendrá con la detección de errores desconectada. En ese caso si tenéis un fallo se mostrará una página en blanco. Este es el comportamiento adecuado en producción, pero en vuestro equipo de desarrollo lo más cómodo es que os muestre el error y en qué línea se ha detectado.

Para cambiar la configuración tenéis que iros a buscar el archivo de configuración de PHP (php.ini), que en Ubuntu por defecto está en etc/php5/apache2/php.ini y en XAMPP podéis acceder a él desde el panel de control principal. Si no lo encontráis basta con que hagáis una página que imprima la función phpinfo() y ahí veréis la ruta completa al archivo (aparece como Loaded Configuration File).

Una vez abierto el archivo con un editor de texto os vais a buscar la instrucción display_errors, que estará por defecto en Off y la cambiáis por On. Vamos que quedará display_errors = On y, tras esto, guardáis los cambios en el archivo. Tras eso reiniciáis el servicio (en XAMPP desde el panel, en Ubuntu con sudo/etc/init.d/apache2 restart) y ya debería estar cantándoos los errores. En todo caso, ejecutad un script con algún fallo que sepáis dónde está (tipo dejaros fuera una coma en la primera fila o un paréntesis sin abrir) para ver que todo funciona correctamente.

Con esto habréis configurado ya vuestro servidor para que detecte los errores, lo que será una enorme ayuda a la hora de desarrollar páginas PHP.

El patrón Registry (y su aplicación en PHP)

Volvemos a los patrones de diseño tras un par de artículos de otra índole, y lo hacemos con Registry. La idea de este patrón es que nos permita utilizar los objetos y variables registrados en cualquier nivel de la aplicación sin necesidad de duplicarlos. Es decir, en la práctica nos permitiría usar cualquier objeto como si fuera un Singleton.

La idea de este patrón es crear una clase que tenga un array donde guardar los objetos registrados y una serie de métodos: uno que añada los objetos al array, otro que compruebe su existencia para evitar duplicaciones, otro que devuelva el objeto pasándole su clave, uno que borre el objeto recibiendo la clave y finalmente uno que limpie el array de la clase.

Pasado a código, PHP como siempre, la estructura sería la siguiente:

    <?php      
    class Registry  
    {  
        /** 
         * Registra variables y objetos         
         */  
        static private $registry = array();  
      
        /** 
         * Método que añade objetos
         * Recibe el objeto (por referencia) y la clave
         * Devuelve un booleano para confirmar si se ha insertado
         * o si en cambio estaba duplicado.
         */  
        static public function add($key, &$elemento)  
        {  
            if (!self::exists($key)) {  
                self::$registry[$key] = $elemento;  
                return true;  
            } else {  
                return false;  
            }  
        }  
      
        /** 
         * Función que comprueba la existencia de una clave.
         * Devuelve un booleano confirmando si existe o no.
         */  
        static public function exists($key)  
        {  
            return array_key_exists($key, self::$registry);  
        }  
      
        /** 
         * Función que devuelve un item dada la clave          
         */  
        static public function get($key)  
        {  
            if (self::exists($key)) {  
                return self::$registry[$key];  
            } else {  
                return null;  
            }  
        }  
      
        /** 
         * Elimina una entrada recibiendo su clave y devuelve confirmación.
         * Si la clave no existe devuelve false.
         */  
        static public function remove($name)  
        {  
            if (self::exists($name)) {  
                unset(self::$registry[$name]);
                return true;  
            } else {
                return false;
            }  
            
        }  
      
        /** 
         * Limpia el registro totalmente.         
         */  
        static public function clear()  
        {  
            self::$registry = array();  
        }  
    }  
    ?>  

El ejemplo es una estructura muy básica, puedes ampliarlo con filtros varios, control de errores y demás, pero la idea del esqueleto de este tipo de clase.

Ale, a disfrutarlo.

Patrón MVC y PHP

Cierto es que este mes he estado poco activo en cuestiones bloggeras, pero ya me tenéis de vuelta con el tema de los patrones de Diseño, en este caso con el popular MVC (Model/View/Controller o Modelo/Vista/Controlador).

La idea del patrón MVC es separar en tres capas los datos (model), la interfaz de usuario (view) y la lógica de negocio (controller). Esto permite una mayor reutilización de componentes, facilita la modificaciones del aspecto del programa/web sin tener que tocar el funcionamiento y simplifica el mantenimiento. Funciona de forma «triangular», es decir, cada capa envía información a una y la reciba de la otra.

El modelo sería la representación de la información y se encargaría de gestionar el acceso, adición y modificación de los mismos (operaciones CRUD). A nivel de interacción con los otros componentes enviaría a la vista los datos que tienen que ser mostrados y recibiría desde el controlador las peticiones de acceso y manipulación.

La vista sería, como su nombre indica, lo que se ve en pantalla. Además de mostrar los datos al usuario le permite interactuar con ellos. La vista recibe del modelo los datos a mostrar y permite al usuario comunicarse con el controlador a través de sus objetos.

Finalmente el controlador, trabajaría como puente entre la vista y el modelo, recibiendo las peticiones del usuario a través de la primera, realizando las labores de transformación necesarias y realizando finalmente las peticiones al modelo.

Aunque el MVC nació originalmente (allá por los años 70) para aplicaciones de escritorio, el desarrollo de la web dinámica hizo que fuera adoptado como patrón para diseñar la arquitectura de muchos sitios web. Existen múltiples frameworks para diversos lenguajes que permiten implementar el MVC a la arquitectura web. En el caso de PHP hay gran variedad, pero desde aquí vamos a destacar cuatro de ellos, todos software libre:

  • Zend Framework: Dado que Zend es la empresa con más peso en el mundo de PHP, comenzaremos con su framework. He de decir que hasta la versión 1.9 existen muchas quejas al respecto de su rendimiento, pero a partir de la versión 2 se reescribió el código para lograr aligerarlo. Está bajo licencia BSD, por lo que su uso es cercano al dominio público.
  • Symfony: Creo que a día de hoy es el framework más utilizado en PHP. Funcional, ligero, productivo y bien estructurado, es utilizado por gran número de CMS  (destacando Drupal) y por empresas potentes. Está bajo licencia MIT.
  • Codeigniter: Un veterano, al menos según mi percepción porque fue del primero del que oí hablar. Por lo que se dice tiene menos funcionalidades que Symfony o Zend, pero a su favor juega con tener una mayor flexibilidad y menor peso. Menos productivo pero más adaptable. Su licencia es GNU/GPL.
  • CakePHP: Irrumpió con mucha fuerza hace un par de años, pero parece que al final no ha logrado desbancar a Zend y Symfony del trono, en parte porque se dice que tiene una curva de aprendizaje más pronunciada. Incluye funcionalidades para casi todo y está bajo licencia MIT al igual que Symfony.

Y con estos cuatro no se acaba, hay docenas de frameworks para PHP funcionales como Yii, ZanPHP (de esto no tengo muy claro su estado, porque la web oficial a día de escribir este artículo, aparecía como un dominio caducado, pero en GitHub sigue) o KumbiaPHP. En cualquier caso, la oferta es amplia y variada en ese sentido.

Sesiones en PHP: uso básico

A la hora de guardar los datos de navegación de un usuario de nuestra web el uso de sesiones se torna esencial. Las sesiones son una forma fácil y práctica de almacenar estos datos del usuario (los almacena en una cookie de sesión que gestionará el propio navegador), de forma individual, para trabajar con ellos.

La idea es simple: cuando llamamos a la función session_start() PHP comprueba si existe un ID de sesión, en caso negativo crea una sesión nueva y en caso afirmativo mantiene los datos de la creada. Con la sesión activa podremos utilizar la variable array superglobal $_SESSION para almacenar los datos que queramos relativos a la navegación. Piensa en el carrito de la compra de cualquier tienda on-line, que va almacenando los items que vas comprando hasta que haces el pago, creo que es el mejor ejemplo de cómo funcionan estas variables.

Vamos a ver un ejemplo donde creamos una sesión y almacenamos la hora de la última conexión y de la última acción:

@session_start(); //iniciamos la sessión

if(!isset($_SESSION["first_connection"])){ //comprobamos si existe la variable y si no, inicializamos
  $_SESSION["first_connection"] = time(); //asignamos a la variable la fecha de creación
}else{
  $_SESSION["lastAction"] = time(); //sobreecribimos la fecha de la última acción
}

Un ejemplo tonto, pero básico.

Para destruir una sesión, por ejemplo al pulsar un botón de logout, usaríamos la función @session_destroy(). Y para acceder al id de la misma la función @session_id() nos lo devolverá. Si queremos cargarnos una variable de la sesión sin destruir la sesión basta con usar la función unset(), más o menos como en el ejemplo que va ahora:

//AHORA QUEREMOS DEJAR DE ALMACENAR LA ÚLTIMA ACCIÓN
unset($_SESSION["lastAction"]);

Ni se os curra hacer unset($_SESSION) sin indicar variable para cargároslas todas, esto deshabilitará el registro de las variables del array y os romperá un montón la cabeza.

En fin, como siempre si queréis más ejemplos en la web de PHP podéis explorar sobre el uso de sesiones. Un saludo y que os sea provechoso.

El patrón de diseño Singleton (implementado en PHP)

Vamos con la entrada número 400 del blog, y la 200 de informática. Curioso, llegados a este punto de casi dos años bloggeando un tema que no era el principal ha acabado ocupando el 50% del contenido del blog.

En fin, seguimos con los patrones de diseño. El otro día hablaba del patrón Decorator, hoy vamos con el Singleton.

La idea del patrón Singleton, también llamado de instancia única, es restringir la creación de objetos pertenecientes a una clase a sólo uno. Garantiza que sólo hay una instancia y proporciona un único punto de acceso.

La idea es que la clase tenga un constructor privado para que no pueda ser accedido desde fuera de la clase y que aunque haya clases hijas estas no puedan instanciar objetos. También debe tener una propiedad estática privada donde almacenaremos nuestra instancia y un método estático que sea el punto de acceso global a la misma, devolviéndola cuando se lo llama.

Vamos con el ejemplo típico y tópico del objeto de base de datos, que suele ser el uso más común de este tipo de clases. Porque crear varias instancias de acceso a una base de datos en la mayoría de los casos es un malgasto de recursos, lo mejor suele ser tener una sola instancia para realizar las conexiones.

class Database {
//Propiedad estática, inicializada a nulo, donde guardaremos la instancia de la propia clase
    static private $instance = null;
//Definimoms el método constructor como privado
    private function __contruct() {}
     
//Método estatico que sirve como punto de acceso global
    public static function getInstance() {
        if (self::$instance == null) {
//Si no hay instancia creada, lo hace. Si la hay tira p'alante
            self::$instance = new Database();
        }
//Al final devuelve la instancia
        return self::$instance;
    }
	     
 //a continuación ya meterías todas las funciones necesarias para un objeto de base de datos. CRUD, etc...
}

Y ya est… No, sorry man pero no. Con el código así todavía es posible que alguien logre hacer más de una instancia. Y te dirás ¿cómo? Pues porque todavía es posible usar la clonación y la serialización para lograrlo. Cosa mala, pero con los métodos mágicos de PHP5 podemos arreglarnos.

Para evitar la cuestión de la clonación definimos el método mágico __clone() en la clase, para que en lugar de permitir el clonado del objeto nos lance un error y detenga el script:

public function __clone()
{
  trigger_error("No puede clonar una instancia de ". get_class($this) ." class.", E_USER_ERROR );
}

Y vamos con el tema de la serialización y deserialización. Con la función serialize() se puede almacenar una representación apta de una variable (y una instancia de un objeto es, al fina, una variable) mientras que con unserialize() podemos acceder a ella como se si tratara de un clon. De nuevo hay que redefinir un método mágico, en concreto esta vez __wakeup(), que es el método que se invoca al deserializar un objeto. De esa forma se evita que pueda ser accedido. También podría hacerse con __sleep(), que es el que se invoca al serializar, pero veo más práctico evitar la deserialización.

public function __wakeup()
{
  trigger_error("No puede deserializar una instancia de ". get_class($this) ." class.", E_USER_ERROR );
}

En fin, he caído en el ejemplo tópico, pero también me pareció el más claro. Un saludo, disfruta este articulo 400.

El patrón de diseño Decorator (aplicado en PHP)

Iba a poner El patrón de diseño decorator en PHP pero dado que los patrones de diseño son independientes del lenguaje preferí poner un título más matizado. Aunque algunos parezcan empeñados en no usar patrones en PHP (a pesar de que desde PHP5 ya esté orientado a objetos) en un proyecto grande serán útiles.

El patrón Decorator se pensó para permitir herencia múltiple sin que el árbol de clases crezca de forma incontrolada. Permite añadir a un objeto funcionalidades de forma dinámica. Piensa en un juego de rol, piensa en cuando vinculabas una matriz de conjuros a un arma en Runequest… vale, es muy friki, pero lo voy a usar de ejemplo para explicar el patrón.

Imagina que haces un videojuego, inspirado en el antes citado Runequest mismamente. Entonces creas la clase espada, que hace 10 puntos de daño y tiene 20 puntos de armadura. Muy bien, ahora le vinculas un hechizo de armadura extra. Tendrías que crear la clase espada_armadura con 10 puntos más de armadura. Hasta ahí, bien: tienes la clase espada, y la clase hija espada_armadura que hereda de espada.

Ahora imagina que también le vinculas un hechizo que duplica el daño. Tendrías que crear la clase espada_daño, pero también la clase espada_armadura_daño, que sería la clase con ambos hechizos. Para dos funcionalidades has tenido que crear 3 clases hijas. Y ahora supón un tercer hechizo que mejora tu posibilidad de éxito un 100%: espada_éxito, espada_éxito_armadura, espada_éxito_daño, espada_éxito_daño_armadura… y las cuatro clases anteriores. Para tres funcionalidades ya vas en 8 clases, si haces el cálculo progresan en potencias de 2, por lo que para 4 funcionalidades tendrías 16 clases, para 5 32

El patrón Decorator nos permite evitar esto a base de delegar funciones. Vamos a poner un ejemplo práctico en PHP solucionando el problema anterior, explicado en los comentarios:


//interfaz arma, común a todas las armas
interface iArma{
  public function ataca();
  public function defiende();
}

//clase espada, que implementa la interfaz arma
class espada implements iArma{
  private $armor = 20;
  private $attack = 10;

  public function ataca(){
    return $this->attack;
  }
  public function defiende(){
    return $this->armor;
  }
}

//creamos la clase abstracta Decorator
abstract class espada_decorator implements iArma{
  protected $_espada;
  public function __construct(iArma $Espada){
    $this->_espada = $Espada;
  }
}

//ahora creamos la funcionalidad con más ataque
class extra_attack extends espada_decorator{
  public function ataca(){
    return $this->_espada->ataca()*2;
  }
}

//ahora la funcionalidad de más defensa
class extra_armor extends espada_decorator{
  public function defiende(){
    return $this->_espada->defiende()+10;
  }
}

//ahora podemos crear un objeto espada con la defensa extra
$espada = new extra_armor(new espada());

//y ahora añadimos el ataque extra
$espada = new extra_attack($espada);

Como puedes ver, de esta forma agregamos a nuestro objeto diversas funcionalidades, creando sólo una clase por funcionalidad en lugar del montón al que nos obligaría el ir creando clases para cara posible combinación.

Instalar Symfony 2.1 en Linux

Bueno, seguimos con el tema de Symfony tras el interludio papal. El caso es que comenzamos este tutorial donde dejamos el anterior ¿anterior? Sí, en cierto modo la entrada sobre instalar Composer sirve de introducción a esto.

En fin, la cosa es tener instalado Composer de forma global en tu equipo y GIT (aunque si te dedicas a programar seguramente ya lo tengas instalado), lo que ya se explicó en la entrada anterior. El caso es que con Composer instalado lo primero es ejecutar desde línea de comandos $ composer create-project symfony/framework-standard-edition directoriodelproyecto 2.1.x-dev obviamente cambiando directoriodelproyecto por el directorio que corresponda. Sin Composer ni GIT esto no furrulará, repito.

Una vez instalado prueba a situarte en el directorio donde has instalado y ejecutar $ php app/check.php, ahí verás la lista de requisitos que debe cumplir tu equipo para ejecutar Symphony. Luego si ejecutas desde ahí $ php app/console verás en la consola una lista con todos los comandos disponibles para las aplicaciones de Symfony 2.

Finalmente, puedes probar en tu navegador el funcionamiento de Symfony. Visita http://localhost/directoriodelproyecto/web/config.php (cambia directoriodelproyecto por lo que corresponda). Puede que te salga un mensaje de error, suele ser por cuestiones de permisos, nada que no se arregle trasteando con la configuración de seguridad.

Instalar Composer en Linux

¿Qué es Composer y por qué debería instalarlo? En fin, es la primera pregunta, desde luego. Composer es un gestor de dependencias para PHP, de uso común en los proyectos realizados con Symfony (sí, me he puesto a trastear con Symfony, aunque ando un poco pez). En todo caso, lo que Composer hace es comprobar la lista de dependencias de cada proyecto y decidir qué librerías hay que instalar, qué versiones de las mismas se instalan y en qué orden. Muy útil sobre todo cuando actualizas tu versión de Symfony, ya que te evita problemas de incompatibilidad con librerías antiguas.

En fin, vamos a meternos ya en harina. ¿Cómo instalo Composer en mi Linux? Bueno, no es muy difícil (no como en el caso de Windows donde es un puto coñazo, pero eso ya lo explicaré otro día). Tienes dos opciones, además: instalar Composer en un proyecto concreto o instalar Composer globalmente.

Para la instalación en un proyecto concreto, desde la consola de comandos sitúate dentro del directorio raíz de ese proyecto y ejecuta $ curl -s https://getcomposer.org/installer | php y, tras ello, si todo ha ido bien, deberías tener en el directorio del proyecto un archivo llamado composer.phar. Para comprobar si está bien instalado ejecuta $ php composer.phar

Las instrucciones anteriores nos sirven para instalar Composer en un proyecto concreto, pero generalmente lo que nos interesará es instalarlo globalmente para usarlo en varios proyectos.

La idea sería la misma, pero en lugar de descargar Composer en el directorio raíz de un proyecto lo deberíais hacer en un directorio ejecutable del sistema, como por ejemplo /usr/local/bin/composer. Después deberíais poder ejecutar el comando composer desde cualquier directorio del sistema y funcionaría. De esta forma además de tenerlo disponible para todos los proyectos también se facilita la actualización de Composer, dado que con la instalación para un proyecto concreto tendrías que ir actualizándolo en cada uno de ellos, mientras que con esta basta con actualizar sólo el global, con el comando $ sudo composer self-update.

En fin, con esto queda explicado cómo instalar Composer, del cual podéis leer aquí la documentación oficial. Próximamente (espero) más sobre Symfony.