Alfredo Juarez

La manera simple de manejar un error es usando die( ) cuando éste ocurre, sin embargo, a esto se le conoce como el suicidio del software. Aunque Martin Fowler nos dice que: “Si el costo de que el programa truene es pequeño y el usuario es tolerante así está bien”.

En PHP 5, como en muchos otros lenguajes, tenemos una alternativa al suicidio: Lanzando una excepción. Si no manejamos la excepción con un catch el sistema terminará el programa de la misma manera que die( ), agregándole un trazado de la pila (stack trace). Pero si en un futuro decidieramos manejar cierto error, de esta manera ya sería más sencillo.

¿Como funcionan?

El lenguaje de programaciónsabe que exception es una manera de comunicar un error o condiciones de excepción entre diferentes partes del programa. Por ejemplo, imaginemos que tenemos un método para conectar con una base de datos MySQL.

$db = new DBM;

if ( !$db->connect( ) )
	die("Error: no se puede conectar");
else
{
	// .....
	// --------->
	// .....
}

Esta es la versión suicida usando die( ), ahora veamos la versión utilizando el manejo de excepciones:

$db = new DBM;

if ( !$db->connect( ) )
{
	throw new Exception(
		"ERROR: no se ha podido conectar");
}
else
{
	// .....
	// --------->
	// .....
}

Si no hacemos nada para cachar la excepción, esto tiene el mismo efecto que die( ): Para la aplicación, además, este método hace una cosa adicional, imprime un stack trace, la cual puede ser muy usable para el debugging. Puedes obtener un stack trace sin usar excepciones usando las funciones debug_backtrace( ) y debug_print_backtrace( ). Pero lanzando una excepción es aún más sencillo de hacerlo.

Fatal error: Uncaught exception 'Exception' with message
'Error: no se ha podido conectar' in /path/exception.php:6
Stack trace:
#0 /path/exception.php(6): DBM::connect()
#1 /path/exception.php(12): DBM->connect()
#2 {main}
thrown in /path/exception.php on line 6


Si no queremos que los usuarios vean estos errores técnicos (por cierto no deberíamos por cuestiones de seguridad), estamos en una mejor posición por haber usado excepciones que usar die( ).  Si hemos usado die( ) en muchos lugares, tenemos que encontrar todas las ocurrencias y cambios en cada una. Si usamos excepciones, todo lo que necesitamos es cacharlas en algún lugar conveniente, por ejemplo, pudieramos registrar el mensaje y redireccionar al usuario a una pagina de error.

$db = new DBM;

try
{
	$db->connect( );
}
catch (Exception $e)
{
	$logger->log($e->getMessage());
	header("Location: error.php");
}

Como podrán ver el manejo de excepciones es algo imprescindible en el desarrollo de aplicaciones, ya que manejas de una manera más elegante los errores que surjan dentro de la aplicación. En próximas entregas les mostraré más ejemplos y profundizaré en el manejo de excepciones en PHP.

La mayoría de aplicaciones requieren de interacción con una base de datos, ya sea del tipo relacional u orientada a objetos y en la mayoría de los casos la persistencia de datos está mezclada con la lógica del negocio. Lo que supone un problema a la hora de querer cambiar el motor de base de datos.

Para entenderlo mejor formularemos un ejemplo de la vida real.

Imaginemos que estamos desarrollando una aplicación en la empresa donde trabajamos y estamos utilizando MySQL como motor de base de datos. Estamos en la fase de pruebas (ya a punto de publicar el producto final), y por alguna extraña razón a tu jefe se le ocurre que mejor deberíamos usar Oracle, por que se lo recomendaron, piensa que es mejor, etc.

Que pasa si tenemos todo mezlcado (lógica del negocio, métodos de acceso a datos, etc),  se convierte en una tremenda pesadilla.

Para nuestra suerte existe el patrón de diseño Data Access Object (DAO), que se encarga de encapsular la interacción de una aplicación con la base de datos.

¿Como funciona?

DAO encapsula el acceso a la base de datos, de esta manera cuando la capa de lógica de negocio necesite interactuar con la base de datos, ésta utilizará los métodos ofrecidos por DAO. Generalmente la clase de operaciones que ofrece la capa de datos se le conoce como CRUD (Create, Read, Update y Delete).

Cuando la capa de negocios necesite almacenar datos (por ejemplo) solo tendrá que hacer referencia al método correspondiente para insertar los datos de la clase DAO, de esta manera si en algún momento se llegara a optar por usar otro motor de búsquedas, la capa del negocio no se debe preocupar ya que sólo bastará con actualizar la capa de datos. Si hablamos de patrones algunos detectarán por aquí que se están delegando responsabilidades, una buena práctica de la orientación a objetos.

De hecho el método de persistencia no debe de interesarle a la capa de negocios, es decir, a él no le importa si los datos se guardan en una tabla MySQL, XMl, Texto plano o se imprime, de esto se encarga DAO.

