Servicios haldaemon y pcscd no arrancan en Fedora 14

Hace poco mi Fedora empezó a mostrarme un mensaje de error al arranque: los servicios haldaemon y pcscd no arrancaban. En la práctica esto no permite cargar ciertos dispositivos en el entorno gráfico (p.e.: la unidad de DVD) y no muestra los rostros en la pantalla de login de entorno gráfico.

Culpé a la última actualización y estuve a punto de 'desactualizar' los paquetes, pero decidí hacer una búsqueda en Mr Google primero. Finalmente encontré este post en el que dicen que la razón de este error se debe a borrar el contenido de /var/cache y recordé que efectivamente había hecho eso porque pensé: "Hey, para qué quiero toda esa basura en la caché". Pues grave error, no lo hagan.

La solución fue ejecutar:

yum -y reinstall hal

Con esto tanto haldaemon como pcscd inician ahora correctamente y los dispositivos se pueden cargar en el entorno gráfico, sin embargo las foticos no salen en la pantalla de login :( pero como no es crítico no he hecho nada para solucionarlo.

Comando para encontrar archivos de forma recursiva buscando por una cadena de texto

Este es uno de mis comando favoritos. Usando la habilidad de find para ligarse con otro, en este caso grep, podemos buscar en un directorio por todos los archivos que contengan cierta cadena de texto:

$ find ruta_directorio -exec grep -li 'texto' {} \; -exec grep -ni 'texto' {} \;

En el primer grep usamos -l para listar los archivos, en el segundo usamos -n para mostrar la línea en la que está la ocurrencia del texto.
La opción -i sirve para ignorar diferencia entre mayúsculas y minúsculas.

Yo suelo usarlo filtrando el tipo de archivo:

$ find ruta_directorio -name "*.php" -exec grep -li 'texto' {} \; -exec grep -ni 'texto' {} \;

Simplemente maravilloso!

sfGuard no funciona al copiar o exportar el proyecto

Si al copiar o exportar el proyecto, este plugin no funciona, incluso si funciona bien el entorno de desarrollo; tal vez dando un error como:

500 | Internal Server Error | Doctrine_Record_UnknownPropertyException
Unknown method SfGuardUser::checkPassword

Es muy probable que se deba al haber generado el archivo schema.yml a partir de la base de datos existente DESPUÉS de haber instalado el sfGuard. Al hacer esto se duplican las clases cuando se usan los subcomandos de symfony doctrine:build-model, doctrine:build-form y doctrine:build-filter o doctrine:build --all. Los nuevos archivos creados tienen nombre con formato *SfGuard*.php, a diferencia de los que vienen con el plugin cuyo formato es *sfGuard*.php (con 's' minúscula).

La solución es:

Tips sobre internacionalización en symfony

Cuando trabajemos en una aplicación en la que necesitemos algo de internacionalización (i18n), es bueno tener siempre presentes un par de cosas (que por cierto podemos encontrar en la documentación oficial):

• La internacionalización no es posible sin un usuario. Cuando el website está disponible en varios idiomas o regiones del mundo, el usuario es el responsable de escoger aquel que se le ajusta mejor.
• Durante el desarrollo, puede sorprenderse de ver que un cambio de cultura en el archivo settings.yml no cambia la cultura actual en el navegador. Esto es porque la sesión ya tiene una cultura de páginas anteriores. Si quiere ver la aplicación con la nueva cultura debe limpiar las cookies del dominio o reiniciar el navegador.
• Para ver los cambios en textos traducidos, hay que limpiar la cache de symfony.

Corregir error "Class XxxFormFilter not found" en symfony

Si al trabajar en nuestro proyecto, nos encontramos con un error como este:

Fatal error: Class 'XxxFormFilter' not found in ...

Seguramente se debe a que cambiamos nuestro esquema y no actualizamos todos los componentes importantes (model, forms, filters). Así que habrá que reconstruirlos todos, ya sea uno por uno:

./symfony doctrine:build-model
./symfony doctrine:build-forms
./symfony doctrine:build-filters

o todo a la vez:

./symfony doctrine:build --all-classes


Corregir advertencia de función date() de php en symfony

Si al ejecutar comandos o aplicaciones de symfony se obtiene el siguiente mensaje:

Warning: date(): It is not safe to rely on the system's timezone settings...

Hay que editar el(los) archivos de configuración php.ini del sistema y agregar la siguiente línea especificando la zona a usar por defecto.:

date.timezone = America/Bogota

Para conocer la zona apropiada, el mismo mensaje de advertencia ofrece la zona que usó para ejecutar la función que da el problema, y si el sistema está correctamente configurado, podemos usar esa zona. Si no aparece o si se quiere cambiar, hay un listado de zonas válidas en http://nl3.php.net/manual/en/timezones.php

El comando symfony no muestra mensajes con resaltado en color

Una forma de forzar el resaltado con color en la línea de comandos (CLI) con symfony es usar la opción color, por ejemplo:

./symfony doctrine:build --all --color

Pero eso es algo engorroso. Este pequeño error seguramente se debe a que hace falta instalar la extensión posix de php, para estar seguros habrá que ejecutar el script check_configuration.php que nos ofrece symfony para conocer el estado de nuestra instalación:

php lib/vendor/symfony/data/bin/check_configuration.php

Si es así veremos una línea como esta:

[[WARNING]]         The posix_isatty() is available:  FAILED

Así que habrá que buscar este paquete en el repositorio de nuestra distribución. En Fedora 14 la extensión php_posix (usada por Symfony para dar resaltado de colores en la CLI) se instala dentro de la extensión php-process.

yum install php-process

Y listo! Ya veremos bonitos colores en nuestra línea de comandos con symfony.