En este post veremos como programar tareas en linux (servidores, máquinas personales, etc.) usando crontab.

A veces es necesario correr procesos en el background en los servidores web, tales como generar thumbnails o calcular data para la base de datos, etc. Corriendo estos procesos en el background no interferimos con la interfaz del usuario. Linux tiene un gran programa llamado cron. Este programa permite correr procesos automáticamente en intervalos regulares. Además, podríamos usarlo para automáticamente crear backups, sincronizar archivos, programar actualizaciones, y mucho más. Para todo esto contamos con crontab.

Crontab
El comando crontab es utilizado en sistemas Unix para programar otros comandos para ser ejecutado periodicamente. Para ver que crontabs están actualmente corriendo en nuestro sistema, púedes abrir un terminal y correr:

root@mylinux:~$ sudo crontab -l

Para editar la lista de crontabs podemos correr:

root@mylinux:~$ sudo crontab -e

Este comando abrirá nuestro editor por defecto para dejarnos editar el crontab. Si editas y sales del editor, todos tus cronjobs son guardados dentro de crontab. Los cronjobs son escritos siguiendo el siguiente formato:

 * * * * * php /var/www/hasheado/script.php

Explicando el formato
Como podemos ver en el comando de arriba hay 5 asteriscos. Los asteriscos representan diferentes partes de la fecha en el siguiente orden:

• 1. minutos (desde 0 a 59)
• 2. hora (desde 0 a 23)
• 3. día del mes (desde 1 a 31)
• 4. mes (desde 1 a 12)
• 5. día de la semana (desde 0 a 6) (0 = Domingo)

 

Ejecutando el comando a cada minuto
Si dejamos los asteriscos significa "cada". usemos el ejemplo anterior:

 * * * * * php /var/www/hasheado/script.php

Esto significa que ejecutaremos el script /var/www/hasheado/script.php:

• 1. cada minuto
• 2. cada hora
• 3. cada día del mes
• 4. cada mes
• 5. cada día de la semana

 

Espero que les sea de utilidad, crontab es mucho más poderoso, y espero en la brevedad escribir un poco más acerca de esto.

Fuente: Kevin Vanzonneveld's blog

El equipo de Symfony2 ha decidido retrasar un poco la versión final del esperado framework.

El equipo principal de desarrollo de Symfony2 ha decidido retrasar la release final del esperado framework, fué una decisión difícil de tomar pero piensan que no hay necesidad de apurar la release de Symfony2 (estoy de acuerdo con eso :-)). De hecho, piensan que es una buena noticia, debido a que durante los últimos meses más y más desarrolladores se han unido al equipo de Symfony2; dándole muy buen feedback que como resultado tiene una gran actividad en el repositorio de Git durante las últimas semanas. Por ejemplo, se han realizado merges de más de 300 pull y más de 150 diferentes desarrolladores han contribuido de una u otra manera con el framework. Toda esta contribución es fantástica, pero significa que el equipo de Symfony2 necesita un poco más de tiempo para estabilizar todos los cambios que se han hecho últimamente.

La arquitectura principal es ahora estable, excepto por unos pocos cambios en la convención de naming que será completada en los siguientes días. Esto es realmente importante para que el equipo de desarrollo este confiado que la arquitectura principal de Symfony2 es lo suficientemente flexible para mantener compatibilidad hacia atrás en los pŕoximos años.

Como todos sabemos, todos estamos impacientes y queremos jugar con el framework. Por esto, la release previa número 9 ya está disponible para descargar. Además, la documentación ha evolucionado rápidamente documentando la versión principal del framework.

Entonces, porqué el equipo de desarrollo no libera la primera Beta? porque están esperando por la última gran modificación que posiblemente será mergeada prontamente: el refactor del framework de formularios. La primera Beta será liberada luego de tomar la decisión de realizar el merge de esta última refactorización o no. Entrar a una versión Beta significa que las principales features del framework estarán disponibles. Esto no significa que no se romperá la compatibilidad hacia atrás aquí y allá, pero todos esos cambios serán documentados para fácil migración.

Por lo tanto, más allá de que todos estemos esperando la versión final de Symfony2 y esta ha sido retrasada, hay buenas noticias. Ya que es mejor tener algo perfecto un poco más tarde que tener algo incompleto con anterioridad.

Fuente: Synfony's blog

Resúmen de behaviors en Symfony y Doctrine, los cuales resultan útiles en el uso cotidiano.