Por cada tabla de una base de datos relacional existirá un DAO. Esto consiste básicamente en una clase que es la que interactúa con la base de datos. Los métodos de esta clase dependen de la aplicación y de lo que queramos hacer. Pero generalmente se implementan las 4 funciones básicas (también conocidas como métodos CRUD).

Una vez entendido el funcionamiento de DAO, es conveniente explicar un nuevo término que nos será de ayuda para completar la implementación de nuestra capa de persistencia. Se trata de los DTO’s (Data Transfer IObject), los cuáles son utilizados por DAO para transportar los datos desde la base de datos hasta la capa de lógica de negocio o vice versa.

En pocas palabras un DTO es un objeto que en su interior tiene como atributos los mismos atributos del modelo, con sus correspondientes accessors (Setters y Getters).

Diagrama DAO

Ahora veamos un ejemplo

Tenemos una aplicación que entre una de sus tantas funciones es controlar los datos de  clientes, y queremos usar DAO para el manejo de la persistencia de dicha aplicación.
Primero que nada de define el modelo 8en este caso de clientes), para después partir con la codificación de los respectivos DTO y DAO.

DTO

Class ClientesDTO
{
      private $id;
      prívate $nombre;
      prívate $direccion;

      public static function getID( )
      {
          return $this->id;
      }

      public static function getName( )
      {
          return $this->nombre;
      }

      public static function getAddress( )
      {
          return $this->direccion;
      }

      /* Setters */
      Public static function setID( $id )
      {
          $this->id = $id;
      }
      Public static function setName( $name )
      {
          $this->nombre = $name;
      }
      Public static function setAddress( $address )
      {
          $this->direccion = $address;
      }
}

DAO

class clientesDAO
{
     public static function create( $dto )
     {
          /* implementación para la creación de un nuevo registro */
     }

      /* aqui van los demás metodos CRUD */
}

Por obvias razones no escribí todo el código necesario ya que este artículo es meramente informativo, pero pienso que es explicito el ejemplo para comprender el uso del patrón DAO.
En la próxima entrega les mostraré un ejemplo más real, utilizando una mezcla de patrones, como el DAO, Singleton, Factory y Façade.

Estas pueden ser buenas y malas noticias, ya que por un lado los desarrolladores ya no podemos poner el pretexto de no hacer webs en flash por que son anti-buscadores, es decir, los bsucadores no pueden indexar su contenido por estar hechas en flash.

Por otro lado los clientes se verán beneficiados, ya que ahora podrán tener sus webs llenas de vida (a los que les gustan las páginas en Flash).

Google y Adobe hicieron una alianza para que el buscador pudiera indexar el contenido de los flash. Siendo anunciado unos días atrás que Google ha desarrollado un algoritmo con el cuál será posible la indexación.

Ahora si que no hay pretextos, si un cliente lo quiere en flash….

Links

Desarrollo Web

siendo sincero no se si tenga algo que ver, ni tampoco es algo relevante, pero bueno aquí se los dejo para los curiosos.

Via aNieto2k

Esta es una de las muchas noticias que se han generado durante Google I/O, que se trata de la mayor concentración de desarrolladores web del planeta, donde estarán en una jornada intensiva de dos días cubriendo 90 sesiones que giran en torno a 5 ejes:

1. AJAX y JavaScript
2. APIs y Herramientas
3. Redes Sociales
4. Mapas y Geolocalización
5. Móviles

Ahora puedes incrustar Google Earth con una nueva API que liberaron el día de hoy, por lo que desde ya será posible agregar un mapa a tu página web en la que podrás crear lineas, polígonos, fotos, etc.. todo como si fuera la aplicación de escritorio.

Pero bastata de tanto rollo, que mejor que verlo en vivo, tras el salto…te pedirá que instales un plugin, reiniciar el navegador y listo.
Read the rest of this entry »

Jon wiley es un diseñador de experiencia al usuario en Google, el cuál ha mencionado 10 lineamientos que rigen el diseño de aplicaciones dentro de Google. Creo conveniente publicarlas por que así como le han servido de gran ayuda a Google, son lineamientos que todos deberíamos seguir.

1. Useful: focus on people - their lives, their work, their dreams.
2. Fast: every millisecond counts.
3. Simple: simplicity is powerful.
4. Engaging: engage beginners and attract experts.
5. Innovative: dare to be innovative.
6. Universal: design for the world.
7. Profitable: plan for today’s and tomorrow’s business.
8. Beautiful: delight the eye without distracting the mind.
9. Trustworthy: be worthy of people’s trust.
10. Personable: add a human touch.

No se si tengan algún problema por dejarlos en inglés, pero para los que prefieran aqui les va en español:

Usable: Enfócate en las personas - sus vidas, su trabajo, sus sueños.

