Ejecución de scripts en modalidad "batch" y validar sintaxis

Muchas veces necesitamos correr procesos "batch" que se ejecutarán a determinada hora desde un cron (unix/linux) y no tienen ningún tipo de interacción con el usuario, a lo sumo, generarán un reporte de resultados del proceso en un log. Este tipo de procesos pueden ser tan variados como respaldos, transferencias de datos entre sistemas, envío masivo de mails a la base de usuarios, etc.

Por ejemplo:


30 13 * * *  enrique php /var/www/batch/sincronizarBases.php &>/dev/null

Aquí se ve la ejecución para el usuario enrique, el cual llegada las 13:30 hs ejecutará el comando php /var/www/batch/sincronizarBases.php y toda la salida de mensajes internamente será redireccionada a un archivo de log.

También se puede evitar tener que llamar desde consola el comando php y decirle internamente que el ejecutable es el binario de php, además de tener que darle permisos de ejecución al archivo en cuestión (chmod +x ), por lo que la invocación quedaría así (sin la invocación de php):

 30 13 * * *  enrique /var/www/batch/sincronizarBases.php &>/dev/null

y la primera línea de nuestro scripts debería ser:

#!/usr/bin/php -q

// código fuente

Bien podríamos usar otro tipo de lenguaje o simple scripting bash, pero tener todo un sistema desarrollado en PHP permite luego reusar componentes o clases dentro de estos scripts "batch", así que bien podemos seguir usando nuestro lenguaje base de desarrollo.

Como último detalle que quería comentarles, es que amén que siempre hay que probar todo en consola antes de agregarlo al crontab, sucede que si bien sabemos que funciona todo correctamente, a veces tenemos que hacer modificaciones al scripts y que probablemente luego no nos tomamos el trabajo de volver a revisar nuevamente. Para estas situaciones les dejo un pequeño "tips" que puede ser de ayuda con errores básicos que nos pueden suceder sin darnos cuenta:

Luego de editar nuestro fuente, podemos verificar la sintaxis básica del código, evitando por lo menos no cometer un error en algun ";" o similar (obviamente, esto no asegura que no hayamos cometido un error de lógica):

php -l sincronizarBases.php


No syntax errors detected in sincronizarBases.php

En caso contrario

Parse error: syntax error, unexpected T_INCLUDE in sincronizarBases.php on line 33
Errors parsing sincronizarBases.php 


Espero que les sea de utilidad ;-)

¿tienen alguna sugerencia más o experiencias en estos temas que quieran compartir?

[screencast] Cómo usar Zend Framework en Netbeans 6.9

Hace un buen tiempo que vengo usando Netbeans como IDE "todo terreno", tanto para PHP5 puro como para desarrollar bajo Zend Framework. Si bien usar Zend bajo Netbeans no aportaba ninguna ayuda especial, es muy bienvenido que lo hayan incorporado ahora con la nueva versión (ya puedes bajar la versión 6.9 Beta, en pocos días ya estará la versión final).

Aquí una explicación de los primeros pasos para sacarle el máximo de provecho:



¿y tú, ya lo probaste? ;-)

[SVN] Resolución de conflictos usando un IDE (Netbeans)

Dicen que una imagen vale más que mil palabras, así que me pareció bueno mostrarles algo que es relativamente "común" que suceda en un proyecto, y es, que existan conflictos entre las modificaciones de uno o más desarrolladores, muchas veces por modificar las mismas líneas de código en el mismo lapso de tiempo.

Los sistemas de versionado, si bien se encargan de mantener sincronizado un proyecto donde pueden trabajar muchas personas, en determinados casos no puede hacer "magia" y cuando se dan los conflictos (porque no sabe qué líneas deben quedar como definitivas) nos deja a nosotros la responsabilidad de decidir qué hacer.

En este caso veremos cómo luego de trabajar sobre un fuente, al intentar hacer un commit el IDE (en este caso Netbeans for PHP) me avisa que ya existieron cambios en el repositorio SVN, y que luego de hacer mi actualización local (update) me reporta que hay "conflictos" con los cambios.

Por lo general, usemos o no un IDE, ocurrirá lo siguiente:

• nuestro fuente quedará marcado en las líneas que ocurrieron el conflicto (por lo tanto si estamos ejecutando este fuente, ahora dejará de funcionar y dará error de sintaxis)

• y 3 archivos más, con la información de las líneas del problema (.mine, .r198 y .r241, estos últimos hacen referencia a las líneas del conflicto).

 En el caso de Netbeans (aunque en Eclipse es muy similar), nos posicionamos sobre el fuente en cuestión, botón derecho, Subversion > Resolve Conflicts... y nos desplegará la siguiente interfaz

