Muchas gracias por confiar en nosotros, por cada RT en twitter, por estar ahí (en el blog, en twitter, facebook, en persona…), por trabajar con nosotros y sobre todo, por hacer que este año lo empecemos con toda la ilusión y ganas de ofreceros el servicio y la atención que os merecéis.

Puede que en algún momento de nuestras apasionantes vidas como desarrolladores web nos interese extraer el contenido de cada uno de los elementos de una lista html (<li>,<option> o similares) y almacenarlos en un array para utilizarlos a lo largo de nuestra aplicación.

Me he escrito una función que hace precisamente esto, gracias a la función preg_replace de php.

function li2Array($html,$elemento="li"){

  $a = array("/<".$elemento.">(.*?)</".$elemento.">/is");
  $b = array("$1 <explode>");

  $html  = preg_replace($a, $b, $html);
  $array = explode("<explode>",$html);

  return $array;

}

Cuando desarrollamos con php haciendo uso de la librería curl, para hacer peticiones http post, nos podemos encontrar con el siguiente error al mostrar las cabeceras de respuesta: “HTTP/1.1 417 Expectation Failed Connection: close Content-Length: 0“

La solución al problema es enviar el campo Expect (basta con enviarlo vacío) dentro de las cabeceras http de la petición. Lo vemos en el siguiente ejemplo:

$ch = curl_init();

//metemos el campo expect en la cabeceras

curl_setopt( $ch, CURLOPT_HTTPHEADER, $headers = array( "Expect:"));

Los desarrolladores familiarizados con symfony conocen la clase sfWidgetFormChoice que nos permite crear un campo html seleccionable (tipo select, radio, checkbox y list) de una forma muy cómoda:

class ComprarForm extends sfForm{

  private $opciones = false;

  //configuramos el widget con sus opciones en la clase formulario
  public function configure()
  {

     $this->opciones  = array('manzanas',
                              'peras',
                              'limones');

     $this->setWidgets(array(
                              'quiero'   => new sfWidgetFormChoice(
                                              array('expanded' => true,
                                                    'choices'  => $this->opciones)),
                       ));

     $this->setValidators( array( 'quiero' => new sfValidatorChoice(
                                              array( 'required' => true,
                                                     'choices'=> array_keys($this->opciones)
                                                   )),
                         ));
  }

}

//en la acción creamos el formulario
  $this->formulario = new ComprarForm();

//y en la vista generamos el campo tipo <select> con las opciones configuradas
  $formulario['quiero']->render();

Hoy me he encontrado con la necesidad de tener que crear diferentes opciones segun la petición que llegue a la acción que muestra el formulario. Quizá me interese que en lugar de que mi select se rellene con frutas como en el ejemplo anterior, se rellene con todo tipo de utensilios para matar zombies, por ejemplo.

Para conseguir esto podríamos crear otra clase de formulario que contenga un widget con esas opciones y sus respectivos validadores, pero eso rompería totalmente la regla de oro en el desarrollo web ágil: “Don’t repeat yourself“.

La solución más elegante es sobreescribir el constructor de nuestra clase ComprarForm, de tal forma que se especialice con respecto al de su padre sfForm para admitir un parámetro extra llamado “tipoDeProducto”.

class ComprarForm extends sfForm{

  private $opciones = false;

  public function __construct($tipoDeProducto='frutas',
                              $defaults = array(),
                              $options = array(),
                              $CSRFSecret = null){

      switch($tipoDeProducto){
        case 'frutas':
          $this->opciones  = array('manzanas',
                                   'peras',
                                   'limones');
        break;
        case 'armas':
          $this->opciones  = array('sierra eléctrica',
                                   'recortada',
                                   'katana',
                                   'rifle de francotirador');
        break;
      }

      parent::__construct($defaults, $options, $CSRFSecret);

 }

 //configuramos el widget con sus opciones en la clase formulario
 public function configure()
 {

     $this->setWidgets(array(
                              'quiero'   => new sfWidgetFormChoice(
                                                   array('expanded' => true,
                                                         'choices'  => $this->opciones)),
                      ));

    $this->setValidators(array(
                              'quiero' => new sfValidatorChoice(
                                               array('required' => true,
                                                     'choices'=> array_keys($this->opciones)
                                                    )),
                         ));
 }

}

Ahora ya tenemos todo preparado para poder especificar desde la acción qué opciones queremos en el campo select del formulario ComprarForm

   $this->formulario = new ComprarForm('armas');

