• No soy un programador Zend Framework o CakePHP.
• Pienso que PHP es bastante complicado suficientemente complejo.

Me gusta construir cosas pequeñas

• Me gusta construir cosas pequeñas con propósitos simples.
• Me gusta hacer cosas que resuelven problemas.
• Me gusta construir cosas pequeñas que trabajan juntas para resolver grandes problemas.

Quiero escribir menos código, no más

• Quiero escribir menos código, no más.
• Quiero manejar menos código, no más.
• Quiero soportar menos código, no más.
• Necesito justificar cada pieza de código que agrego a un proyecto.

Me gusta el código simple, legible

• Quiero escribir código que sea fácil de entender.
• Quiero que el código sea fácilmente verificable.

Traducción al español de: http://microphp.org/

Hoy día con todo esto de la web 2.0 y las geo-posiciones, nos hemos acostumbrado un poco a ver los mapas en 2D (como Google Map), y puede que en algún momento necesitemos calcular determinadas distancias entre 2 puntos de referencia. Y como es obvio, no podemos hacerlo sobre un plano cartesiano ya que nuestro querido planeta tierra no es plano ;-)

function distance($lat1, $lon1, $lat2, $lon2, $unit) { 

  $theta = $lon1 - $lon2;
  $dist = sin(deg2rad($lat1)) * sin(deg2rad($lat2)) +  cos(deg2rad($lat1)) * cos(deg2rad($lat2)) * cos(deg2rad($theta));
  $dist = acos($dist);
  $dist = rad2deg($dist);
  $miles = $dist * 60 * 1.1515;
  $unit = strtoupper($unit);

  if ($unit == "K") {
    return ($miles * 1.609344);
  } else if ($unit == "N") {
      return ($miles * 0.8684);
    } else {
        return $miles;
      }
}

Una grata noticia ! el mejor framework PHP ha liberado su versión 2.0 con decenas y notables mejoras.

Descargar: http://codeigniter.com/download.php

Y para agregarle la cereza a nuestro cóctel también tenemos el paquete oficial en Español (al cual le eché una manito ;-) )
Descargar: http://mygengo.com/string/p/codeigniter-2-1/export/language/es/

Estoy considerando traducir la guía oficial completa al español, ¿voluntarios?

Pero en esta ocasión trajo algo muy particular… algo que procedía de Cupertino, California.

Ya había visto algunas fotos de como sería el famoso certificado, de hecho ya estaba consciente de que el diseño lo habían “modernizado”, lo que no imaginaba era el momento en que yo mismo tendría la oportunidad de hacer lo mismo :-)

Ahora si puedo decir que la arepita con queso e’ mano que me estaba comiendo, sabe ahora mucho mejor !

¿Qué más puedo decir?, pues sólo aconsejar a quienes me leen, que si tienen oportunidad de certificarse, HÁGALO!

Y he aquí: DESCARGAR

Espero les sea de utilidad.

Editado: El link de descarga ahora ya no está en mediafire, sino en el sitio oficial de codeigniter.

1. Usar MyISAM en lugar de InnoDB.
MySQL tiene un considerable número de motores de almacenamiento, entre los cuales lo más destacados con MyISAM e InnoDB.

Pero MyISAM es quien viene por defecto en toda instalación MySQL. Y muchos ignoramos esto y sencillamente lo dejamos así, pero MyISAM no soporta foreign key ni transacciones. Además, la tabla completa es bloqueada cada vez que insertamos o actualizamos un registro causando problemas de rendimiento.

La solución es simple: Usar InnoDB

2. Usar las funciones mysql de PHP.
PHP provee un amplio set de funciones para trabajar con MySQL, y eso ha sido así desde el principio (muchos años). Funciones tales como mysql_connect, mysql_query, mysql_fetch_assoc, etc. pero ignoramos una importante mejora implementada desde PHP 5: la librería mysqli.

Y tal como cita el manual oficial de PHP:

Si se utiliza una versión de MySQL 4.1.3 o posterior, se recomienda encarecidamente utilizar la extensión mysqli en su lugar.

mysqli tiene notables ventajas:

• Una interfaz opcional orientada a objetos
• Prepared Statements (sentencias preparadas) que ayudan a prevenir los ataques de inyección SQL e incrementa el performance.
• Soporta la ejecución de múltiples sentencias y transacciones

