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.

Las charlas que daré el 6/Marzo/2010 (Argentina)

Como comentaba en un anterior post, a través del Grupo PHP Argentina estamos preparando una serie de charlas abiertas para todos los desarrolladores y empezar a forjar una comunidad sólida de profesionales y mejorar la percepción de nuestra tecnología ("PHP es informal", "PHP no es serio", "Con PHP no se puede", "PHP no es para grandes organizaciones", etc).

Aún se encuentran en preparación las introducciones que expliquen el contenido de cada charla, (por ahora tenemos los títulos generales que aportó cada uno de los organizadores), pero puedo ir comentando las que daré tentativamente el próximo 6/Marzo:

Introducción a POO / UML / PHP5

El objetivo de la charla es abordar los conceptos básicos de la POO para PHP5 y cómo a través de un lenguaje de diseño estándar como UML (muy usado en el ambiente profesional) se debe hacer la traducción de diseños a código PHP5, particularmente entender la importancia de las relaciones entre clases, cómo afectan a nuestros sistemas y corregir un error que la mayoría comete: ubicar correctamente los require_once de cada relación entre clases.


Arquitectura Zend / SURFORCE

Zend Framework es una excelente herramienta para desarrolladores que aún necesitan tener control de los "desarrollos a medida" pero quieren evitar el "desarrollo artesanal". Zend nos ofrece una nueva capa de abstracción que nos permite desarrollar sobre ella, fácilmente, nuevas herramientas de más alto nivel (gracias a que sus componentes están altamente desacoplados).


SURFORCE (empresa) presentará la arquitectura que actualmente está usando para maximizar el reuso de componentes entre sistemas, permitiendo evitar el desarrollo repetitivo de funcionalidades recurrentes, como ser login, gestión de usuarios, administradores, etc, bajo el nombre de SURFORCE_CORE, SURFORCE_LIBRARY y SURFORCE_MODULES (todos proyectos libres bajo la GPL).


Introducción al Estándar de Codificación de Zend

Nadie a esta altura debe dudar de los beneficios de una estandarización en ninguna actividad (organización, disminución de costos y esfuerzos, etc). Pero el problema de los estándares es cuando no existen, no se siguen o existen muchos para seguir (se pierde el concepto de "estándar"). Para el mundo Java la empresa SUN es el pilar que define los lineamientos generales y ningún desarrollador duda en no seguirlos. De la misma forma, la empresa Zend (de donde vienen la mayoría de las mejoras de PHP) debería ser nuestro referente y nosotros los desarrolladores deberíamos seguir el estándar de codificación Zend.


Así que no se olviden de ir votando las charlas y estar al tanto de todos los medios de comunicación que iremos notificando los avances y cualquier novedad.

Te esperamos, a ver si los desarrolladres PHP nos juntamos y empezamos a trabajar para formar una verdadera comunidad que nos benefice a todos ;-)

Breve resumen de la segunda reunión del Grupo de Usuarios PHP Argentina


Voy a tener que optar por "publicar algo breve" a "no publicar", ya que de lo contrario voy a escribir un post por mes, y nunca fue mi idea :-(. Creo que la mayoría sabrá que cuando inician los cursos que estamos dictando a través de surforce.com empiezo a estar un poco desbordado de trabajo y concentrarme casi exclusivamente a los alumnos.


Así que bueno, quería hacer un resumen más completo de la reunión que hicimos el sábado pasado, pero aquí van los titulares:
  • Nos reunimos varios desarrolladores PHP con las mismas inquietudes para tratar de "hacer algo por la comunidad PHP", particularmente promover nuestra tecnología y consolidar una organización que nos nuclee.
  • Algo que nos preocupa a todos es que muchos desarrolladores / empresas consideran a PHP como una "tecnología poco seria", por lo que queremos trabajar en ese sentido para cambiar radicalmente esa percepción a través de charlas.
  • Ya lo veníamos hablando en la primer reunión, empezar con charlas informativas, y para ello debíamos buscar un lugar para hacerlas. Tenemos algunas ideas, oficinas ofrecidas de algunas empresas, hasta universidades (aún no tenemos una confirmada).
  • Fijamos la fecha de mejor conveniencia para todos, el sábado 6 / Marzo.
  • Estamos tratando de pulir la idea general, si es una serie de charlas informales, o tendrá más perfil de jornada ó conferencia (por ahora se puede decir que va primando la primera).
El temario general de charlas introductorias se pasará en limpio y publicará en el sitio oficial, por ahora los títulos que más les interesen se pueden votar, para ver si dejamos alguna afuera, o cómo priorizamos el orden de las mismas. La idea es que dentro de unos días todos los que quieran ir a las charlas confirmen su lugar para que nos podamos organizar con tiempo en base al público que participará.




Se está discutiendo el tema de armar podcasts o videocast o streaming, aún no está definido si contamos con la infraestructura y organización suficiente como para hacerlo.


Para más información, tienen el sitio web "oficial" del grupo en grupophp.com.ar (en la página pueden extraer información sobre otros medios, como foro de discusión, twitter, facebook, etc).


¡Así que esperamos su participación!

PD: todas las demás fotos se encuentran en el grupo de facebook.

Segunda "PHP Meeting Argentina" - Sábado 30/1 - 10hs

Para quienes estén por Buenos Aires y quieran unirse a nosotros y organizar la comunidad PHP local, nos estaremos juntando este próximo sábado en la segunda "PHP Meeting" (aquí la primera).

Fecha: Sábado 30 de Enero
Hora: 10:00 (AM) hasta el mediodía.
Lugar: Tronador 2650 3 B (en las oficinas que nos ofrece un colega)


Ver mapa más grande

Aquí les muestro un posible camino desde Cabildo y Juramento (una zona conocida, pueden llegar en subte línea "D", bajar en la estación "Juramento" y posteriormente tomar un taxi). Pueden consultar también http://mapa2.buenosaires.gov.ar/ que está muy completo y en la sección de "cómo llegar" muestra todos los colectivos posibles y sus recorridos (Google, aún te falta ;-))

Nos concentramos en 2 horas concretas para tratar todos los temas de la comunidad y finalmente hacer algunas charlas semi-informales de los temas que cada uno quiera presentar.

Están todos invitados ;-)

