desarrollo

Liberado Zend Framework 1.8.4 y más

A través del Developer Center de Zend me entero de que hoy se ha liberado la última versión estable de Zend Framework. Esta release de mantenimiento ha corregido más de 50 tickets abiertos en 20 componentes distintos. Con un poco de suerte ya podremos disfrutar de la rama 1.8 sin tantos workarounds para salir del paso.

Por lo pronto, y si utilizáis svn, ya tardáis en hacer un svn up :)

A finales del próximo mes de julio lanzarán la versión 1.9.0. ¿Qué está previsto que traiga? Pues bastantes cosas, como por ejemplo un lector de feeds mucho más completo y elaborado, enrutador para peticiones de tipo REST, soporte LDAP, patrón factory en Zend_Log, etc.

Además, acaban de lanzar también un visor de roadmap que estará activo a partir de ahora para todas las futuras releases. Si bien esta herramienta será muy útil tanto para fieles como para curiosos, no contará con fecha de lanzamiento, pues tal y como explican en su blog, es muy complicado estimar fechas cuando todo el trabajo lo realizan voluntarios en su tiempo libre.

Edit: Acabo de comprobar que además han corregido la creación de controladores en modulos desde la utilidad en línea zf. ¡Bravo! :)

to goto or not to goto

Hace 5 días PHP lanzó la versión 5.2.10, centrada sobre todo en corregir fallos de seguridad. Un día después, el 19 de junio, lanzaron la RC4 de PHP 5.3.0, algo así como una versión de transición entre PHP 5 y el esperada PHP6. ¿Qué novedades traerá PHP 5.3.0? Bueno, de eso ya se ha hablado mucho, como por ejemplo namespaces (¡Al fin!), late static binding y closures entre otras muchas cosas. ¿Qué cosas exactamente? Sigue leyendo…

Una de ellas es, ni más ni menos, que la estructura de control goto. Así es amigos. Si PHP no es suficientemente sencillo, que incluso poniendo tu perro a pisar el teclado se sacará un programa que ejecute sin problemas, ahora para facilitar el trabajo a los muchos entusiastas del spaguetti code nos presentan el goto.

Sin duda esta estructura es muy controvertida. Bien usada permite construír código más limpio y legible. Pero ahí radica el problema… Pocas veces está justificado su uso.

En fin, al igual que en la documentación de PHP, os pongo una tira cómica cortesía de xkcd.

goto

Interfaz fluida

Es curioso cuando averiguas el nombre con el que se designa a algo que ya conocías. Eso me ha pasado hoy, cuando he visto lo que en ingeniería del software se conoce como una interfaz fluida.

La idea es esta: Que todos los métodos setters devulvan el objeto actual de forma que se puedan anidar llamadas y el código sea más legible.

Como ejemplo, copio y pego de la Wikipedia:

	// Interfaz fluida
	$myCar = new car();
	$myCar->setSpeed(100)->setColor('blue')->setDoors(5);

	// Ejemplo sin interfaz fluida
	$myCar2 = new car();
	$myCar2->setSpeed(100);
	$myCar2->setColor('blue');
	$myCar2->setDoors(5);

Aunque a mí, personalmente como más me gusta escribirlo es así:

	$myCar = new car();
	$myCar
		->setSpeed(100)
		->setColor('blue')
		->setDoors(5);

Y todo poniendo un simple “return $this;” al final de cada método setter :)

Zend Framework 1.8.0 Released

¡Qué gran noticia! :) Ha sido liberada la nueva versión de Zend Framework. Como principales novedades nos ofrece la posibilidad de utilizar Zend Tool, la herramienta de consola para hacer el trabajo sucio por nosotros, y además una nueva capa para servicios de computación nube (ugh!) en Amazon.

Desde la famosa aparición de Ruby on Rails en el año 2004, no han parado de aparecer nuevos frameworks de desarrollo implementando las fantásticas ideas alrededor de RoR. En PHP, por nombrar algunos, pronto se hicieron muy populares CakePHP o Symphony. Pero por otra parte tenemos a Zend, la empresa detrás del motor intérprete de PHP (En consecuencia, gozan de un principio de autoridad más que merecido en dicho lenguaje). Corría el año 2005 cuando lanzaron la primera versión de su framework.

