Una buena guía para sumergirse en HTML5

El libro de Mark Pilgrim Dive into HTML5 tiene una pinta estupenda para empezar a familiarizarse con el nuevo (e inacabado) estándar, y empezar a usarlo en la medida en que algunas de sus novedades ya están soportadas por los navegadores modernos.

Además, el autor hace varias recomendaciones prácticas acerca de cómo utilizar los nuevos elementos y características, dado a la vez soporte a navegadores que aún no las contemplan. Por ejemplo: cómo puedes empezar a utilizar ya los nuevos types del los input en los formularios, o cómo utilizar el elemento video sin dejar de lago el viejo explorer.

Diseño web con HTML y CSS

El título suena a perogrullada, pero en 24 ways han publicado un gran artículo de Meagan Fisher acerca del proceso de diseño de webs usando código y relegando la costumbre de crear los bocetos mediante un editor de imágenes.

Lo cierto es que nunca fui capaz de diseñar una web mediante un editor de imágenes pues lo mío siempre ha sido lápiz y papel, aunque es una práctica muy común abrir el Photoshop o el programa equivalente y trabajar a partir de ahí.

El artículo hace hincapié en las capacidades de HTML y CSS 3, cuyas propiedades más avanzadas empiezan a estar soportadas por los navegadores más importantes, ya sean de la rama Mozilla (Firefox, Flock, Camino), de la Webkit (Safari, Chrome) o de Opera. Así que quitando ese que tú sabes, un navegador moderno permite jugar con propiedades como las sombras, opacidad, tipografía e incluso animaciones.

En ese sentido, es muy interesante visitar css3.info para empezar a familiarizarse con CSS3, conocer el soporte en cada familia de navegadores y cómo usar las nuevas propiedades.

En muchos casos estas propiedades están soportadas todavía como extensiones propias de cada navegador.

Programar en inglés

Hace tiempo alguien preguntó en el grupo google de cakephp en español acerca de la costumbre de programar en inglés y hace un par de días volví a caer en este post de CakeBaker sobre el tema.

Bien, primero habría que explicar lo que entiendo por "programar en inglés". Para empezar, PHP, como tantos otros lenguajes de programación, es una especie de dialecto del inglés. Por programar en inglés, quiero decir usar este idioma para nombres de variables, clases, funciones, comentarios e incluso para los textos iniciales de la aplicación.

¿Y qué razones tendríamos para hacer esto?

Hay algunas bastante prácticas, como las siguientes:

• Siendo PHP un lenguaje basado en el inglés, evitamos mezclar idiomas, lo que hace más fácil la lectura del código.
• Es más fácil compartir código con otros programadores de todo el mundo. Y en consecuencia:
• Es más fácil que otros programadores te puedan ayudar en foros y grupos de correo, etc.
• En CakePHP, específicamente, te puedes evitar algunos problemas con el Inflector cuando intentas añadir reglas para dar soporte a español y otros idiomas y que interfieren con las establecidas por defecto para el inglés.
• En bastantes casos, la jerga técnica en inglés es más completa, expresiva y precisa que en español, por lo que los comentarios serán mucho más informativos. 

Y, la más importante:

• Programando en inglés, pareces mejor programador de lo que eres ;-)

echo "Happy new year!"

Poblar variables de clase a partir de un array

Este código nos permite poblar de valores las propiedades de una clase a partir de un array asociativo cuyas claves tengan el mismo nombre. Es algo así como un extract.

Puede ser útil al pasar parámetros en forma de array asociativo, una práctica habitual en CakePHP.

<?php

class test {

var $prueba;
var $control;

function __construct() {

$array = array(
'prueba' => 'Hola',
'control' => 'amigos'
);
foreach ($array as $key => $value) {
$this->{$key} = $value;
}
}
}

$test = new test();
print_r($test);
?>

Comprobar que un array no es asociativo

Se me ha ocurrido esta función para comprobar que un array no sea asociativo:



function isList($array) {
if (!is_array($array) || count($array) == 0) {
return false;
}
return array_sum(array_keys($array)) > 0;
}


?>

Devuelve true si el array es numérico, y false si no es un array o es asociativo.

En CakePHP puede ser interesante usarlo cuando queremos diferenciar entre los datos devueltos por un read y un find('all'). En el segundo caso, el array es numérico (una clave numérica por cada registro del modelo).

Si los datos vienen de un read (o un find('first')) podemos convertirlos en array numérico con un simple $datos = array($datos), y luego procesar con un foreach. La ventaja es que el mismo código nos vale luego para ambos casos.

Yo voy a usar esta idea para un uploadable behavior en el que estoy trabajando.

Querys CakePHP con operaciones bitwise

Otro de esos títulos "sólo para iniciados"...

Hoy me he encontrado con un problemilla curioso. Necesitaba definir una condición para un find en la que hay una operación bitwise en la base de datos. En concreto, un & de una máscara binaria contra un campo del modelo.

Bueno, pues la forma en que he conseguido que funcione es algo así:

