En la versión 5.3 de PHP se añadió soporte para una de las características típicas de otros lenguajes como C++ o Java: los namespaces.
Aparte de su uso habitual, los namespaces en PHP ofrecen una funcionalidad que puede ser usada a modo de pequeño truco para reducir los nombres de clase demasiado largos.
Antes de los namespaces las librerías, frameworks... debían asegurarse de no pisar los nombres de clases o funciones de otras librerías que el usuario estuviese usando, por lo que solían añadir prefijos. Por ejemplo, Worpress añade un 'WP_' a sus clases y funciones. Esto en ocasiones genera nombres excesivamente largos rozando el ridículo, siendo un ejemplo clásico el de la clase CaseInsensitive del motor Lucene en el Zend Framework: Zend_Search_Lucene_Analysis_Analyzer_Common_Text_CaseInsensitive.
El pequeño truco consiste en usar los namespaces como accesos directos para acortar el nombre de las clases que nos interesen:
use Zend_Search_Lucene_Analysis_Analyzer_Common_Text_CaseInsensitive as CaseInsensitive; $icase = new CaseInsensitive();
Un pequeño truco muy útil para hacer la vida más sencilla, que resulta obvio en cuanto te lo cuentan. Se puede ampliar información sobre los namespaces con un artículo de introducción a ello en: How to use PHP namespaces de Craig Buckler.
Esta es la historia de uno de esos efectos que tanto nos gustan a los desarrolladores, en los que un cambio del mundo real hace que aplicaciones que antes funcionaban dejen de hacerlo. Como el "efecto año 2000" pero en pequeño y en local.
La CMT ha aprobado y asignado los primeros 200.000 números de móvil que comienzan por 7 para Orange, que los utilizará de forma interna y con sus empleados para hacer pruebas. En el cuarto trimestre de 2011 la CMT abrirá definitivamente las asignaciones de estos números a cualquier operador y cliente. Y a esto hay que añadir que hace ya algún tiempo que se asignan números fijos que empiezan por 8 en lugar de por 9 (al menos Jazztel y Ono ya los asignan).
Y he aquí nuestro pequeño "Efecto 7": hay miles de aplicaciones con formularios donde se puede escribir un teléfono, aplicaciones que validan el número de teléfono... a la antigua usanza, es decir, que comienzan por 6 (móviles) o por 9 (fijos). Por lo tanto, toca revisar y cambiar las validaciones de todas estas aplicaciones. Trabajo de chinos en según que casos.
Hay que revisar y cambiar miles de aplicaciones que validan números de teléfono que comiencen por 6 o por 9
Personalmente, hace ya tiempo que a la hora de validar un teléfono acepto móviles y fijos indistintamente, salvo que el cliente exija distinguirlos y yo no le pueda convencer de lo contrario. Lo hago así porque hoy en día mucha gente (me incluyo) no tiene teléfono fijo, al no ser ya necesario para tener internet en casa y ser suficiente con el móvil para la mayoría de personas.
En mi caso, ya voy cambiando mis validaciones para usar una expresión regular modificada para aceptar estas dos nuevas numeraciones que empezarán a extenderse en unos meses:
^(((\+\d{2,3})|(00\d{2,3}))(\s|\-)?)?([6-9]){1}(\d|\d\s|\d\-){8}$
Esta regexp valida números de teléfono fijos y móviles, que empiecen por 6 o 7 o por 8 o 9 respectivamente. Admite prefijos internacionales, así como separar los números por espacios o por guiones.
Ejemplo de uso desde PHP mostrando posibles números que acepta:
$numeros = array(
'666666666', '666-666-666',
'777 77 77 77', '91 111 11 11',
'+34 888 88 88 88', '0034 999 99 99 99',
'+34-666 66 66 66', '0034 766777777',
'444555666', 'abcdefghi',
'123456789', '9876543210',
'654321', '666 aaa 666'
);
foreach( $numeros as $numero )
echo preg_match('/^(((\+\d{2,3})|(00\d{2,3}))(\s|\-)?)?([6-9]){1}(\d|\d\s|\d\-){8}$/', $numero) ? "\nAceptar: $numero" : "\nNo aceptar: $numero";
echo "\n";
Una de las variables que más afectan a la velocidad de carga de una web es el número y tamaño de achivos Javascript que deben descargarse. Para mejorar esto, se suelen emplear técnicas para comprimir al máximo el código, a la vez que se ofusca para evitar que visitantes malintencionados se lo apropien.
El problema de estos compresores es que obligan a tener dos versiones del código: la "buena", que podemos modificar cómodamente, y la reducida, y nos obligan a tener que ejecutar el reductor-compresor por cada cambio que hagamos en el código, lo cual es poco eficiente y además es un punto de error claro: cambiamos algo pero olvidamos ejecutar el compresor, por lo que el código que subimos a producción no tiene el cambio implementado.
Tras el salto, una solución a este problema, matando dos (o hasta tres) pájaros de un tiro.
Estoy probando CMS Made Simple para un pequeño proyecto que exige un CMS sencillo y rápido de ajustar, y una de las cosas que me encontré nada más instalarlo fue que no tenía URLs amigables.
Tras una rápida búsqueda por el wiki de CMSMS veo que esta opción no aparece en el instalador, y hay que ajustarla a mano. Hay varias recetas sobre ello, pero la que me ha funcionado a mi para la versión 1.8.2 es esta:
Options +FollowSymLinks
RewriteEngine on
# 301 Redirect all requests that don't contain a dot or trailing slash to
# include a trailing slash
RewriteCond %{REQUEST_URI} !/$
RewriteCond %{REQUEST_URI} !\.
RewriteRule ^(.*) %{REQUEST_URI}/ [R=301,L,NE]
# Rewrites urls in the form of /parent/child/
# but only rewrites if the requested URL is not a file or directory
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.+)$ index.php?page=$1 [QSA,NE]
Options +FollowSymLinks
RewriteEngine on
RewriteBase /
# Rewrite for NEWS
# requested URL looks like /news/12/13.html rewrite is
# index.php?mact=News,cntnt01,detail,0&cntnt01articleid=12&cntnt01returnid=13
# first number is article, second is returnid; NC = nocase, L=last (rule)
RewriteRule ^([0-9]*).html$ index.php?mact=News,cntnt01,detail,0&cntnt01articleid=$1 [NC,L]
RewriteRule ^([0-9]*)/([0-9]*).html$ index.php?mact=News,cntnt01,detail,0&cntnt01articleid=$1&
cntnt01returnid=$2 [NC,L]
$config['url_rewriting'] = 'mod_rewrite'; $config['page_extension'] = '/'; $config['use_hierarchy'] = true; $config['query_var'] = 'page';
Listo, ya tenemos URLs amigables funcionando.
En la aplicación que estoy desarrollando actualmente me interesa tener un foro para los usuarios de la aplicación, y para no reinventar la rueda uso un foro phpBB. Lo ideal es que un usuario sólo se tenga que registrar en la aplicación y automáticamente lo esté también en el foro, y que al hacer login y logout en la aplicación web, también lo haga en el foro; además, necesito que el foro sea exclusivamente para los usuarios registrados en el sitio web.
No fue complicado montar el tinglado que me ha permitido cumplir con estas premisas. El cómo hacerlo, tras el salto.
Esta web
http://alvaroremesal.net
, su contenido, texto e imágenes está licenciado bajo una
Licencia Creative Commons Reconocimiento-Compartir bajo la misma licencia 3.0 España.