Gráficas a través de Google Chart API

Hace poco empecé a probar la API de Google Chart, un nuevo servicio web disponible que nos permite a través de una url y una serie de parámetros obtener -sin instalar nada- un gráfico que puede ser embebido en nuestro sitio web.

Lo estoy usando para desarrollos internos, y la verdad que simplifica bastante el trabajo al evitar muchos problemas, desde instalar herramientas, librerías, configuración, curva de aprendizaje, etc.

Ejecutar las primeras pruebas que aparecen en la documentación puede dar la impresión que todo es muy sencillo, pero cuando queremos obtener algo que se ajuste exactamente a nuestras necesidades es casi seguro que pasaremos algunas horas de "prueba y error" hasta lograr entener todos los parámetros y cómo cambian de acuerdo al tipo de gráfico.

Es un servicio gratuito y no tiene límites, aunque hay que avisar en caso de superar los "250,000 API calls per day".

Aquí un ejemplo de una url donde simplemente hay que pasar parámetros con los valores necesarios. Esta misma url la podemos agregar dentro de un <IMG> y como el resultado es una imágen .PNG, automáticamente la podemos tener embebida en nuestro sitio:

Lo bueno es que también puedo de forma muy simple enviar el link por mail a un usuario a partir de la url generada con los datos de mi sistema.

Aquí les dejo un ejemplo:

1  
<?php
2  
3  foreach( $this->ventas as $venta ){
4     $dia[] = $venta['dia'];
5     $cant[] = $venta['cantidad'];
6  }
7  
8  $chx = implode( "|", $dia );
9  $chd = implode( ",", $cant );
10  
11  $pars = array(
12     "http://chart.apis.google.com/chart?chs=1000x300",
13     "cht=ls",
14     "chxt=x,y",
15     "chds=1,100",
16     "chxl=0:|" . $chx . "|1:|0|50mil|100mil|150mil|200mil",
17     "chtt=Ventas por Dia",
18     "chd=t:" . $chd,
19     "chm=D,C6D9FD,1,0,8|D,4D89F9,0,0,4",
20     "chg=20,50,1,0"
21  );
22  
23  $url = implode( "&", $pars );
24  
25  ?>
26  <table border=1 align="center">
27   <tr>
28    <td>
29     <img src="<?php echo $url ?>" alt="Ventas por Dia"/>
30    </td>
31   </tr>
32  </table>
33  
34  


Tal vez no sea lo mejor para todos los contextos, pero lo bueno es que usamos una herramienta de Google que está probada y tiene un respaldo de calidad detrás, como así también nos libera de tener que instalar librerías en nuestro servidor, ancho de banda y tiempo de procesador para generar los gráficos.

Por el momento me está siendo muy útil ;-)

Herencia de clases y el "Principio de Liskov" (actualizado 15/10/2007)

En realidad se llama "Principio de sustitución de Liskov" y el nombre completo es Bárbara H. Liskov (sí, hay mujeres en la informática y han hecho grandes aportes ;-)).

A grandes rasgos dice que el famoso "es un" (is_a) que generalmente usan los docentes para enseñarnos "herencia de clases" no es suficiente.

No basta con "ser" hay que "comportarse como tal".

Generalmente hago el mismo chiste cuando trato el tema en un curso: "un docente es una persona, pero no basta, debe comportarse como tal".

Un ejemplo más real: Sistema de liquidación de sueldos

Si tienes un sistema que liquida sueldos, una clase base Empleado (con atributos como "sueldo" que se usa para calcular su pago) y subclases Gerente, Desarrollador, Administrativa y Becario (asumamos que el último no recibe ninguna remuneración).

Usas polimorfismo y en tu clase Administracion tienes un método liquidarSueldo donde recibirás objetos de tipo Empleado. Bien, cuando en un momento recibes de tu lista de empleados un becario... ¿qué debe hacer el sistema? (ya que haces el cálculo en base al valor que viene en el atributo sueldo y este es heredado por todos desde la clase Empleado).

1. ¿Emitir un comprobante impreso pero con valor 0?
2. ¿Agregar un "if" preguntando si es becario, y no hacer nada?
3. etc

Supongamos que el 1) no es aceptable por el gasto de papel y te piden que no se impriman (no tiene sentido), pasamos al punto 2), agregamos un "if".

¿No estamos "codificando a fuego" nuestro sistema para un comportamiento particular?

Estamos rompiendo el polimorfismo, justamente, el patrón estratégico más importante que tiene la POO. Cada vez que tenemos que cambiar nuestro código generamos nuevos costos y nuevos posibles errores.

Por eso cada vez nos cuesta más desarrollar un sistema, hasta que tenemos que tirarlo y desarrollar otro de cero... y empezamos otra vez con los problemas del mal diseño (code smell).

La base teórica

Los principios de diseño te dicen que "desarrolla cerrado al cambio y abierto a la extensión" (Principio Open/Closed, "Abierto / Cerrado").

Por ejemplo, tu código debe ser reutilizable (¿no es la idea esencial de la OO?) y con solo agregar código -sin tocar el existente- lograrás adecuarte a los cambios, a los nuevos requerimientos. No te olvides que nuestro código lo usan muchos otros objetos, si este cambiara, generaría un efecto en cadena, posiblemente, dejando de funcionar lo ya existente y tener que modificar más objetos.

Esta forma de "extensión" es agregar más clases a la herencia y el método liquidarSueldo no se modifica, pero si tu no haces correctas herencias, no puedes hacer lo primero, por lo tanto tu sistema se degradará en cascada.

Esta simple tontería el autor demuestra con muchos ejemplos que hacer "herencia por herencia", "por reutilizar código", no es suficiente y genera grandes problemas en los diseños.

Es una de las razones que me ven de mal humor cuando veo que implementan herencia a los golpes, prueba y error, con el argumento solo de "reutilizar código"

La conclusión final es...

El problema es que la herencia está mal formulada y que el Becario no se comporta como un Empleado, por lo tanto no puede ir en esa estructura jerárquica, de lo contrario nos va a obligar a desarmar nuestro sistema para tratar de ajustarlo a un comportamiento no adecuado (agregando condiciones explícitas para el mismo, hardcode) y este empezará a dejar de ser reusable.

No se puede hacer herencia por herencia, para reusar código. No se puede hacer herencia simplemente por que un "Becario es un Empleado", hay que estar seguro que además de "ser" se comporte como tal.

Nuestro becario, ya que no cobra una remuneración, no pude pasar por el sistema de liquidación de sueldos. La solución no es ajustar el sistema de sueldos para que lo permita.

Anexo otro artículo relacionado: Herencia Múltiple en PHP5

Nota: este post está basado en una discusión presentada en Foros del Web