La idea de este artículo es dar un resúmen de los behaviors de Doctrine (herramientas muy útiles), los cuales aceleran significativamente el desarrollo de las aplicaciones. En el artículo encontrarás breve descripciones de los behaviors más importantes con links a su documentación.

Basicamente, un behavior te dará algunas relaciones, algoritmos y otras características entre los objetos del modelo de tu proyecto. Ellos son (o deberían de ser) muy configurables: dándote un mecanismo que pueda ser facilmente configurable para acordar con diferentes proyectos. La configuración de estos incluye: activar/desactivar algunas de las características del behavior, renombrar algunos atributos adicionales del schema, etc. Puedes usar un monton de behaviors de Doctrine en tus proyectos, puedes usar los core behaviors, los Doctrine extensions behaviors, los plugins de Symfony, o bien, puedes crear tu propio behavior.

Core Behaviors

Doctrine ya viene con varios behaviors (llamados core behaviors), estos son:

• # Versionable - agrega una tabla XXXVersion para almacenar tus versiones del objeto XXX, para mantener un versionamiento de tus objetos.
• # Timestampable - este probablemente sea el behavior más popular, agrega las columnas de tipo timestamp created_at y updated_at a tu modelo, y automáticamente guarda la fecha cuando un registro es guardado o editado respectivamente.
• # Sluggable - agrega una columna slug que almacena un slug el cual es único y puede ser usado por sfDoctrineRoute para referirse a un objeto sin pasar el ID como parámetro; por defecto la opción de update esta desabilitada.
• # I18n - agrega una tabla XXXTranslation para proveer Internationalization (I18n) a tu XXX modelo, es behavior es esencial para cuando se desarrollan proyectos multi-lenguaje.
• # NestedSet - agrega las columnas root_id, lft, rgt y level a tu modelo para desarrollar una estructura de datos jerárquica (estructura de árbol, como categorías-subcategorías).
• # Searchable - elige las columnas de tu modelo que quieres indexar y agrega una nueva tabla, acelerando el desarrollo de motores de búsqueda.
• # Geographical - agrega las columnas longitude y latitude almacenando coordenadas geográficas, además te provee de un método getDistance() para calcular la distancia entre 2 objetos geográficos.
• # SoftDelete - agrega una columna deleted_at la cual define si un registro ha sido marcado como borrado (y cuando). Es un behavior útil cuando se diseñan sistemas con importante consistencia de datos.

Extension Behaviors

Además puedes utilizar las extensiones de Doctrine:

• # Blameable - agrega un nivel adicional para auditar tus modelos, te permite llevar un seguimiento de quien ha creado o actualizado cualquier modelo en un entorno con muchos usuarios.
• # EventLoggable, readme - guarda un log de cualquier evento de Doctrine (pre/post Delete/Insert/...) usado por un registro.
• # Localizable - te da la funcionalidad de convertir unidades de medidas (por ejemplo, de kilometros a millas) o cualquier otra conversión deseada.
• # Locatable - te da la funcionalidad de usar Google Maps para automáticamente rellenar tu modelo con información de latitud y longitud usando Google, una gran herramienta para usar con sfEasyGMapPlugin.
• # Sortable - le da la funcionalidad de ordenamiento a tus modelos.
• # Taggable - agrega capacidades de Tagging, crea una tabla TaggableTag y una XxxTaggableTag por cada modelo taggablel, usando relaciones refClass m:n, provee una fácil administración de los tags: agregar, borrar, borrar todo, etc., finalmente, te da la posibilidad de obtener los tags más populares (para una nube de tags, por ejemplo).

Plugin Behaviors

Finalmente, existen plugins de Symfony que nos dan más behaviors:

• # sfDoctrineActAsSignablePlugin - una buena alternativa para la blameable Doctrine extension.
• # sfDoctrineActAsTaggablePlugin - provee administración de tags (es una alternativa para taggable Doctrine extension), y provee la generación de una nube de tags.
• # csDoctrineActAsAttachablePlugin - asocia varios uploads con múltiples modelos.
• # sfDoctrineJCroppablePlugin - agrega imagenes user-croppable a tus modelos con un javascript image cropper.
• # sfDoctrineNestedSetPlugin - un formulario y un validator dandonos fácil administración de NestedSet behavior.
• # csDoctrineActAsCategorizablePlugin - Categoriza tus modelos, mix, match ó separa multiple modelos dentro de múltiples nested/flat categorías.
• # sfDoctrineActAsRattablePlugin - da puntuación a objetos de Doctrine.
• # vjCommentPlugin - provee commentable behavior para comentar nuevas páginas, artículos, etc.

 

Fuente: symfony-world.blogspot.com