Mostrando en la parte superior ambos archivos, la versión local (izq) y la versión remota (der), y sobre cada una de ellas hay un botón de "Aceptar" para que nosotros decidamos cual de las dos se queda (descartando la opuesta) y podremos ver cómo va quedando la versión final en la parte inferior central.

Aquí podemos visualizar cómo se vería si aceptáramos la versión del lado derecho (versión remota)

Al finalizar de responder cual versión del conflicto queremos dejar nos preguntará si queremos finalmente salvar todos los cambios y marcar el archivo como "resuelto".

Y conflicto solucionado, ahora podemos seguir adelante, no sin antes volver a charlar con el equipo de desarrollo para tratar de evitar estos problemas a futuro.

Saludos! ;-)

PHP Namespace Support in NetBeans IDE 6.8

Interesante cómo va creciendo poco a poco las funcionalidades de Netbeans para PHP y cómo ya se asoma el soporte de PHP 5.3, como así también soporte para diversos frameworks PHP. Para tener en cuenta ;-)

Video de la charla: "Introducción a POO / UML / PHP5"

Lo prometido es deuda ;-). Ya se encuentran disponibles los videos de todas las charlas que hicimos a través del Grupo PHP Argentina el Sábado 6/Marzo en el Hotel Las Naciones, Corrientes 818 1º, Capital Federal.

No más palabras, aquí la charla (sí, casi no se me veía, luego se corrigió en las demás charlas ;-))

Presentación

Quiero aclarar algunos detalles sobre el contexto de la charla, ya que recibí algunas críticas (que las acepto):

• Estaba saliendo de una gripe, por lo que me era difícil hablar mucho tiempo sin parar de toser, pero bien pude hacerlo, aunque al final de la charla me vino un ataque de tos por espacio de 5 minutos ;-)
• Razón por lo que la charla fue rápida y casi sin pausa (que generalmente es todo lo contrario, me gusta interactuar y que me interrumpan), ya que no sabía si iba a tener que suspenderla (cosa que no sucedió).
• Trato de ser "duro" para generar polémica y que posteriormente se hable de estos temas fuera de la charla misma, algo que creo sucedió ya que recibí muchos comentarios sobre el tema ;-)
• Estoy hablando particularmente de PHP 5.2, esta charla cambiaría si estábamos hablando de 5.3
• No quiero decir que los autoloads no sirvan para nada, simplemente que prefiero que los desarrolladores se acostumbren a medir las consecuencias de relacionar las clases, y que si hacemos todo "automático", muchas veces ayudados con los autoloads, nuestro sistema saldrá muy perjudicado. Las relaciones se planifican antes y durante el desarrollo del sistema, no es "porque la tengo disponible, la uso"... así no se hacen sistemas POO.
• De todas formas, prefiero dar charlas concretas, directas y breves, y que el auditorio quede con ganas de más a que se aburran o saturen. Además, éramos varios oradores y no sabíamos si nos daba el tiempo para todos (varias razones para suspender mi segunda charla).

Espero todos sus comentarios, dudas o críticas ;-)

Primera versión presentación realizada en las charlas del Grupo PHP Argentina

Introducción a UML / POO / PHP5

View more presentations from Enrique Place.

Este sábado pasado hice una rápida charla de 24 minutos(a pesar de mi gripe y mi posibilidad de empezar con un ataque de tós durante la misma ;-)). La idea es que luego estará diponible todo el audio de la misma, y posteriormente veré de complementar con textos esta presentación para que sea más fácil de seguir.

Pronto, más novedades! ;-)

Fotos desde las charlas del Grupo PHP Argentina!

[confirmado] Primeras charlas del Grupo PHP Argentina - 6/3/2010

Primeras charlas GrupoPHP 

Sábado 6 de Marzo, 2010 a las 9:30 AM 

Hotel Las Naciones, Corrientes 818 2º piso 

 Ver Agenda - Inscripción Obligatoria - Banners promocionales

 

Cambio de opinión: en algunos casos acepto el uso de null == $var

Hace un tiempo hice un extenso post comentando sobre el "difundido fanatismo" de algunos desarrolladores de usar al revés las condiciones de igualdad en un if , en mi opinión "contranatura", sin respetar como alguna vez nos enseñaron nuestros primeros docentes (ver artículos como "Código como documentación"):

if ($variable == "valor")

Por lo que este orden nos permite hacer una redacción natural de la lógica que estamos codificando, es decir:

if ($edad == 30)

Se traduciría como

"Si la edad es igual a 30"

Por lo que actualmente hay una "seudo-moda" de hacerlo al revés,

if (30 == $edad)

Se traduciría como

"Si 30 es igual a edad"