Pese a que aun hoy se podría decir que carece de muchas funcionalidades que hace años son comunes hasta en los frameworks más espartanos, a título personal Zend Framework fue el que me cautivó desde el primer momento: Su funcionamiento es totalmente modular. A diferencia de sus competidores, no obliga a dar el salto de la noche a la mañana, sino que permite ir adoptando poco a poco sus utilidades, instalándolas bajo demanda. Lenta pero implacablemente vas cayendo presa de sus encantos, hasta que ya un día te das cuenta de que has dejado de programar en PHP; Ahora programas en ZF :)

Una de las ventajas de que sea tan increíblemente modular es que puedes dar el salto a su sistema MVC poco a poco. Primero empiezas con un bootstrap y controladres básicos, luego vas dominando las vistas y los layouts, hasta que finalmente un día añades modelos de datos, y modificas el enrutador a tu antojo. Todo ello controlando desde el primer momento qué estructura de directorios emplear, o de qué manera funcionará la maquinaria.

No sé a vosotros, pero yo una de las cosas que mas detesto de todas las novedosas herramientas de programación que surgen últimamente es la magia. Sigues los tutoriales y piensas “¡Dios mio! ¡He creado un blog en 10 minutos! Pero no tengo ni idea de cómo“. Y eso no deja buen sabor de boca. ¿Que ocurre si necesitas alterar levemente el funcionamiento de la aplicación que se crea en el tutorial? Pues que sudas tinta y en el peor de los casos vuelves acobardado a tu metodología de siempre. Esto no pasa zon ZF :)

Pero al lío, que mi disertación sobre frameworks se ha alargado. ¿Por qué me emociona tanto la nueva release? Porque, tras varios meses programando con él, acaba de salir el script de consola que permite crear los andamios de tu aplicación (Scaffolding). Pero, como todo en Zend, es totalmente personalizable. Puedes configurar el funcionamiento por defecto del script mediante el Provider y el Manifest.

Además, y cosa que me encanta, esta herramienta ha sido lanzada junto con una nueva arquitectura de aplicaciones: Zend_Application. Básicamente encapsula las funcionalidades del fichero bootstraping en un recurso reutilizable dentro de un objeto. O visto desde otra perspectiva, es el objeto principal con su método main(). Orientación a objetos al poder!

Respecto al apartado de la computación nube… No tengo mucho que comentar. Me gustan las infraestructuras estándar (Como LAMP), y eso de volcar mis recursos en plataformas propietarias, heterogéneas, y sólo en manos de un proveedor, no me gusta nada. Así que por el momento dejo el cloud computing a los gurús de las blackberries.

Seguridad en PHP

En este pequeño post voy a dar un repaso a algo que la mayoría de programadores web ya saben, pero para no olvidarlo, y por si a alguien le viene bien, voy a resumir los principales puntos en los que debemos cuidar la seguridad de nuestras aplicaciones en PHP.

Facebook como plataforma de usuarios

Facebook es un monstruo que cada día gana más y más adeptos. Por suerte o por desgracia parece que se está convirtiendo en una necesidad para todos los usuarios contar con una cuenta en este sistema. Uno de las razones de su éxito es la de facilitar a los desarrolladores interactuar con su plataforma. Todo comenzó permitiendo el desarrollo de aplicaciones dentro de su web. Ahora ofrecen mucho más. ¿Qué podemos hacer gracias a Facebook?

Lejos quedan aquellos tiempos en los que una página web era autocontenida. Hoy todos entendemos como normal relegar ciertos servicios en manos de terceros, como por ejemplo mapas, vídeos, audios, encuestas o fotografías. Sin embargo hasta ahora ninguna plataforma de usuarios ha llegado a cuajar del todo.

Si bien existe OpenID y su uso está muy extendido, poca gente lo utiliza o entiende cómo funciona, ni siquiera mediante la ayuda de Google y Yahoo! En cambio Facebook, con su conocido Facebook Connect parece estar ganando la batalla.

Facebook Connect

Facebook Connect en funcionamiento

Es un todos ganan:

  1. Facebook, porque hace más necesaria e ubicua su plataforma.
  2. Desarrolladores, porque se agiliza la programación, se invita a participar con facilidad, y se cuentan con fichas más exactas y completas.
  3. Usuarios, ya que no necesitan registrarse en otra nueva página para participar.

La gran pega, como ya se sabe, es la dependencia de terceros para algo tan crítico como son los usuarios. Además que no todo el mundo tiene cuenta en Facebook.

