<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <configSections>
        <sectionGroup name="system.webServer">
            <sectionGroup name="rewrite">
                <section name="rewriteMaps" overrideModeDefault="Allow" />
                <section name="rules" overrideModeDefault="Allow" />
            </sectionGroup>
        </sectionGroup>
    </configSections>
    <system.webServer>
        <directoryBrowse enabled="true" />
        <caching>
            <profiles>
                <add extension=".php" policy="DisableCache" kernelCachePolicy="DisableCache" />
                <add extension=".html" policy="CacheForTimePeriod" kernelCachePolicy="CacheForTimePeriod" duration="14:00:00:00" />
            </profiles>
        </caching>
        <rewrite>
            <rules>
                <rule name="block favicon" stopProcessing="true">
                    <match url="favicon\.ico" />
                    <action type="CustomResponse" statusCode="404" subStatusCode="1"
                        statusReason="The requested file favicon.ico was not found"
                        statusDescription="The requested file favicon.ico was not found" />
                </rule>
                <rule name="Imported Rule 1" stopProcessing="true">
                    <match url="^(.*)$" ignoreCase="false" />
                    <conditions>
                        <add input="{HTTP_HOST}" pattern="^example\.com$" />
                    </conditions>

                    <action type="Redirect" redirectType="Permanent" url="http://www.example.com/{R:1}" />
                </rule>
                <rule name="Imported Rule 2" stopProcessing="true">
                    <match url="^(.*)$" ignoreCase="false" />
                    <conditions>
                        <add input="{REQUEST_FILENAME}" matchType="IsFile" ignoreCase="false" negate="true" />
                        <add input="{REQUEST_FILENAME}" matchType="IsDirectory" ignoreCase="false" negate="true" />
                        <add input="{URL}" pattern="^/favicon.ico$" ignoreCase="false" negate="true" />
                    </conditions>
                    <action type="Rewrite" url="index.php?category={R:1}" appendQueryString="true" />
                </rule>
            </rules>
        </rewrite>
        <defaultDocument>
            <files>
                <remove value="index.php" />
                <add value="index.php" />
            </files>
        </defaultDocument>
    </system.webServer>
</configuration>

y voilà! mi sitio en sNews funcionando con sus lindas urls amigables!

1. Bajar el zip de la última versión
2. Descomprimir en el servidor
3. Con tu administrador de mysql favorito crear la base de datos e importar el sql que se encuentra en la carpeta /sql/ del proyecto.
4. Configurar la conexión de la base de datos en las primeras líneas del archivo snews.php:
   // MySQL host
'dbhost' => 'localhost',
// Database name
'dbname' => 'snews17',
// Database Username
'dbuname' => 'root',
// Database password
'dbpass' => 'root',

Y listo!, claro, siempre y cuando se cumplan ciertos requisitos:

• Tener el Apache instalado con el mod_rewrite habilitado, para que funcionen las url amigables
• MySQL
• PHP versión 4.3.x o superior
• .htaccess (con permisos de edición)

Haciendo click en login ingresan a la administración, el usuario y contraseña por defecto es test. Ahí van a ver las múltiples opciones que tiene.

Sugerencias:

• Cambiar el prefijo de las tablas, es una medida de seguridad que no esta demás. Esto se hace modificando el archivo sql antes de importarlo. Luego indicar en el snews.php el prefijo usado:

  // Table prefix for multiple sNews systems on one database
// if you don't need it just leave it blank
'prefix' => ' '


• Pueden bajar el archivo de idiomas, bajarlo en la carpeta /lang/ y setear en la configuración el idioma deseado. Yo tomé el archivo EN.php de esa carpeta y creé mi traducción propia: ES.php, la pueden bajar a su riesgo por que puede que tenga muchos errores.