Algo que, luego de haber pasado algunos años dando clases a distintos niveles de desarrolladores, empezando por personas con cero conocimiento del tema, siento que esta práctica no hace más que dificultar la lectura natural de las condiciones, y en consecuencia, ofuscar el código.

Amante de lo simple como soy (considero que el verdadero arte y esencia de la programación es hacer las cosas simples, no complejas), me opuse completamente a esta práctica, aún con los argumentos técnicos de que esta técnica podría salvarnos en caso de asignaciones accidentales del tipo:

if ($edad = 30)

Lo cual en PHP terminaríamos modificando el valor de $edad (porque estamos usando un solo "=" y no dos), algo que no sucedería si hiciéramos

if (30 = $edad)

De todas formas me pareció exagerado al extremo, cambiar algo que se hizo por años, desde los inicios de los tiempos, solo para cubrir esta "hipotética situación tan poco probable", ni que hablar que todo IDE respetable nos detecta este error y es fácil de ver y corregir.

Bien, suerte que gracias a los errores uno aprende y me pasó hace relativamente poco este error con consecuencias bastante importantes, por lo que voy a describir en qué situación SI sugiero esta práctica (no siempre, no con todo el código):

• Si por una razón extrema tienes que modificar código en producción
  

• y además no puedes usar un IDE que te asista, y tienes que usar un editor sin asistencia en la codificación (como el Editplus, Notepad++, etc)

Sí, y solo sí, mientras tengas que alterar o agregar una condición que pueda generar este error, invierte la condición para estar cubierto ante cualquier distracción. Pero luego de hecho, fuera de producción, corrige el código, para clarificar su entendimiento.

De todas formas, lo veo complicado de hacer si no estás acostumbrado a ello.

Pero bueno, cuando me sucedió me hizo reconocer que había una situación muy específica que podría ser aplicable y útil, aún para una persona con experiencia como yo ;-)

¿Alguna vez te fue verdaderamente útil esta práctica? ¿alguna otra?

[SVN] Agregar notificación por email en caso de cambios en el repositorio

Esto es muy productivo en cualquier equipo de trabajo, recibir notificación por email de cada vez que ocurre un cambio en un repositorio de un proyecto donde estés trabajando, esto permite tener a todo el equipo notificado y coordinado con los cambios, y en caso de problemas poder detectarlo rápidamente (se tocó un archivo que no correspondía, un error, cambio no planeado, etc). También permite aumentar el contro de calidad si esto es revisado por el teamleader (o un responsable de QA) que revise si se cumplen los criterios de calidad prefijados.

Les dejo la configuración que hay que hacer en el hosting dreamhost.com, pero que también pueden aplicar en vuestros servidores:

En el directorio del proyecto SVN tienen que buscar el subdirectorio hooks, y copiar el archivo de ejemplo post-commit.tmpl como post-commit (donde agregaremos todas las acciones que queremos que ocurran una vez que existan un commit):

#!/bin/sh

REPOS="$1"
REV="$2"

/usr/share/subversion/hook-scripts/commit-email.pl --from info@surforce.com "$REPOS" "$REV" desa1@gmail.com desa2@gmail.com desa3@gmail.com

Y listo, ahora luego de que cualquier desarrollador haga un commit, nos llegará a todos un email con un diff con los cambios realizados, por ejemplo:

Author: alejandro145
Date: 2009-12-04 14:49:01 -0800 (Fri, 04 Dec 2009)
New Revision: 16

Modified:
public/js/jquery/ui/themes/ui-

lightness/ui.datepicker.css
Log:
Cambia el tamaño del widget para elegir fechas

Modified: public/js/jquery/ui/themes/ui-lightness/ui.datepicker.css
===================================================================
--- public/js/jquery/ui/themes/ui-lightness/ui.datepicker.css 2009-12-04 21:48:09 UTC (rev 15)
+++ public/js/jquery/ui/themes/ui-lightness/ui.datepicker.css 2009-12-04 22:49:01 UTC (rev 16)
@@ -1,5 +1,7 @@
/* Datepicker
----------------------------------*/
+.ui-widget.ui-datepicker { font-size:.8em }
+
.ui-datepicker { width: 17em; padding: .2em .2em 0; }

Las líneas agregadas aparecen a la izquierda con un "+" o un "-" si estas son eliminadas.

Que les sirva de referencia para su trabajo en equipo ;-)

PD: por las dudas, ya que es un error que he cometido seguido, el scripts tiene que tener permisos de ejecución (confunde muchas veces que el ejemplo .tmpl no tenga permisos de ejecución, y uno viene y lo copia directamente y piensa que es solo cambiar el contenido), ya que es SVN lo tiene que ejecutar.