Igualmente curioso es el hecho de que esta misma tecnología consiste básicamente en lo mismo que Microsoft siempre ha querido hacer con Windows Live ID (Anteriormente Microsoft Passport), que no es mas que un servicio de Single Sign-On: Utilizar una misma cuenta para acceder a diferentes servicios.

Pero ahora Facebook no sólo nos ofrece su sistema de autenticación de usuarios, sino que desde hoy también permite añadir un sistema de comentarios sencillo de administrar y sin necesidad de programación. En esto tampoco son pioneros, pues con Google Friend Connect ya podíamos hacerlo.

Con todo esto, si utilizamos Facebook como plataforma de usuarios obtendríamos:

  • Agilidad. En unos minutos tendríamos el sistema de usuarios listo en nuestra web.
  • Exactitud de información. Los datos que los usuarios completan en Facebook suelen ser de bastante calidad.
  • Mayor presencia. Podríamos añadir notas en su muro.
  • Comentarios. Gracias a la nueva herramienta.
  • Red social. Por supuesto los enlaces de usuarios dentro de Facebook puede funcionar dentro de nuestra web.
  • Más participación. Puesto que no es necesario registrarse para participar en nuestra web.

Pero como dije antes, puede resultar un precio demasiado caro.

A título personal, todas las páginas que he creado funcionaban con un sistema de usuarios propio. Tengo bastantes ganas de poner en práctica una visión distinta, y Facebook hoy por hoy me parece la opción más sencilla y con posibilidades de éxito.

Contenido duplicado

Uno de los principales retos a la hora de optimizar bien el posicionamiento de nuestros sitios web es evitar el contenido duplicado. ¿Qué es exactamente? Se trata de aquellos casos en que se puede acceder al mismo contenido desde distintas URLs. Podemos resumirlo como DUST (Different URLs with Similar Text). Hoy, los tres principales buscadores han lanzado un nuevo método para solucionar este problema. Pero antes de ver esta sencilla solución, veamos el problema del contenido duplicado.

Históricamente los spammers han tratado de obtener un mejor posicionamiento web gracias a inundar multitud de páginas en uno o varios dominios con las palabras clave que desean posicionar. De este modo lograban una alta densidad de palabras, obteniendo un buen posicionamiento para dicha keyword, y además se enlazaban entre esas páginas aumentando su ranking.

Los buscadores, para evitar que estas páginas fraudulentas obtivieran un rango tan elevado, modificaron sus algoritmos de modo que se penalizara el contenido duplicado.

¿Cuál fue el problema? Que muchas páginas legítimas presentaban casos de contenido duplicado. Por ejemplo, en muchas webs se accede al mismo documento escribiendo estas URLs:

  • http://www.example.com/articulo?id=314
  • http://example.com/articulo?id=314
  • http://www.example.com/articulo/314
  • http://example.com/articulo/314
  • http://example.com/articulo/314?SESSID=65AD8801FB

Las páginas que se comportan así están siendo penalizadas, ya que, como dije al principio, muestran el mismo contenido desde distintas URLs. Afortunadamente los programadores de los motores de busqueda eran consciente de esto y sugirieron a los webmasters seguir una estricta política de URLs únicas mediante el uso de redirecciones HTTP.

Pero hoy los 3 grandes buscadores, mediante su alianza Sitemap, nos han presentado una nueva solución que han consensuado entre ellos. A partir de ahora mediante una etiqueta <link> podremos especificar qué URL es la prioritaria, por ejemplo, siguiendo con el ejemplo anterior:

<link rel=”canonical” href=”http://example.com/articulo/314” />

De este modo, las otras 3 URLs incluirían esta etiqueta <link> informando a los buscadores de que es una dirección con contenido duplicado.

De cara al usuario, a diferencia de las redirecciones, no se percibirá ningún cambio. Sin embargo los buscadores sí manejarán estos documentos como si se tratara de redirecciones, es decir, se comportarán con estos casos exactamente igual que se han venido comportando con las redirecciones 301: Traspaso de enlaces entrantes, de ranking, etc.

Mi opinión: Prefiero emplear directamente redirecciones. Si tengo unas URLs estandarizadas para mi página web, prefiero que los usuarios utilicen ésas. Sin redirecciones cada persona podría apuntar una URL distinta. Así mismo me parece curioso la directriz de Google de “Make pages primarily for users, not for search engines“. Con iniciativas como esta demuestran que es necesario realizar páginas web teniendo en cuenta los motores de busqueda desde el primer momento.

Cómo escribir un archivo CSS