1. Mantener la versión de WordPress actualizada, siempre, evitemos que nos ataquen por bugs conocidos y resueltos.
2. Lo mismo corre para los plugins y para los themes. Además tratar de que sean de fuentes confiables. Creo que a partir de la versión 2.7 WP te avisa siempre que haya actualizaciones disponibles.
3. Siempre, siempre hacer backups de todo (esto es para mi).
4. instalar el plugin WP Security Scan que sugiere varias modificaciones, entre ellas:
• Cambiar el prefijo por defecto de las tablas. Esto es una medida que se puede tomar a la hora de la instalación, o bien modificarlas en uno ya instalado. A mi la herramienta que trae el plugin no me funcionó, pero pude hacer manualmente haciendo un backup del sql de la base de datos y remplazando el wp_ por una cadena nueva del tipo gql257s_ por ejemplo, subir de nuevo la base de datos con este sql. Luego reemplazar en el wp-config.php la cadena $table_prefix = ‘wp_’; por $table_prefix = ‘gql257s_ ‘;. Como precauciones, no hay que estar logueado en el panel de administración al momento de hacerlo y se deben desactivar todos los Plugins, una vez restaurada la base de datos se activan nuevamente. No hacer esto puede generar el maldito error “No tienes autorización para acceder a esta página” (que no supe solucionar) al loguearte.
• Eliminar el usuario admin que crea por defecto, para no ser tan obvios.
• Crear el archivo .htaccess para nuestro wp-admin. Yo lo hice siguiendo este instructivo de paso creé el del wp-content también.
• También hace un chequeo de los permisos que deberias tener en cada una de las carpetas de tu blog, y te sugiere los cambios necesarios.
• Otras recomendaciones que en las últimas versiones de WP vienen por defecto o en el theme que uso viene por defecto, como ocultar la versión de WP, apagar los errores de de la base de datos, etc.

Buscando un poco encontré un par de link interesantes en el blog de aNieto que vale la pena recorrerlos para estar mas seguros:
10 pasos para proteger tu panel de administrador y uno mas viejito:
Las páginas blancas de la seguridad WordPress

Es muy útil cuando consideramos que la cantidad de opciones de un campo tipo select es muy grande; por ejemplo, un listado de países.

Consideraciones Iniciales

En este ejemplo se muestra como implementar los scripts necesarios. Utilizaremos el widget sfWidgetPropelChoice con algunas funcionalidades adicionales incluidas en el plugin sfFormExtraPlugin [1].

Instalando el plugin

No vamos a perder mucho tiempo en esto; simplemente:

$ symfony plugin:install sfFormExtraPlugin
$ symfony clear:cache

Si surgen dudas puedes consultar el readme de la doc.

Agregando jQuery

Por si no lo comenté anteriormente, necesitamos el framework de javascript jQuery para nuestro input de autocompletado. El plugin sfFormExtraPlugin no lo incluye por lo que tendremos que hacerlo a manopla. Puedes descargar el framework desde este link [2]. En estos momentos yo he descargado jquery-1.3.2.min.js.

Luego tienes que incluirlo en tu aplicación, para eso edita el archivo view.yml que se encuentra en la carpeta /config de la misma. Algo así:

  javascripts:    [ jquery-1.3.2.min.js ]

Puedes verificar si sQuery es cargado por la aplicación ojeando el código html generado; hasta puedes copiar la ruta del script y cargarla en el del browser para la comprobación final.

Schema de nuestro ejemplo.

Usaremos como ejemplo una tabla denominada producto y otra categoria para la relación 1-n:

propel:
  categoria:
    _attributes: { phpName: Categoria, idMethod: native }
    id: { type: integer, required: true, primaryKey: true, autoIncrement: true }
    nombre: { type: varchar(50), required: true }
    descripcion: { type: longvarchar }

  producto:
    _attributes: { phpName: Producto, idMethod: native }
    id: { type: integer, required: true, primaryKey: true, autoIncrement: true }
    codigo: { type: varchar(20), required: true }
    nombre: { type: varchar(100), required: true }
    marca: { type: varchar(80) }
    descripcion: { type: longvarchar }
    categoria_id: { type: integer, foreignTable: categoria, foreignReference: id }

Creamos una aplicación y para simplificar la existencia generamos un módulo administrativo con el generador de propel. En mi caso yo generé la aplicación pruebas y el módulo a partir de la clase Producto.

$ symfony generate:app pruebas
$ propel:generate-admin pruebas Producto

Configurando el widget

Como todo hijo de vecino sabe Propel genera clases del modelo (ORM) y también las clases de formulario del modelo entre otras cositasa más. Tendremos que redefinir el widget para nuestro campo categoria_id.