Además, usted podría considerar usar PDO si planea dar soporte a distintos tipos de bases de datos.

3. No filtrar las entradas del usuario
Este es quizá el peor de todos los errores. NUNCA CONFÍE EN LO QUE LOS USUARIOS ENVÍEN. Validar todo desde el lado del servidor es algo obligatorio, no confíe en las validaciones JavaSript. Atacar un sitio por inyección SQL es tan simple como:

$username = $_POST["name"];
$password = $_POST["password"];
$sql = "SELECT userid FROM usertable WHERE username='$username' AND password='$password';";
// run query...

Esto puede ser crackeado con tan sólo ingresar “admin’; –” en el campo de username. La cadena SQL quedaría así:

SELECT userid FROM usertable WHERE username='admin';  

El atacante ha logrado ingresar al sistema como ‘admin’ sin siquiera necesitar el password, porque fue comentado dentro del SQL.

4. No usar UTF-8
Un gran problema respecto al manejo de los caracteres y la internacionalización (otros idiomas) es el mal uso del charset. Sin importar si lo que desarrollamos sea en inglés o español (o cualquier otro) usar UTF-8 es una gran solución. Aunque PHP no ofrezca del todo un soporte a UTF-8 (al menos hasta la versión PHP 6) MySQL si posee dicho soporte, MySQL character sets

5. Favorecer a PHP por sobre MySQL
MySQL posee un amplio set de funciones que puede correr como parte de la sentencia QUERY, pero muchos lo ignoramos.

Por ejemplo, para obtener un valor promedio de los salarios en una tabla, un programador realizaría una consulta a MySQL y traería hasta PHP todos los registros a calcular; y posteriormente realizaría el cálculo del promedio con la aritmética de PHP (y que es el lenguaje que conoce); pero la mejor opción hubiese sido aprovechar la función AVG() que trae MySQL y nos ahorramos procesos innecesarios.

La regla general es usar en la mayor medida posible las funciones pre-construidas en la base de datos, ahorrando procesos a PHP.

6. No optimizar las consultas
El 99% de los problemas de performance en PHP se deben a sentencias y consultas SQL mal hechas. MySQL cuenta con herramientas que nos permiten medir y probar nuestras consultas a fin de buscar mejores opciones. Sentencia EXPLAIN, Query Profiler y algunas otras herramientas que le ayudaran a robustecer sus SELECT.

7. Usar tipos de campo inadecuados
MySQL ofrece un amplio rango de tipos numéricos, cadenas y de fechas. Si usted va a almacenar una fecha, use el campo indicado para ello DATE o DATETIME. Usar enteros o cadenas para ello, sólo le traerá problemas.

Es importante determinar cual es el tipo de campo ideal para cada dato que vaya a almacenar. Piénselo bien, MySQL ofrece bastante de donde escoger.

8. Usar * en las consultas SELECT
Es un error terriblemente común. No use * para retornar todas las columnas de una tabla. No sea flojo ! Sea específico en definir cuales campos desea consultar, incluso si los llega a necesitar todos.

9. No indexar o indexar más de lo necesario
Como regla de oro, indexe sólo donde una columna sea solicitada en una sentencia WHERE de una consulta SELECT. Saber hacerlo mejorará el performance de su base de datos y en consecuencia incrementará la velocidad de todo su sistema.

10. Olvidar respaldar !
Aunque no lo crea, las cosas no siempre funcionan como esperamos. Las bases de datos se pueden corromper, el disco duro estropearse, un incendio puede consumir su datacenter e incluso su proveedor puede irse a banca rota !

Perder datos es algo catastrófico e imperdonable, tome todas las medidas necesarias para tener siempre a mano respaldos de sus datos, de forma automatizada y remota.

11 La ñapa: no considerar otras bases de datos.
MySQL es sin duda uno de los más famosos y extendidos entre los programadores PHP, pero no es la única opción. Existen muchas alternativas como PostgreSQL y Firebird quienes son además Software Libre y no controlados por una corporación como sí lo es MySQL. Incluso SQLite puede resultar en una interesante alternativa para aplicaciones pequeñas y embebidas.