A veces trucos sencillitos nos ayudan mucho en el día a día de la maquetación web. En este minipost voy a intentar convenceros de que es mejor escribir todas definiciones de una clase en una sola línea, en lugar de en varias.

Partamos de un ejemplo cualquiera. Tenemos un estilo CSS para un párrafo que utiliza la clase “foo”:

p.foo {
   border: 1px solid red;
   background-color:#EEE;
   font-size: 12px;
   padding: 20px;
   width: 300px;
   float: right;
}

Si digo que es más cómodo ponerlo todo en una línea muchos pensaréis “no… Es incómodo y queda mal estructurado”:

p.foo { border: 1px solid red; background-color:#EEE; font-size: 12px; padding: 20px; width: 300px; float: right; }

Pues después de mucho tiempo funcionando con este tipo de sintaxis he de decir que es muchísimo más cómodo trabajar con estilos en una sola línea, que tabulados y multilínea. El motivo a continuación :)

Normalmente una página web cualquiera puede tener más de 50 clases de estilos como la que he puesto en el ejemplo de arriba. Sin embargo prácticamente nunca se tienen más de 10 estilos dentro de una clase. De ese modo, cuando tenemos que modificar algo en nuestra hoja tenemos primero que localizar el lugar en el que se encuentra aquéllo que queremos actualizar.

El grueso de nuestra búsqueda está en localizar la clase, ya que tenemos más de 50, y no el estilo, ya que rara vez sobrepasan los 10. Echémos números.

Vamos a suponer 70 clases, con una media de 6 estilos. Si nuestra hoja utiliza el primer método tendrá 9 líneas por clase (Añadimos una línea en blanco entre ellas), por lo que el fichero resultante tendría la friolera de 630 líneas!

Ahora lo codificamos con el segundo método. Una linea por clase, y en total… 70 líneas. Eso es un gran ahorro en búsqueda!

Dicho de otra forma. En lugar de buscar entre 630 “campos”, tendremos que buscar entre 70 y entre 6. Esto en algoritmia se llama optimización :)

Estándar de código en PHP

Los convenios son buenos. Ayudan a resolver siempre de una misma forma situaciones similares. Cada programador/proyecto tiene sus propios convenios de programación. En este artículo voy a contar los mios cuando desarrollo en PHP.

Sangrado y edición

No utilizo el caracter tabulador. En su lugar, empleo 3 espacios. Motivo: El caracter tabulador (t) no se muestra igual en todos los lectores de ficheros.

No utilizo más de 80 caracteres de ancho por línea. Motivo: El código es mucho más legible y cómo de imprimir.

Si una línea excede de 80 caracteres:

preg_match('expresion regular de la muerte larga larga', $cadena, $match);

quizás meto la cadena larga en una variable

$reg = 'expresion regular de la muerte larga larga';
preg_match($reg, $cadena, $match);

o si la cadena es muy larga, concateno las partes

$reg = 'expresion regular de ';
$reg .= 'la muerte larga larga';
preg_match($reg, $cadena, $match);

o si no es tan larga, divido en lineas la función

preg_match('expresion regular de la muerte larga larga',
   $cadena, $match);

¿Y con los ifs de muchas condiciones que sobrepasan los 80 caracteres?

if ($condicion1 && $condicion2 && $condicion3 && $condicion4) {
   // código
}

pasa a ser

if ($condicion1 &&
   $condicion2 &&
   $condicion3 &&
   $condicion4)
{
   // código
}

Bloques de código

Las llaves, para definir bloques de código, siempre las coloco así:

expresión {
   // código
}

salvo que la expresión exceda de 80 caracteres, en cuyo caso lo hago así:

expresión larga
   muy larga
{
   // código
}

En este segundo caso la razón de pasar la llave a la izquierda es poder distinguir dóde empieza el bloque de código. Sin embargo, en el primer caso lo pongo al final de la línea por costumbre.

Nombres

Por supuesto deben ser descriptivos, salvo algunas excepciones, como variables de contadores.

Los nombres de funciones, métodos y clases, siempre procuro ponerlos en CamelCase, esto es, eliminando los espacios y poniendo la primera letra de cada palabra en mayúscula. En funciones y métodos, la primera letra de todas es minúscula, y en el caso de clases, en mayúscula.

Por ejemplo

class Car {
   public function getSpeed() {
   }
}

En el caso de atributos y variables suelo emplear palabras en minúsculas delimitadas por guiones bajos, por ejemplo:

private $main_container;

Las constantes, como no, en mayúsculas.