Presentación: "Frontend. Principios básicos. Una guía de estilo y fundamentos web"

Me encontré por accidente revisando unos foros de linkedin. Aunque algunos puntos pueden ser discutibles, si no tienes alguna referencia clara sobre el tema, esta presentación me parece una buena guía para empezar.

¡Iniciamos inscripciones para los cursos Febrero 2010!

Damos oficialmente el anuncio de apertura de inscripciones para los cursos y talleres que iniciarán el 1ro de Febrero de 2010!

'Cursos Abiertos' <> 'Cursos Intensivos'

Les comento que los 'cursos abiertos' se van armando de forma libre a medida que los alumnos se van registrando. Si sobre la fecha de inicio del curso no se llegó al cupo mínimo de 10 alumnos, se postergará una semana el inicio del curso. En caso de superar el máximo de 20 alumnos, se abrirá un único segundo grupo a la semana siguiente. El próximo período de cursos se abrirán recién a partir de Marzo 2010 (fecha a confirmar).

Todos los cursos tienen una duración promedio de 2 meses, pero existe la posibilidad de armar grupos INTENSIVOS y REDUCIDOS de 1 mes de duración (a un costo mayor).

¡Promoción!

Es de público conocimiento que hace 3 años que los precios de los cursos se han mantenido invariables, por lo que este año aumentarán los 'cursos abiertos' de USD 50 a USD 60. Pero, a modo de promoción, quienes se inscriban durante esta semana (plazo hasta el domingo 24/1), lo podrán hacer a precio congelado! (luego no se aceptarán reclamos ;-)).

¡No pierdas tú lugar! Accede a usuarios.surforce.com e ingresa a la sección COMPRAR.

Toda la información sobre los cursos en surforce.com

Saludos! ;-)

Enrique Place

SURFORCE TEAM
www.surforce.com

Sobre la "complejidad de los diseños" ...

"Me cansé de advertir sobre los riesgos de la ambiguedad, la complejidad y la ambición desmedida de los nuevos diseños, pero nadie escuchó mis consejos. He llegado a la conclusión de que existen dos formas de construir un diseño de software: simplificándolo hasta el punto que resulte obvio que no hay en él errores o complicándolo de tal forma que los errores que haya en él no sean tan obvios".


Tony Hoare, Turing Award Lecture, 1980 (refiriéndose al diseño del lenguaje Ada).

Para los que me preguntan constantemente sobre la "optimización"

"Las reglas de la optimización son sencillas.

Regla 1: No optimices.

Regla 2 (solo para expertos): No optimices todavía."

Michael A. Jackson


Comparto 100% ;-)

¡Pregúntame lo que quieras!

Cómo lo comentaba en mi blog personal, estoy probando el nuevo servicio formspring.me, en el cual de forma muy sencilla (una de las razones del éxito de estos proyectos: utilidad + simplicidad) pueden hacerme pregunta de los temas que quieran, los cuales responderé con gusto ;-)



Sigue todas las preguntas y respuestas

Entradas populares