...
array('conditions' => array('12 & Rule.precedence'):
...

Que debe dar un WHERE más o menos así:

WHERE 12 & `Rule`.`precedence`

Es decir, primero pongo el valor de la máscara, luego la operación binaria y luego el campo.

Si pongo primero el campo, CakePHP se empeña en hacer no sé qué y no aparece la comparación en el WHERE.

Obtener el prefijo de una acción (o dividir una cadena)

Esta es una de esas cosas que siempre se me olvidan, así que voy a anotarla.

He aquí una operación típica para romper un string en dos partes, sabiendo que están separadas por un carácter concreto, en este caso el socorrido "underscore".

list($part1, $part2) = explode('_', $string);

Aplicándolo a CakePHP, vamos a imaginar que tenemos el nombre de una acción y queremos saber si tiene prefijo y cuál es. Así que en algún sitio de nuestro Controller (probablemente en el beforeFilter) hacemos:

$action = $this->params['action'];
list($prefix, $actionName) = explode('_', $action);

Sencillo, ¿verdad?

Pero, ¿qué pasa si $action no tiene prefijo y por tanto no hay separador en la cadena?

Bueno, pues en ese caso, $prefix toma el valor de la cadena y $actionName queda vacío, por lo que necesitaríamos el siguiente código para controlar la situación:

$action = $this->params['action'];

list($prefix, $actionName) = explode('_', $action);

if(!$actionName) {
    $actionName = $prefix;
   $prefix = '';
}

Bootstrap para plugins

El archivo APP/config/bootstrap.php de una aplicación CakePHP nos sirve como lugar donde cargar funciones, cargar configuraciones, iniciar variables o definir constantes globales para nuestra aplicación.

Estos días me encontré con la necesidad de disponer de una funcionalidad parecida para los plugins. La idea es interesante, se trata de poder disponer, entre otras cosas, de ajustes de configuración y constantes definidas en los plugins pero que sean accesibles desde otras partes de la aplicación.

La cuestión es cómo hacer ese "bootstrapping" para plugins de forma "automágica".

A mí se me ha ocurrido usar este fragmento de código en el bootstrap de la aplicación

<?php
App::import('Core', 'Folder');
$folder =& new Folder();
$folder->cd(APP . 'plugins');
$files = $folder->findRecursive('bootstrap\.php');
foreach ($files as $file) {
include_once($file);
}
?>

La explicación es bastante sencilla. La clase Folder nos permite apuntar a un directorio, en este caso plugins, y obtener todos los archivos cuyo nombre se ajuste a un patrón grep, cuyos paths se obtienen en un array. Luego no tenemos más que hacer include de cada uno de los archivos y ya tenemos nuestros bootstrapping.

Nota mental: Controller necesita $name

Pues sí, los controladores necesitan tener la propiedad $name, al menos para funcionar en los test, de otro modo se rompe todo. Incluso con PHP 5.

Cosas que hago mal

Dejando aparte errores de sintaxis y algunos fallos lógicos, más o menos normales, he estado pensando que hago algunas cosas mal en mi "estrategia" (por decir algo) de desarrollo.

Una de las principales es que tiendo a centrarme demasiado en lo periférico, con lo cual avanzo relativamente poco en mis tareas, aunque teclee innumerables líneas de código.

Por ejemplo, llevo unos meses trabajando (un poco irregularmente) en el desarrollo de un proyecto que, en principio, será un CMS y la base para una aplicación de Intranet para el colegio en el que trabajo.

Pues bien, he dejado la parte de CMS para el final, y mientras tanto he estado desarrollando módulos auxiliares que, si bien son importantes, no son el objetivo principal de la cuestión. Sólo últimamente he empezado a trabajar en el módulo de contenidos, el cual, en muchos aspectos debería haber sido el primero (o uno de los primeros, ya que también me resulta muy importante el de gestión de usuarios y autorización).

Con todo, no he estado parado, sino que he desarrollado una serie de módulos que aportan gran cantidad de funcionalidad: comentarios, etiquetas, licencias, colecciones, uploads..., pero todavía no hay una aplicación real que esté funcionando. Lo que resulta frustrante.

La cuestión es que desde un punto de vista más "pragmático" lo lógico hubiera sido empezar a desarrollar la parte de gestion de contenidos (dejaré fuera de la cuestión la parte de acceso, que estoy revisitando ahora mismo) y seguramente estos otros elementos hubieran ido surgiendo de forma natural, aportando funcionalidad "avanzada" a la básica.

Mi CMS se estructura en torno a los modelos Channels e Items. Los Channels son canales, que pueden ser blogs, podcasts, photologs o similares. Los Items son los posts, episodios, etc. Si conoces la estructura de los RSS entenderás en qué me he inspirado.

La idea que intento explicar es que probablemente es más eficaz y mejor práctica comenzar por desarrollar una funcionalidad básica "gruesa", sin preocuparse de detalles. Es decir, en este caso, poner a funcionar mis channels e items, perfeccionando luego, de forma iterativa, el sistema añadiendo nuevas prestaciones.

Probablemente eso ayudaría también a mantener una buena motivación a lo largo del trabajo, cosa que en algunos momentos hecho de menos.