Y por último, los nombres de ficheros, que los pongo también sustituyendo espacios por guiones bajos, por ejemplo foo_bar.php.

Cadenas de texto

Nunca empotro variables dentro de una cadena entrecomillada. Por ejemplo

"Hola $nombre, bienvenido"

Lo pondría como

'Hola ' . $nombre . ', bienvenido'

Si bien hace unos años la diferencia de rendimiento al utilizar comillas dobles o simples era muy notable, debido a que las dobles permiten interpretar las variables dentro de ellas, hoy día es un obstáculo superado para PHP. En cualquier caso, sigo prefiriendo comillas simples salvo que sea imprescindible.

Nunca separo una misma cadena en varias líneas. En su lugar concateno las partes.

Comentarios

Los ficheros, clases y métodos los documento con comentarios con phpDocumentor.

Para comentar trozos de código utilizo doble barra (//), aunque exceda dos líneas:

// Este comentario tiene dos líneas, pero
// aun así no utilizo comentarios multilínea

Para poner comentarios importantes, por ejemplo, informando de qué me queda por hacer en un código sin acabar, lo pongo con tres barras (///):

/// Terminar la validación de variables introducidas por el usuario

Y para poner avisos importantes con algo que sé que hasta dentro de un tiempo no me volveré a encontrar, pongo:

/// NOTE: recuerda eliminar este método

Miscelánea

Por último, las etiquetas de PHP <?php y ?>, que tan poquito me gustan, las escribo siempre como <?php y ?> salvo en el caso de hacer un echo, que utilizo la forma abreviada <?=$var?>. Esto último está desrecomendado, ya que por ejemplo, daría error la primera línea de un fichero en XML:

<?xml ?>

Además muchos servicios de alojamiento no permiten las etiquetas cortas de PHP.

Y respecto al importado de ficheros, tenemos include(), include_once(), require() y require_once(). Siempre utilizo los terminados en once(), ya que de ese modo puedo llamar varias veces sin preocuparme a un mismo fichero. Además, procuro usar siempre require_once() (Aunque a menudo se me olvida) pues, a diferencia de include, require lanza un error que interrumpe la ejecución. Y no queremos que nuestra aplicación continue la ejecución si falta un fichero importante :)

Algunos estándares

Cada framework y casi cada proyecto tienen su propio estándar. A continuación enumero algunos:

SVG y la web

Los mapas de bits no escalan (Y nunca mejor dicho), por lo que en numerosas situaciones es preferible utilizar imágenes vectoriales. Por ejemplo, los escritorios de Linux ya están permitiendo emplear iconos vectoriales, de modo que se vean siempre bien definidos independientemente de su tamaño o de la resolución de la pantalla. Existen muchos formatos propietarios, pero, como siempre, para garantizar la interoperabilidad es preferible utilizar estándares, y ese es el formato SVG, que es un lenguaje para describir imágenes y aplicaciones gráficas en XML.

En el mundo web es igualmente interesante poder empotrar imágenes dinámicas generadas mediante SVG. Por ejemplo, hace un tiempo quise hacer unos mapas de densidades de población por municipios generados de forma automática para la Wikipedia. En realidad es muy sencillo. En ese caso podemos partir de una imagen con un objeto por cada término municipal, y mediante un editor de SVG (Por ejemplo, Inkscape) editar las propiedades del objeto y establecer como ID el código postal del municipio. De ese modo, podremos acceder mediante DOM al objeto que representa cada término municipal para posteriormente establecer el color de fondo dependiendo de su densidad (Expresiones regulares al rescate).
Mapa de España por provincias generado utilizando PHP y SVG

Y es que a veces nos complicamos mucho la vida, como por ejemplo dibujando a pelo polígonos sobre la API de Google Maps, cuando incluso podemos empotrar directamente imágenes SVG en un mapa de Google.

A día de hoy, la mayoría de los navegadores permiten visualizar directamente imágenes vectoriales SVG dentro de un documento XHTML, pero como a menudo sucede, Internet Explorer no renderiza de forma nativa SVG. ¿Qué podemos hacer en esos casos? Muy sencillo. Convertir dinámicamente a un mapa de bits. En el caso de PHP no he encontrado ninguna biblioteca o clase que permita la conversión de forma eficaz, sin embargo existen utilidades en la línea de comandos a las que podemos llamar para que realicen conviertan al formato deseado (Como el propio Inkscape o la utilidad convert de ImageMagick).