No cabe duda que los muchachos de hoy día son unos genios desde que nacen, desde que los primeros rayos de luz tocan sus retinas ya están observando y comprendiendo un mundo mucho muy diferente al que conocimos en el pasado, rodeados de nuevas tecnologías que aun nos sorprende; y sin duda cada nueva generación será más “avanzada” aún.

Lo mismo sucede con la genialidad tecnológica, grandes genios (y ahora multimillonarios) son muchachos muy jóvenes. Por citar a Sergey Brin y Larry Page los creadores de Google o a Mark Zuckerberg el genio detrás de Facebook. Todos ellos muy jóvenes.

Pero, ser un Programador Senior PHP va más allá de tener una “chispa de genialidad” y algo de suerte para convertirse en un hito de la historia universal, ser un Programador Senior PHP no es sólo saber programar en PHP.

Ahora bien, alguno podría auto-evaluarse y decir: “yo desarrollé un framework, eso me hace PHP Senior“… pero me temo que no, eso no te convierte en un SENIOR.

Otro dirá: “Yo he desarrollado más de 200 sistemas web para distintos clientes“, qué bien !… pero eso tampoco te hace SENIOR.

No faltará quien diga: “tengo muchos artículos redactados en la web sobre PHP“, felicidades… pero sigue sin ser lo necesario para convertirte en un SENIOR.

Y es que parte del problema es la edad…. si, la edad. Aunque suene disparatado.

Analicemos los hechos:

* PHP nació en 1995 pero llegó a conocerse recién en tierras latinoamericanas casi 2 años después: 1997
* PHP tal como lo conocemos hoy, tiene la forma de PHP4 más que PHP3 (o PHP5 incluso) el cual vio la luz en el año 2000
* Comprender hexadecimales, binarios, vectores y aritmética progresiva (necesarios para establecer la bases fundamentales de los operadores en PHP), es algo que un individuo promedio conoce a la edad de 15 años (cuando cursa el 8 grado de educación básica)

PHP entonces tiene 12 años de edad aproximadamente (15 para ser exactos pero no olvidemos el factor socio-económico que siempre produce retrasos tecnológicos en estas tierras sur-occidentales)… y si alguien se subió al tren de PHP digamos a una edad de 17 años quiere decir que apenas ha conocido los últimos 5 años de PHP y esa es toda su experiencia, la cual es sólo 1/3 un tercio de lo que algunos con más edad ha podido saborear.

Puede que haya excepciones y hay quien diga, pero yo programo desde que tengo 8 años… quizá, y si es así felicidades… quizá te conviertas en un buen programador, pero por ahora… no serás un SENIOR hasta que llegues a la edad en la cual comprendas :

* Que no te las sabes todas.
* Que la humildad es algo que también se lleva a nivel de código.
* Que desarrollas para ti y no para los demás.
* Que no tienes nada que demostrarle al mundo, sólo a ti mismo.
* Que no necesitas que tu nombre aparezca muchas veces en Google para sentirte “famoso”.
* Que siempre habrá alguien que sepa más que tú.

Y es que lo que te hace SENIOR, no es lo bien que programes, la cantidad de funciones que te sepas de memoria o los certificados que te avalen… lo que te hace SENIOR es la experiencia y eso estimados amigos, sólo se gana con la edad no con los miles de proyectos o las millones de líneas de código que hayas escrito.

Si tienes más de 30 años (naciste antes de 1980), trabajaste con PHP3, instalaste y compilaste tú mismo PHP+Apache desde los códigos fuentes cuando antes no existía los LAMP o WAMP, si no te has “ensuciado” la mente con otros lenguajes de programación y en su lugar estás dedicado en cuerpo, alma y corazón a PHP desde hace más de 12 años sin dejar de pensar en ello un sólo día de esos más de 4300 días, si lograste desarrollar sistemas procedimentales limpios y lograste hacer de tripas corazón de la programación orientada a objetos con lo poco que había antes de PHP5, si has creado tus propios sistemas que no se parece a nada nunca antes visto y gozas del respeto de la comunidad pero a su vez conservas la humildad de reconocer que no te las sabes todas…

… entonces amigo mio, eres un Programador Senior PHP

Inicialización de variables PHP

Consideremos el siguiente código:

<?php
if (authUser($_POST["login"], $_POST["password"])) {
    $auth = true;
}
if ($auth) {
    echo "Secret\n";
}
?>

Puedes detectar fácilmente la vulnerabilidad en el mismo. La variable $auth no se inicializó para todos los casos por lo que puede ser engañada desde el exterior. PHP define una forma de manejar las variables sin inicializar (a diferencia del lenguaje C, por ejemplo), todos ellos tienen el valor null. El problema es que la variable se puede inicializar de otras fuentes:

• Código Anterior.
• Archivo incluido (include)
• Remotamente si register_globals está habilitado.
• Usando el extract de una variable (no fiable).

Defensa:
Defenderse de este tipo de vulnerabilidad es muy simple – Siempre inicializa las variables:

<?php
$auth = false;
if (authUser($_POST["login"], $_POST["password"])) {
    $auth = true;
}
?>

Ahora $auth contiene algo (o nada) entonces siempre resolverá a FALSE. Es una buena idea inicializar las variables incondicionalmente. El siguiente código debería funcionar aunque no es tan robusto:

<?php
if (authUser($_POST["login"], $_POST["password"])) {
    $auth = true;
} else {
    $auth = false;
}
?>

Ahora consideremos que a alguien le gusta revisar las direcciones IP y lo hace de este modo:

<?php
if ($_SERVER["REMOTE_ADDR"] == "127.0.0.1") {
    if (authUser($_POST["login"], $_POST["password"])) {
        $auth = true;
    }
} else {
    $auth = false;
}
?>

La variable $auth puede ser engañada de nuevo !

Nota: El atacante debe conocer la variable a engañar, bien puede adivinarla, obtenerla de algún mensaje de error, usando fuerza bruta o en la mayoría de los casos, se ha hecho con el código fuente (aplicaciones open source o siendo un ex-empleado de una empresa).

Deshabilitando register_globals

Es importante mencionar que deshabilitar register_globals no es en definitiva una defensa contra este tipo de ataques. Esto sólo nos acerca a evitar el más común de los tipos de ataque. Por supuesto es una buena idea deshabilitarlo pero las buenas aplicaciones no dependen de esta directiva y funcionan indistintamente de ellas, así no es necesario emular de este modo:

<?php
// NUNCA USES ESTE TIPO DE CÓDIGO
if (ini_get("register_globals")) {
    foreach ($_REQUEST as $key => $val) {
        unset($$key);
    }
}
?>

Reconociendo variables no inicializadas

PHP posee un mecanismo para vigilar variables no inicializadas, este es el manejador de errores E_NOTICE quien nos muestra las variables no inicializadas, aunque esto conlleva algunos problemas:

1. No advierte acerca de un array sin inicializar.
2. Advierte al acceder a un índice no-existente en un array debidamente inicializado.
3. Se publica en tiempo de ejecución.

E_NOTICE No advierte acerca de un array sin inicializar.

Este primer problema es el más relevante, considere el siguiente código:

<?php
$config["password"] = "pwd";
if (isset($_POST["password"]) && $_POST["password"] == $config["password"]) {
    echo "Secret information.\n";
}
?>

Esto no notará si un atacante falsifica la variable $config. Si el pasa una cadena entones el código es interpretado como esto:

<?php
$config[0] = "p";
// $config es una cadena de modo que  [] es usada para acceder a los bytes de la cadena
// "password" es convertido al número 0 porque la posición de la cadena son siempre enteros
// sólo un byte puede ser escrito a [0] de modo que "pwd" es interpretado como "p"
if (isset($_POST["password"]) && $_POST["password"] == $config[0]) {
    echo "Secret information.\n";
}
?>

Ahora bien, esto es suficiente para adivinar el primer carácter de la contraseña y enviarla junto con el falso $config

E_NOTICE advierte al acceder a un índice no-existente en un array debidamente inicializado.

Este segundo problema no está relacionado con la seguridad pero si con desarrollar código “bien hecho”. El siguiente código informaría una notificación aún si funciona bien y no puede ser engañado:

<input name="search" value="<?php echo htmlspecialchars((string) $_GET["search"]); ?>" />

Con el E_NOTICE habilitado, nosotros debemos re-escribir el código aunque un poco más largo con la misma funcionalidad:

<input name="search" value="<?php
if (isset($_GET["search"])) {
    echo htmlspecialchars((string) $_GET["search"]);
}
?>" />

Otro ejemplo de esta restricción – El siguiente código es perfectamente válido y hace lo que esperamos que haga (contar miembros de un grupo):

<?php
$groups = array();
foreach (getData() as $data) {
    $groups[$data["id_group"]]++;
}
?>

Con el E_NOTICE habilitado, debemos re-escribirlo de este modo:

<?php
$groups = array();
foreach (getData() as $data) {
    if (!isset($groups[$data["id_group"]])) {
        $groups[$data["id_group"]] = 0;
    } else {
        $groups[$data["id_group"]]++;
    }
}
?>

Yo no diría que este es el código más claro y menos propenso a errores (ya hay un error incluido).

E_NOTICE se publica en tiempo de ejecución.

Este tercer problema está relacionado con la seguridad. Si usamos variables no inicializadas que no monitorizamos durante el desarrollo, entonces el atacante puede usarle. Es bueno informar sobre variables no inicializadas en el log de errores pero si esto puede ser usado por el atacante, entonces será demasiado tarde. Es posible hacer notificaciones fatales con set_error_handler pero no vale la pena para la mayoría de las aplicaciones.

Mejor monitoreo de variables no inicializadas

No recomendaría deshabilitar las notificaciones. Sin embargo, esto no soluciona todos los problemas y requiere de re-escribir un código más profundo como han notado. Afortunadamente, hay una forma mejor de rastrear las variables no inicializadas que resuelve los tres problemas de las notificaciones. Su nombre es php-initialized. Es una herramienta para analizar el código fuente en búsqueda de variables no inicializadas. Esto no ejecuta el código y tiene algunas limitaciones pero se puede utilizar para comprobar el código de forma rutinaria, por ejemplo, después o antes de realizar una refactorización.

La principal limitación es que sólo el bloque actual es considerado dentro del ámbito de variables. Así, el siguiente código reclamaría a $auth como variable no inicializada:

<?php
if (authUser($_POST["login"], $_POST["login"])) {
    $auth = true;
} else {
    $auth = false;
}
if ($auth) {
    echo "Secret\n";
}
// Imprime: Uninitialized variable $auth on line 7
?>

No use $_REQUEST

Engañar variables no sólo involucra a las variables globales. La variable $_REQUEST puede ser llenada desde cualquier fuente externa.

Recordemos que $_REQUEST obtiene sus valores de los métodos: POST, GET y COOKIE … en su lugar deberíamos ser más específicos respecto al origen de la información usando las super-globales: $_POST, $_GET y $_COOKIE en cada caso.

En resumen

Las buenas aplicaciones PHP deberían siempre inicializar sus variables antes de usarlas. Es una maravillosa idea establecer el register_globals en OFF Aunque una buena aplicación debe funcionar indistintamente de dicha directiva. PHP nos ofrece un manejador de errores E_NOTICE que puede monitorizar las variables que no están inicializadas pero esto no debe ser 100% confiable. La herramienta php-initialized resolverá estás deficiencias.

En realidad no se trata de un error en sí, sino de una buena practica de programación que evita disparar comportamientos indeseados cuando la aplicación tiene a crecer.

La premisa es simple: no debes asignar variables dentro de una condición.

El típico ejemplo mal indebidamente hecho:

while($array = mysql_fetch_array($result)){

¿Y como debería ser?

while( ($array = mysql_fetch_array($result)) !== false){

¿Cual es la diferencia?

Esta buena práctica evita errores como:

if($a = 36){

Fíjense como sucede una “asignación dentro de una condición“, exactamente lo que debemos evitar… y es malo porque esa asignación SIEMPRE será cierta (true).

¿Y porqué usar !== en lugar de un simple !=?

Ese es otro detallito que muchos suelen ignorar ;-), resulta que esperamos un FALSE booleano, no una “false” cualquiera, así que para estar seguros del valor y el tipo (no vaya a ser un string con la palabra false), lo mejor es comprobar si el dato es IDÉNTICO o NO IDÉNTICO, los cuales evalúan no sólo el contenido de la variable, sino el tipo de variable también.

Espero les haya gustado esta mini-entrada, tenía tiempo sin redactar algo a este abandonado blog. Hasta la próxima.