Rápido: cada milisegundo cuenta.

Simple: simplicidad es poder.

Acoplamiento: acopla a principiantes y atrae a los expertos.

Inovador: Atrévete a ser inovador.

Universal: diseña para el mundo.

Provechoso: planea para el negocio de hoy y mañana.

Hermoso: deleita al ojo sin distraer a la mente.

Digno de confianza: sé digno con la confianza de la gente.

Personal: agrega un toque humano.

Algo que siempre he odiado de IE, y que hasta la fecha ha hecho que cuando desarrollo/diseño páginas y aplicaciones Web, simplemente no hago testeos en él, esto quiere decir, que no se si mis páginas/aplicaciones se ven bien o no en IE (lo mas probable es que no), ya que IE hasta el momento no renderea las páginas de acuerdo a los estándares.

Pero al parecer esto está por terminar, ya que Microsoft ha anunciado que la versión 8 de IE, vendrá con 3 modos de renderizados, de los cuales uno de ellos es el Standards mode, al principio se habia dicho que para que las páginas usaran este modo, se tendría que especificar en las cabeceras, pero la buena noticia es que ahora Microsoft la ha pensado dos veces, y han establecido que el modo estándar será el modo default, evitando con esto la incompatibilidad que se ha venido generando por no estar basado en estándares.

Después de IE8, los desarrolladores ya no nos tendremos que preocupar por que nuestras páginas se vean bien en todos los navegadores, teniendo que hacer códigos y diseños especiales para cada navegador.

Las relativamente nuevas propuestas de adobe para el desarrollo de aplicaciones Web,  acaban de ser renovadas, y ya estan disponibles para su descarga. Se trata de Adobe AIR 1.0  y Flex 3.0

Estas tecnologías están demasiado interesante, la verdad es que por falta de tiempo no he podido conocerlas a fondo, pero prometo que en cuanto pueda les traeré un tutorial para desarrollar aplicaciones con AIR y FLEX.

En CalinSoft acabo de leer una lista con 40 sugerencias para optimizar el código PHP, aqui les mostraré algunas y los invito a que lean el artículo; verdaderamente vale la pena.

1. Dedica tiempo a estudiar PHP, está en un continuo proceso de crecimiento y sus características van cambiando con el tiempo.
2. Si necesitas escribir HTML hazlo directamente sin utilizar echo o print. Usa PHP para imprimir información sólo cuando sea necesario.
3. Utiliza memory_get_usage() y microtime() para comprobar la velocidad y la memoria que consume tu código.
4. Los if / else son siempre más rápidos que los switch / case.
5. Si un método puede ser static, decláralo estático. La velocidad se incrementa en un factor de 4.
6. do-while es más rápido que while, pero más lento que for. Lo primero a optimizar de un programa son los bucles ( un viejo truco de Algoritmia y Arquitectura de computadores ).
7. Utiliza paths absolutos a los ficheros en los include() y require(), el SO tarda menos en resolver las rutas al fichero.
8. $row[’id’] es hasta 7 veces más rápido que $row[id].
9. Incrementar una variable global es dos veces más lento que hacerlo con una variable local.
10. $localvar++ es hasta 15 veces más rápido que function inc(){ $localvar++; }.

Para leer las restantes deberás ir aquí.

Via | CalinSoft
Links |PHPLens (HOWTO on Optimizing PHP)

“Divide et vinces”: Divide y Vencerás
Julio Cesar

Muchos diseñadores web están acostumbrados a tener las etiquetas HTML, junto con las reglas CSS y las funciones JavaScript. Para los que se pregunten ¿Y eso que tiene de malo?  Este método no es de lo mas eficiente, ya que tienes una ensalada de lenguajes, esto hace que a la hora de querer hacer una revisión te pierdas entre tanto jeroglífico; por otro lado si tienes todo en un solo archivo la carga de la página se pone algo lenta ya que para el navegador es mas pesado cargar un archivo de muchos Bytes.
Hace tiempo hable sobre los Patrones de diseño, pero olvide mencionar que también existen los Anti-Patrones los cuales describen las malas conductas que no debe de tomar nunca un desarrollador, a continuación les pongo la descripción del antipatron que les estoy mencionando.
Código espagueti (spaghetti code): Construir sistemas cuya estructura es dificilmente comprensible, especialmente debido a la escasa utilización de estructuras de programación.

Mantener todo separado

Es sabido que las páginas Web se dividen 3 partes fundamentales:

• Contenido: Define el contenido del sitio.
• Presentación: Define el aspecto visual del sitio.
• Comportamiento: Define las acciones del sitio.

Este método es llamado “Separación de preocupaciones”.

Entender e implementar éste método lleva tiempo y se necesita un poco de disciplina, pero una vez que hallan comprendido los beneficios de mantener todo separado tratarán de siempre hacerlo de esta manera.

Read the rest of this entry »