Y en la vista sin modificar el código ya nos aparecerán los productos que estamos deseando comprar.

No hace falta explicar la conveniencia de mantener un sistema actualizado, aunque todos los sysadmins no son de mi misma opinión y muchos se jactan de tener uptimes altísimos en su servidor, confundiendolo con el SLA del servicio.

Para saber la compilación de SQL Server, lo vemos desde el SQL Server Management si lo tenemos instalado o ejecutando:

SELECT SERVERPROPERTY('productversion'), SERVERPROPERTY ('productlevel'), SERVERPROPERTY ('edition')

A falta de una lista oficial que agrupe todas las compilaciones, en SQLTEAM hay publicada una lista mantenida por Bill Graciano que os será de ayuda.

Saludos, Sergio Sainz.

Cuando tenemos que actualizar varias tablas, insertando, borrando o actualizando varios registros en cada una de las mismas y cuya integridad puede estar en riesgo en caso de que una de las operaciones falle, nos es crítico el uso de transacciones.

Si estamos usando Symfony y el orm Propel, con mySql e innodb, podemos hacer lo siguiente:

    $con = Propel::getConnection();

    try {
         //abrimos la transacción
         $con->beginTransaction();

         //operaciones pertinentes contra la base de datos

         //si todo va bien guardamos los cambios
         $con->commit();

    } catch (Exception $e) {

         // Hacemos rollback de los cambios en caso de fallo
         $con->rollback();
         //devolvemos el error al depurador
         throw $e;
    }

Saludos, Asier Marqués

Una de las cosas que más me gustan respecto a la seguridad de Windows, son las mejoras en el firewall de Windows 2008. Entre muchas más posibilidades que en la versión anterior de Windows, podemos bloquear ips atacantes de una forma sencilla.

Como estoy seguro de que ningún administrador deja de revisar la pestaña Seguridad en el Visor de Eventos (¿verdad que no?), en ocasiones pueden detectarse reiterados intentos de conexión, si son ilégitimos, aunque no consigan nada pueden lograr un DDOS en toda regla, por ello lo mejor es filtrarlos desde un firewall perimetral. A falta de  uno, ahora podemos filtrar desde el propio server.

1) Abrimos el firewall de Windows.

2)Seleccionamos añadir nueva regla...

3) Añadimos una regla personalizada.

4) La aplicamos a Todos los programas.

5) Tipo de protocolo: Cualquiera.

6) Agregamos la IP que queremos bloquear, también puede ser un rango entero.

7) Seleccionamos: Bloquear la conexión.

Indicamos a que redes aplicamos la regla.

9) Le damos un nombre identificativo.

10) Y ya tenemos nuestra regla de seguridad creada.

Saludos, Sergio Sainz

Cuando te acostumbras a programar siguiendo el patrón MVC, te resulta incómodo y poco limpio el hardcodear Html en el código interno de la aplicación.

Si embargo en JavaScript, estamos mal acostumbrados a ver códigos como el siguiente:

var html = "<li class='" + class + "'>" +
           "<input type='text' id='"+ id +"' /></li>";

Aunque el código en sí no es incorrecto, cuando tenemos que realizar cambios en nuestra aplicación (situación bastante común) sin volvernos locos, necesitaremos separar o hacer más mantenible ese código html que queremos dinamizar desde javascript.

Una solución consiste en escribir el código html que vamos a reutilizar desde javascript, con una serie de patrones que sustituiremos más adelante por los valores que nos interesen.

Por ejemplo, si quisiéramos rellenar el siguiente elemento <ul>

<ul id="list"></ul>

Junto antes de terminar el body colocaríamos el siguiente bloque de código

<div id="bloque_lista" style="display:none">

  <li class="|class|">
    <input type=”text” id=”input|row_id|” />
  </li>

</div>

Para rellenar la lista, bastaría con sustituir los patrones |class| y |row_id| por los valores que necesitemos.

function addItemToList() {

   var list     = $('#list');
   var class    = "rosa";
   var template = $('#bloque_lista').html();

   template = template.replace(/|class|/gi, class)

   for(var id=1;id<11;id++){

     list.append(template.replace(/|row_id|/gi, id));

   }

}

Saludos, Asier Marqués

Algunas aplicaciones, como WordPress necesitan que el Safe Mode (Modo Seguro) no este activo. Esto se puede controlar facilmente desde nuestro panel de control, sin tocar una línea de código.

1) En el panel de control accedemos a Ajustes de alojamiento.

2) En el apartado de soporte para PHP, activamos o desactivamos la función php_mode.