Entonces, dentro de la clase ProductoForm.class.php definiremos:

  public function configure() {
   // ..
    $this->widgetSchema['categoria_id'] = new sfWidgetFormChoice(array(
      'choices'          => array(),
      'renderer_class'   => 'sfWidgetFormPropelJQueryAutocompleter',
      'renderer_options' => array(
        'model' => 'Categoria',
        'url'   => $this->getOption('url')
      )
    ));
  // ..
  }

Acá es donde invocamos a la clase sfWidgetFormPropelJQueryAutocompleter definida en el archivo sfWidgetFormPropelJQueryAutocompleter.class.php que es agregada en el plugin sfFormExtraPlugin.

La usamos como clase de renderizado en el parámetro renderer_class. También definimos el modelo ‘Categoria‘ que usamos para la relacion 1-n y finalmente definimos ‘url’ mediante el método getObject(‘url’);

El parámetro ‘url’ define la dirección url que utilizará javascript cuando realice las búsquedas, a través de AJAX, de las distintas categorías para nuestro ejemplo. Con ‘$this->getObject(‘url’)’ esperamos que este valor ‘venga’ cuando creamos el objeto de formulario; por lo que tendremos que definirlo.

En el controlador …

En el controlador, en nuestra clase de acciones, vamos a redefinir el método executeNew.

  public function executeNew(sfWebRequest $request)
  {
    $this->producto = new Producto ();
    $this->form = new ProductoForm ($this->producto, array('url' => $this->getController()->genUrl('producto/request2Autoomplete')));
  }

Hemos creado un nuevo objeto de formulario donde se ha pasado dentro del array de opciones el parámetro ‘url‘ con el valor del link (renderizado) de la acción ‘producto/autocomplete‘.

Esto significa que el browser, gracias a los scripts de javascript, hará que cada vez que escribamos en el input se produzca un request a esta acción y es esta misma quien deberá ‘contestar’ ese pedido con los datos (en formato JSON) de la búsqueda en la tabla ‘categoria’ dentro de la base de datos.

Entonces nosotros hemos definido el nombre de la acción ‘autoComplete‘ de nuestro módulo ‘producto’ por lo que tendremos que programarla:

  public function executeAutoComplete($request)
  {
    $this->getResponse()->setContentType('application/json');
    $categorias = CategoriaPeer::retrieveForAutoSelect($request->getParameter('q'), $request->getParameter('limit'));
    return $this->renderText(json_encode($categorias));
  }

En esta acción hemos definido el content-type de la página de respuesta como application/json, creado una variable $categorias que son todas las categorías que nos devuelve el método de la clase CategoriaPeer denominado ‘retrieveForAutoSelect’ y finalmente renderizamos la respuesta de la acción transformando el array $categorias a notación JSon [3].

Por si no te has dado cuenta el método peer ‘retrieveForAutoSelect’ no existe. Amigo .. a arremangarse.

El método Peer

Finalmente debemos programar el método Peer que nos devuelve un array con todas las categorías encontradas en función de los datos que vamos introduciendo en el campo de texto:

  static public function retrieveForAutoSelect($q, $limit)
  {
    $criteria = new Criteria();
    $criteria->add(CategoriaPeer::NOMBRE, '%'.$q.'%', Criteria::LIKE);
    $criteria->addAscendingOrderByColumn(CategoriaPeer::NOMBRE);
    $criteria->setLimit($limit);

    $categorias = array();
    foreach (CategoriaPeer::doSelect($criteria) as $categoria)
    {
      $categorias[$categoria->getId()] = (string) $categoria;
    }

    return $categorias;
  }

Final.

Con todo lo realizado deberíamos tener funcionando nuestro autocompletado en el campo de las categorías. He subido un ejemplo onLine con el comportamiento correcto para que se pueda apreciar el funcionamiento.

Al agregar un producto nuevo [6] se aprecia el funcionamiento en el campo ‘categoria_id’. Puedes agregar más categorías [7] para que el ejemplo funcione mejor.

Gran parte de mi comprensión sobre este tema se debe a la traducción de formularios de librosWeb.es [4], hoy por hoy material imprescindible para el buen aprendizaje de symfony en idioma castellano; y al artículo Haz tu Elección de Roberto Puentes Díaz [5].

Saludos …

Enlaces

