A veces sucede que debemos llenar una tabla con cientos de miles de registros para probar el rendimiento de una aplicación, de modo que no tengamos sorpresas el día de mañana cuando la base de datos crezca mucho. Por lo general los registros se llenan con información al azar y para eso hemos creado una función que genera fechas al azar dentro de un rango establecido.

	function random_date($from = 0, $to = null) {
		if (!$to) {
			$to = date('U');
		}
		if (!ctype_digit($from)) {
			$from = strtotime($from);
		}
		if (!ctype_digit($to)) {
			$to = strtotime($to);
		}
		return date('Y-m-d h:i:s', rand($from, $to));
	}

PHP: Cómo saber si existe o está definida una función

Usamos function_exists. Ejemplo:

if (function_exists('example_function')) {
	example_function($arg1, $arg2);
}

PHP: Cómo saber si un método de una clase existe o está definido

Usamos method_exists. Ejemplo:

$l10n = new L10n();
if (method_exists($l10n, 'translate')) {
	$translated = $l10n->translate('word');
}

Javascript: cómo saber si una función o método existe o está definida

Javascript no hace distinción entre funciones y métodos, ya que todas son funciones. La forma de hacerlo es:

if (typeof functionName == 'function') {
	functionName();
}

Caso especial: jQuery

En el caso de jQuery la forma de saber si un método está definido es mediante jQuery.fn.nombreFuncion. Ejemplo:

if (typeof jQuery.fn.tinymce == 'function') {
	$('textarea').tinymce();
}

Trabajando en optimización de performance de una aplicación CakePHP noté que una consulta SQL se estaba ejecutando más de una vez, siempre igual y devolviendo el mismo resultado.

El método del modelo que generaba la consulta era más o menos así

/**
 * Determina si un producto está habilitado
 *
 * @param int $id Id del producto en base de datos
 * @return boolean
 * @access public
 */
public function isEnabled($id) {
	$product = $this->find('first', array(
		'conditions' => array('Product.id' => $id),
		'fields' => array('enabled')
	));
	if (empty($product)) {
		$out = false;
	} else {
		$out = !empty($product['Product']['enabled']);
	}
	return $out;
}

En algunos casos, al momento de llamar a isEnabled ya teníamos disponible el array con los datos del producto porque habíamos ejecutado un find previamente, así que el método se podría reescribir pasándole el array con todos los datos en vez del id, y con eso ya nos ahorraríamos consultas SQL repetidas

/**
 * Determina si un producto está habilitado
 *
 * @param array $product Array del producto retornado por un find()
 * @return boolean
 * @access public
 */
public function isEnabled($product) {
	return !empty($product['Product']['enabled']);
}

Sin embargo, esto hizo fallar algunos casos de testing porque en otros lugares de la aplicación el método necesitaba recibir el id el producto y todavía no se había leído el producto desde base de datos como para pasar el array.

La refactorización final quedó así:

/**
 * Determina si un producto está habilitado
 *
 * @param mixed $product Array del producto retornado por un find() o id del producto
 * @return boolean
 * @access public
 */
public function isEnabled($product) {
	if (!is_array($product) or empty($product['Product']['enabled'])) {
		$product = $this->find('first', array(
			'conditions' => array('Product.id' => $product),
			'fields' => array('enabled')
		));
	}
	if (empty($product)) {
		$out = false;
	} else {
		$out = !empty($product['Product']['enabled']);
	}
	return $out;
}

Siempre hacemos un esfuerzo muy grande por evitar cometer errores, pero a veces no es suficiente y es posible que algo se nos escape. Cuando esto sucede los clientes (en nuestro caso las agencias) nos avisarán de los bugs encontrados para que podamos corregirlos. Sin embargo, a veces los reportes no están lo suficientemente completos como para que podamos rastrear el error y encontrar el problema para poder solucionarlo.

En proyectos grandes y a largo plazo lo ideal es tener un sistema de bug tracking, pero para trabajos medianos o pequeños consideramos que un sistema de este tipo genera más problemas que beneficios y con un simple correo electrónico es suficiente. Sin embargo, esto no quita que el reporte de error deba estar completo.

Qué debe contener un reporte de bug

Todo reporte de error debe estar lo suficientemente detallado como para que los programadores podamos reproducirlo en igualdad de condiciones. No es suficiente con avisarnos que algo no funciona, debemos saber exactamente qué es lo que no funciona y por qué se considera que es un error, ya que muchas veces no se trata de un error sino de una mala interpretación sobre la forma en que debería estar funcionando el programa.

Un reporte de error debería responder al menos estas 4 preguntas:

1. Cuáles son los pasos a seguir para producir el error
2. Qué resultado esperaba conseguir el usuario al ejecutar estos pasos
3. Qué resultado se obtuvo en lugar del esperado
4. Bajo qué condiciones se ejecutó la prueba: sistema operativo usado, versión del navegador o teléfono móvil, resolución de pantalla, etc.

También resulta de mucha ayuda incluir capturas de pantallas, archivos adjuntos o imágenes que se hayan utilizado, copias completas de direcciones de acceso (URL), datos que se usaron para completar formularios, etc.

Si los reportes de errores están completos ahorraremos mucho tiempo en idas y vueltas de emails y lograremos entregar los trabajos con mayor anticipación.