[1] http://www.symfony-project.org/plugins/sfFormExtraPlugin
[2] http://docs.jquery.com/Downloading_jQuery
[3] http://es.wikipedia.org/wiki/JSON
[4] http://www.librosweb.es/symfony_formularios/capitulo12/widgets_para_elecciones.html
[5] http://www.puentesdiaz.com.ar/symfony/haz-tu-eleccion.php
[6] http://cabezaderaton.com.ar/symfony/web/index.php/producto/new
[7] http://cabezaderaton.com.ar/symfony/web/index.php/producto/new

Internet Explorer requerido. Algo demasiado habitual.

En un primer momento me llama la atención de manera poco agradable la cantidad de páginas del gobierno nacional que están bajo esta condición: FONCyt, SeSOP, AFIP, etc.

Con poco podría ser de otra manera, no ?; más si tenemos en cuenta que gracias a Dios Internet Explorer no monopoliza como lo hacía antes, y parece ser que la tendencia es aún más pesimista para uno de los peores navegadoras que he conocido.

Aclaremos que lo hice usando Symfony 1.2, por lo que puede variar en algunos detalles cuando usemos otra versión.

Primero; los requisitos mínimos.

Muy posiblemente no va a ser ni la primera ni la última vez que subimos nuestro proyecto, creamos la base de datos, importamos los datos, etc. sin antes cerciorarnos que nuestro maldito hosting cumpla con los requerimientos técnicos mínimos. Aclaración para el alunado que nunca falta: no es necesario que en el servidor tengamos instalado symfony.

phpInfo.

Bueno, lo primero que podemos hacer es echarle una mirada a la configuración de php que tenemos en nuestro servidor. Simplemente haciendo un script, por ejemplo con el nombre info.php, y llamando a la función phpInfo() podemos ver un buen panorama de la configuración en el server.

<?php
echo phpinfo() ;
?>

Check Configuration.

Captura del check configuration de symfony 1.2

Y la segunda buena idea que podemos tener es ejecutar el script de chequeo de configuración que viene incluido cuando instalamos symfony (en la modalidad que sea) en nuestro server local. En mi caso donde uso Ubuntu y he instalado symfony mediante pear dicho archivo se encuentra en la siguiente dirección.

/usr/share/php/data/symfony/bin/check_configuration.php

Yo he modificado ligeramente el archivo para que quede mas lindo, similar a una consola . . Pueden descargar el archivo check_configuration.php.tar enlace, descomprimirlo y subirlo directamente a la raiz del hosting y ejecutarlo. En mi hosting actual, este es el link de prueba donde se aprecia que esta todo bien.

Si hay algo que no cuadra en estas pruebas, no sigas. Es imprescindible que estos chequeos sean correctos.

Freezar !

Freezar el proyecto es imprescindible. Creo haber leído que en futuras versiones esto ya no será necesario ya que nuestro proyecto tendrá el código necesario para que sea autosuficiente. Por lo pronto esto no es así.

Una tarea importante, que por lo menos yo siempre hago, es hacer una copia de nuestro proyecto ANTES de freezar. Porque al hacerlo en el proyecto se copiarán las librerías y archivos necesarios. Si bien existen métodos para desfreezar el proyecto me parece que es preferible trabajar con una copia local.

En la raíz de nuestro proyecto:

$ symfony freeze /usr/share/php/symfony

La ubicación donde se encuentra instalado symfony (/usr/share/php/symfony en mi caso) puede variar en función del tipo de instalación que hemos utilizado. Para saber cual es la ruta correcta para nuestro caso podemos usar:

$ symfony -V

Limpiar la Basura. Configurar permisos.

Podemos limpiar la cache usando el comando de symfony o borrando los archivos a mano. También podemos borrar el contenido de la carpeta log/ ya que no nos interesa subirlo al hosting.

$ rm -rf cache/*
$ rm -rf log/*

También podemos darle permisos de escritura a estas carpetas para la aplicación pueda generar los archivos sin problemas.

$ chmod 777 cache/ -R
$ chmod 777 log/ -R

Subir el proyeto al hosting.

Esto puede ser verdaderamente una tarea complicada si no lo hacemos con un mínimo de astucia. A lo que voy, en esta instancia mi proyecto tiene cerca de 4600 archivos (find -type f | wc -l). Si se nos ocurre subir vía ftp el proyecto al servidor a lo paisano vamos a notar que podemos estar una buena cantidad de minutos observando la progresión. Ni hablar si se nos corta la transmisión en medio de la transición. Un caos.

A comprimiiiiiirrrrr.

Lo ideal sería que en nuestro hosting tengamos alguna herramienta que nos permita descomprimir archivos en el servidor, como cPanel. De esta manera con solo comprimir todo el proyecto en forma local, subir un solo archivo (del órden de una decena de megas) y descomprimir en el server a otra cosa mariposa.

Pero si no contamos con este beneficio nos las podemos arreglar con algún script programado en php para tal fin. Para esto usamos PclZip.

Acomodando los archivos

PclZip es una clase programada en PHP que nos permite descomprimir archivos .zip. Lo mejor que podemos hacer es guardar en una carpeta el proyecto comprimido, la clase PclZip y un archivo que usaremos para la descrompresión llámese unzip.php.

Nuestro archivo unzip.php debe incluir la clase php pclzip, crear un objeto y definirle a dicho objeto el nombre del archivo que queremos descomprimir. Podemos hacer algo así:

<?php
require_once('pclzip.lib.php');

echo '<h3>Cargamos clase pclzip</h3>';

echo '<h3>Creando objeto ...</h3>';
$archive = new PclZip("miProyecto.zip");

if ($archive->extract() == 0) {
die("Error : ".$archive->errorInfo(true));
}
else {
echo '<h2>Descompresión OK</h2>';
}
?>

Ahora sólo resta subir estos tres archivos al hosting y ejecutar el script unzip.php. Tengamos en cuenta que esta tarea puede tardar varios segundos. No nos pongamos nerviosos. La pantalla permanecerá con el mensaje ‘Creando objeto …’ un lapso que dependerá de cuán potente es nuestro servidor. Es un buen momento para ir a hacer pis.

Si todo el proceso no ha sufrido errores al actualizar la vista en nuestro gestor ftp podremos ver todos los archivos y carpetas producto de descomprimir nuestro proyecto.

Esta historia continuará …

Restan muchas cosas por resolver que por cuestiones de tiempo y esfuerzo no puedo hacerlas ahora. Si consideramos que ya haz creado la base de datos y has importado lo que tenias en el server local la aplicación debería funcionar.

Espero que este artículo siga evolucionando en función de nuevas experiencias, preguntas y respuestas que puedan llegar. Saludos.

Esta historia continuará …

Javascript Dinámico ?

Pues la verdad así entiendo a un archivo javascript que modifica su contenido en función de ciertos factores. Por ejemplo, generar una estructura de datos en notación JSON en base a datos producto de una consulta realizada en el modelo.

Metodología

La implementación la he tomado de este artículo llamado Use routing to serve localized and dynamic JavaScript que he encontrado googleando. Mi aporte es más que una traducción una libre interpretación con algunos comentarios adicionales. O sea, una chantada.

La dirección del Archivo dinámico

Comenzado de atrás para adelante, vamos a definir el nombre de nuestro archivo javascript para insertarlo en algún script php de la vista, ya sea un layout, un template, etc. Tenemos que tener en cuenta que en función del nombre del archivo que definamos tendremos que definir una ruta nueva en nuestra aplicación.

Por ejemplo … usemos:

<?php
// Cargamos js con el helper
use_javascript('miModulo/dinamico.js');
?>

O sea … el nombre y la ruta que hemos escogido poco tiene que ver con el archivo que realmente terminará generando el código javascript. Eso lo termina definiendo la nueva ruta.

Nueva ruta a routing.yml

Ahora debemos agregar una nueva ruta a nuestro routing.yml de nuestra aplicación en función del nombre de archivo antes definido. Para nuestro ejemplo:

dynamic_javascript:
url: /miModulo/:filename.js
param: { module: modulo-real, action: load }

Con esta ruta lo que logramos es que cuando se intente cargar el archivo desde el helper use_javascript busque la acción load del modulo ‘modulo-real’.

El Módulo

Ahora creamos un módulo nuevo en función de la ruta, en nuestro ejemplo es ‘modulo-real’:

$> symfony generate:module appname script

Y definimos la acción load que indefectiblemente buscará la aplicación a causa de la ruta:

public function executeLoad($request) {
$this->setLayout(false);
$this->getResponse()->setContent('text/javascript');
$this->setTemplate($request->getParameter('filename'));
return ".js".chr(0);
}

En este método:

La respuesta de la aplicación no tendrá un Layout.

Será un archivo de texto de javascript.

El contenido será el template con nombre igual a dinamico.js. Este archivo debe estar dentro de la carpeta templates del mismo módulo que esta acción, o sea, ‘modulo-real’.

Y el dinamismo ?

Bueno, simplemente trata a dinamico.js como un archivo PHP normal. Puedes usar y abusar de PHP y Symfony; mientras te asegures que lo que genera sea javascript, todo vale.

Por otro lado, puedes usar la arquitectura creada para cargar distintos archivos, por ejemplo …

<?php use_javascript('miModulo/otro_js.js'); ?>

… y sólo preocuparte por tener ese archivo otro_js.js dentro de la misma carpeta templates.

Puedes modificar la acción para la forma de cargar el .js, etc. etc. etc.
Espero que sea útil.
Saludos.

Captura del producto del generador

Todavía no quiero mostrar un ejemplo funcionando porque algunas cosas me dan un poco de vergüenza. Están muy mal hechas y a conciencia.

Estos últimos días he tomado la decisión de publicar el código no sin antes terminar al menos algunas puntos primordiales como documentación

Publicar en primera instancia me ayudará a ponerme metas y responsabilidades, y también aclarar mis ideas. Cuando uno escribe con la convicción de que hay personas que lo leen reafirma conceptos para poder transmitir de la mejor manera posible el mensaje al lector. Por lo menos, así lo veo yo.
Y en segunda instancia, algo no seguro, poder recibir críticas, correcciones y porque no participación de otras personas.

Esta publicación estará, sin lugar a dudas, llena de correcciones que inevitablemente surgirán.

Objetivos

Implementar un plugin para symfony que nos permita incorporar a nuestros proyectos un generador similar al generator de propel pero con algunas mejoras sustanciales:

• Widgets de Formularios adaptados a las tecnologías usadas.
• Uso de AJAX.
• Implementación de una UI (Interface de Usuario).
• JavaScript no intrusivo.

Tecnologías

Inevitablemente el plugin deberá tener un buen soporte del lado cliente. En este caso utilizaremos mooTools.

Metodología de funcionamiento

La idea global de la metodología de funcionamiento es implementar un pequeño motor en el cliente (JS) con la capacidad suficiente de ‘entendimiento’  con las convenciones de funcionamiento de los scripts generador por Propel en el servidor.

Esta historia recién empieza …

Hoy pienso que debería escribir sobre algo relevante; cosa que no estoy muy seguro que lo sea. En estos días me ha llamado la atención la facilidad con la que se puede adquirir material ‘prohibido’ en internet.

En realidad este no es el punto; todos sabemos que unos de los principales negocios desde los inicios de internet es la pornografía, por ejemplo. Pero hasta donde yo recordaba … todo se hacía desde el anonimato. Solía consumir material porno cuando buscaba cracks o serials para alguna aplicación pirata. Siempre sitios 100% desprolijos, armados con fotos berretas, gif animados, letras rojas y amarillas grandes, etc.

Al alejarme del soft privativo me alejé de los cracks y consecuentemente, en gran medida, de las chicas (y de los chicos por cierto). Mientras escribo esta entrada no dejo de escuchar a Mario Pergorini promocionar una y otra vez desde ‘cual es?’ su web de mierda www.cuales.fm.

Y eso me llama la atención. Ya no son piratas anónimos, es el mismo pelotudo que tanto respeto se ha ganado con algunos programas televisivos, comentarios contestatarios, excelentes reportajes, etc.

Me da un poco de cosa como se va blanqueando el negocio y que no se entienda que internet es un medio tan o más influyente para el consumidor que la tele. Está flotando en el aire la idea que en la tele hay cosas que se pueden hacer y cosas que no (aunque es de terror) y el producto puede estar en tela de juicio del consumidor. Internet no. Es tierra de nadie.

No estoy en contra de publicar este tipo de material, y uno es consciente que tampoco se puede controlar. Lo que me da por las pelotas es la grasa que chorrea este tipo de sitio, con nombre y apellido, que acuden a una gorda garchando (la escena es morbosamente asquerosa) para levantar las visitas y así promocionarlo con el único control que es casi tan berreta como el video mismo. Una verdadera porquería.

Todo bien, que cada quien haga de su culo un colectivo y deje subir a quien quiera.

No hay mejor momento para invocar una de las frases más repetidas entre personas entre 25 y 35 años: Me estaré volviendo viejo.