Hoy: formatos de vídeo de alta definición
Nos vamos a salir un poco de la temática informática.
¿Recuerdan la "guerra" de los formatos de vídeo doméstico que se produjo en los años 80?
Para los más jóvenes: había dos sistemas de vídeo, VHS y Betamax. VHS ofrecía menos calidad pero más tiempo de grabación en cada cinta. Por otra parte, la empresa que inventó el VHS en seguida abrió la posibilidad de que otros fabricantes utilizasen el formato.
Casi 30 años después, parece que se repite la historia, incluso algunos actores repiten. Tenemos ahora mismo en el mercado dos formatos de vídeo de alta definición: Blu-ray y HD-DVD.
Aparentemente el Blu-ray ofrece un poco más de capacidad de almacenamiento y una mayor inmunidad frente a discos rayados o sucios. El formato HD-DVD guarda algunas similitudes con el DVD convencional y es más económico. Este último fue propuesto por la organización DVD Forum, el formato Blu-ray ha sido desarrollado fuera de esta organización.
Ambos formatos tratan de mejorar la protección anticopia mediante un sistema llamado AACS, aunque este sistema ya ha sido vulnerado. También se implementa un sistema que reduce la calidad de la señal de vídeo cuando se utiliza un cable analógico (esto es, un cable de vídeo normal).
Existen reproductores de mixtos de DVD y Blu-ray, de DVD y HD-DVD y otros (más caros) que reproducen cualquiera de ellos, tanto en versiones "de sobremesa" como para ordenadores. Algunas video-consolas incluyen lector de Blu-ray, otras reproducen HD-DVD.
¿Cuáles son las consecuencias para nosotros, los usuarios?
Realmente ambos formatos ofrecen una calidad muy buena, la diferenciación es más bien artificiosa. Los usuarios estamos soportando una guerra comercial entre dos grandes multinacionales con intereses contrapuestos (Sony, impulsora del Blu-ray, dedicada a la industria del entretenimiento y Microsoft, que apoya el HD-DVD, gigante del software, ... )
En mi opinión, lo que me parece es una tomadura de pelo y un intento de vender más: para poder apreciar bien la mejora de calidad que supone el vídeo de alta definición se necesita un buen equipo (TV de alta resolución, amplificadores y altavoces adecuados, un buen espacio -en un salón de 20 m2 el resultado es más bien atronador-, ...)
Por otra parte, las conexiones de banda ancha (= posibilidad de descargar películas) y las mejoras en los formatos de vídeo comprimido (DivX, ...) facilitan a los usuarios ver películas en alta calidad en un reproductor híbrido de los que ahora abundan y "tragan" con todos los formatos y soportes.
Cada vez hay más personas desencantadas con la industria del entretenimiento y sus prácticas. El arte (cine, música) se entremezcla con intereses comerciales y corporativos, los precios de los soportes siguen sin bajar y se restringen cada vez más los derechos de los consumidores (véase la implantación de los sistemas anticopia y de degradación de la señal).
Finalmente, una valoración muy personal y generalizadora: ahora que tenemos una mayor calidad técnica, la calidad artística es peor.
lunes, 24 de diciembre de 2007
sábado, 22 de diciembre de 2007
¡Ha salido Tcl/Tk 8.5!
En anteriores entradas despotricaba contra Tcl/Tk, y una de mis "quejas" era que el aspecto de los "widgets" era horroroso, sobre todo en sistemas X-Window (Linux y otros UNIX).
Bien, parece que en esta nueva versión se ha añadido una extensión llamada Tile que permite el uso de "themes" en las aplicaciones Tcl/Tk. Los pantallazos que se muestran tienen buena pinta.
A lo mejor le doy una segunda oportunidad a Tcl/Tk como lenguaje para desarrollar programas "de ventanitas". Veamos como queda uno de mis programillas (Pitch & Tunning Studio) con la nueva versión de Tcl/Tk.
Tk 8.4 en Mac OSX
Tk 8.5 en Mac OSX
Tk 8.4 en Linux
Tk 8.5 en Linux
Tk 8.5 en Windows XP
No he adjuntado un pantallazo de Tk 8.4 en Windows porque prácticamente no ha cambiado nada. La mejora en Linux es increíble: fuentes alisadas, los "radio buttons" redondos y muchos más detalles. También la versión para Mac ha mejorado bastante (observen el "spinbox" rotulado como "Note duration").
Definitivamente, ya no puedo mantener que Tk es un "toolkit" feo ;-)
Por cierto, la distribución de Tcl/Tk más conocida, la de Active State, ya no incluye el paquete Snack por defecto (aunque se puede instalar).
¡Grrrr!
Bien, parece que en esta nueva versión se ha añadido una extensión llamada Tile que permite el uso de "themes" en las aplicaciones Tcl/Tk. Los pantallazos que se muestran tienen buena pinta.
A lo mejor le doy una segunda oportunidad a Tcl/Tk como lenguaje para desarrollar programas "de ventanitas". Veamos como queda uno de mis programillas (Pitch & Tunning Studio) con la nueva versión de Tcl/Tk.
Tk 8.4 en Mac OSX
Tk 8.5 en Mac OSX
Tk 8.4 en Linux
Tk 8.5 en Linux
Tk 8.5 en Windows XP
No he adjuntado un pantallazo de Tk 8.4 en Windows porque prácticamente no ha cambiado nada. La mejora en Linux es increíble: fuentes alisadas, los "radio buttons" redondos y muchos más detalles. También la versión para Mac ha mejorado bastante (observen el "spinbox" rotulado como "Note duration").
Definitivamente, ya no puedo mantener que Tk es un "toolkit" feo ;-)
Por cierto, la distribución de Tcl/Tk más conocida, la de Active State, ya no incluye el paquete Snack por defecto (aunque se puede instalar).
¡Grrrr!
viernes, 21 de diciembre de 2007
Cacheando, que es gerundio
El otro día nos llamó un lector del periódico para preguntarnos porqué le había desaparecido un comentario que había escrito en una noticia.
Le preguntamos qué noticia era y, tras localizarla, observamos que su comentario estaba visible.
Preguntamos entonces al lector qué navegador estaba usando (era Internet Explorer) y le sugerimos entonces la combinación "mágica" de teclas: Ctrl+F5
¡Ya veo el comentario! nos respondió el paciente lector, ¿por qué pasaba esto?, nos preguntó. Mi respuesta fue algo críptica: "el navegador le estaba mostrando la página no actualizada que tenía guardada en la caché".
Intentaré en esta entrada enmendarme y explicar un poco mejor qué es eso de la caché.
Podríamos definir caché como una técnica ampliamente utilizada en los ordenadores que consiste en guardar la información más utilizada en una localización más cercana (más accesible y rápida) al elemento que necesita esta información en vez de en su ubicación original.
No queda muy claro ¿verdad?
A ver si con un ejemplo se entiende mejor:
Volvamos al lector de las noticias y su programa navegador. Generalmente los navegadores van guardando una copia en el ordenador del usuario de las páginas y otros elementos (imágenes, archivos auxiliares, etc) que el usuario va visitando.
Con esto lo que se consigue es que cuando visitamos una página en la que ya hemos estado anteriormente el navegador nos muestra la copia que guardó en la anterior visita, en vez de recuperar los contenidos de la página de internet.
Obviamente, la página se carga en el navegador instantáneamente ya que está guardada en el mismo ordenador del usuario. La desventaja de esto es que si la página "verdadera" ha cambiado mientras, no nos enteramos.
La ubicación donde el navegador guarda estas páginas temporales es la llamada caché del navegador.
No sólo "cachean" (disculpen el barbarismo) los navegadores. Como decíamos, esta técnica se utiliza mucho, y a todos los niveles: desde los microprocesadores (CPU) hasta los programas que utilizamos los usuarios finales.
Esta misma página que Ud. está leyendo ha sido cacheada varias veces por distintos dispositivos y programas.
La mayoría de las páginas web hoy en día no son estáticas, sino dinámicas, esto es, se generan "al vuelo", cuando alguien (el lector) las solicita a un servidor web.
Este texto que estoy escribiendo, el título, la fecha y demás datos se guardan en una base de datos. Cuando alguien solicita esta página, el servidor web a su vez pide los datos a la base de datos (que puede estar en la misma máquina o en otra). Una vez obtenidos los datos necesarios, "compone" la página dinámicamente, poniendo el título en un sitio, el texto en otro, añadiendo el encabezado de la página y el pie. Una vez montada la página, la devuelve al cliente (la persona que desde su navegador solicitó la página).
En este sencillo proceso se cachea casi todo por razones de eficiencia. Si a la base de datos le va a llegar muchas veces la solicitud "dame el título, texto y fecha del artículo X", el programa que la gestiona guardará en memoria los resultados de esta consulta, para que la siguiente vez que se lo pidan pueda devolver estos datos con mayor rapidez.
El servidor web, una vez que tiene los datos, como decíamos, "monta" la página final y la guarda también, para que la siguiente vez que le sea solicitada no tenga que repetir la consulta a la base de datos ni el proceso de montaje.
Finalmente, el navegador de la persona que solicitó la página con toda probabilidad también cacheará la página, o algunos de sus elementos, para que en una posterior visita no tenga que solicitarla de nuevo al servidor web.
La duda que nos puede surgir es ¿cuánto tiempo permanecen los datos en las cachés? En algún momento tendrán que renovarse, si no, veríamos siempre todo igual.
La respuesta es compleja, y depende mucho de la tipología del sitio web, del número de visitas y muchos más factores. Por ejemplo, este blog actualiza su caché cada 5 minutos aproximadamente. Otras páginas web, en las que la información varía más en el tiempo (por ejemplo, la página web del diario Público) se actualizan con mayor frecuencia. A menudo se busca un compromiso entre la conveniencia de cachear páginas (se sirven con mayor rapidez) y la necesidad de que éstas estén actualizadas.
Le preguntamos qué noticia era y, tras localizarla, observamos que su comentario estaba visible.
Preguntamos entonces al lector qué navegador estaba usando (era Internet Explorer) y le sugerimos entonces la combinación "mágica" de teclas: Ctrl+F5
¡Ya veo el comentario! nos respondió el paciente lector, ¿por qué pasaba esto?, nos preguntó. Mi respuesta fue algo críptica: "el navegador le estaba mostrando la página no actualizada que tenía guardada en la caché".
Intentaré en esta entrada enmendarme y explicar un poco mejor qué es eso de la caché.
Podríamos definir caché como una técnica ampliamente utilizada en los ordenadores que consiste en guardar la información más utilizada en una localización más cercana (más accesible y rápida) al elemento que necesita esta información en vez de en su ubicación original.
No queda muy claro ¿verdad?
A ver si con un ejemplo se entiende mejor:
Volvamos al lector de las noticias y su programa navegador. Generalmente los navegadores van guardando una copia en el ordenador del usuario de las páginas y otros elementos (imágenes, archivos auxiliares, etc) que el usuario va visitando.
Con esto lo que se consigue es que cuando visitamos una página en la que ya hemos estado anteriormente el navegador nos muestra la copia que guardó en la anterior visita, en vez de recuperar los contenidos de la página de internet.
Obviamente, la página se carga en el navegador instantáneamente ya que está guardada en el mismo ordenador del usuario. La desventaja de esto es que si la página "verdadera" ha cambiado mientras, no nos enteramos.
La ubicación donde el navegador guarda estas páginas temporales es la llamada caché del navegador.
No sólo "cachean" (disculpen el barbarismo) los navegadores. Como decíamos, esta técnica se utiliza mucho, y a todos los niveles: desde los microprocesadores (CPU) hasta los programas que utilizamos los usuarios finales.
Esta misma página que Ud. está leyendo ha sido cacheada varias veces por distintos dispositivos y programas.
La mayoría de las páginas web hoy en día no son estáticas, sino dinámicas, esto es, se generan "al vuelo", cuando alguien (el lector) las solicita a un servidor web.
Este texto que estoy escribiendo, el título, la fecha y demás datos se guardan en una base de datos. Cuando alguien solicita esta página, el servidor web a su vez pide los datos a la base de datos (que puede estar en la misma máquina o en otra). Una vez obtenidos los datos necesarios, "compone" la página dinámicamente, poniendo el título en un sitio, el texto en otro, añadiendo el encabezado de la página y el pie. Una vez montada la página, la devuelve al cliente (la persona que desde su navegador solicitó la página).
En este sencillo proceso se cachea casi todo por razones de eficiencia. Si a la base de datos le va a llegar muchas veces la solicitud "dame el título, texto y fecha del artículo X", el programa que la gestiona guardará en memoria los resultados de esta consulta, para que la siguiente vez que se lo pidan pueda devolver estos datos con mayor rapidez.
El servidor web, una vez que tiene los datos, como decíamos, "monta" la página final y la guarda también, para que la siguiente vez que le sea solicitada no tenga que repetir la consulta a la base de datos ni el proceso de montaje.
Finalmente, el navegador de la persona que solicitó la página con toda probabilidad también cacheará la página, o algunos de sus elementos, para que en una posterior visita no tenga que solicitarla de nuevo al servidor web.
La duda que nos puede surgir es ¿cuánto tiempo permanecen los datos en las cachés? En algún momento tendrán que renovarse, si no, veríamos siempre todo igual.
La respuesta es compleja, y depende mucho de la tipología del sitio web, del número de visitas y muchos más factores. Por ejemplo, este blog actualiza su caché cada 5 minutos aproximadamente. Otras páginas web, en las que la información varía más en el tiempo (por ejemplo, la página web del diario Público) se actualizan con mayor frecuencia. A menudo se busca un compromiso entre la conveniencia de cachear páginas (se sirven con mayor rapidez) y la necesidad de que éstas estén actualizadas.
miércoles, 28 de noviembre de 2007
Patrones de diseño para torpes - 2ª parte
Seguimos la serie de artículos sobre patrones de diseño. Vamos a ver otro de los patrones más típicos.
Usted es el/la encargado/a de la hemeroteca de un laboratorio. Periódicamente se reciben revistas sobre diferentes temas y con una periodicidad variable: unas son semanales, otras quincenales y otras mensuales.
Una de sus funciones es hacer llegar las revistas a diferentes personas de diferentes departamentos. Por ejemplo, la revista "Genómica de las hormigas" debe llegar al laboratorio de genética, la revista "Cristalografía de minerales venusianos" va al departamento de cristalografía, etc.
Imagínese ahora que cada persona de cada departamento estuviese cada dos por tres llamándole para preguntarle si ha llegado su revista, o, peor aún, entrara en su despacho y revolviese su mesa y el archivo buscando su preciada revista.
Obviamente, las personas no trabajamos así, en este ejemplo, lo más lógico, cómodo y organizado es que Ud. mantenga una lista de las personas o departamentos y notifique a estos la llegada de las revistas. Cada departamento decide entonces qué hacer con la revista (fotocopiarla, escanearla, ..., incluso leerla)
Cuando desarrollamos programas hay distintos módulos o unidades funcionales que deben interaccionar entre ellos, pero esta interacción no siempre es tan limpia o aséptica como sería deseable. En ocasiones un módulo, clase, función (o lo que sea) llega a "meterse en el despacho" de otra unidad funcional.
Pongamos un ejemplo más "software". En el libro "Desing Patterns" que mencionábamos en el anterior artículo proponen dos ejemplos muy ilustrativos:
Distinguimos entonces el objeto observado y los objetos observadores. El objeto observado debe mantener una relación de los objetos que le observan y una forma de notificarles. Por su parte, los objetos observadores, sean del tipo que sean, deben implementar alguna funcionalidad para actualizarse en función del nuevo estado del objeto observado.
En el artículo "Five common PHP design patterns" nos proponen algunos ejemplos en PHP muy interesantes. Vamos a adaptar un poco el ejemplo correspondiente al patrón observer y "traducirlo".
Las clases observadoras, independientemente de su naturaleza, deben tener un método común para ser notificadas por el observado. Esto puede garantizarse definiendo una interfaz (IntfzObservador en el ejemplo) y forzando a que estas clases observadoras implementen la interfaz.
El código es autoexplicativo. Tenemos dos observadores que "reaccionan" de diferente forma a los cambios en el observado. Uno de ellos de dedica a notificar los usuarios nuevos, otro los graba en una base de datos, otro los da de alta en el sistema, ...
Cada vez que se añade el objeto ListaUsuarios añade un usuario, notifica a sus observadores y éstos hacen sus tareas, sin interferir con este objeto observado.
Veamos la salida de este programa:
~ $ php test.php
Se ha añadido 'Juana' a la lista de usuarios.
Se ha grabado el usuario 'Juana' en la base de datos.
Se ha creado una cuenta para el usuario 'Juana'.
Se ha añadido 'Pedro' a la lista de usuarios.
Se ha grabado el usuario 'Pedro' en la base de datos.
Se ha creado una cuenta para el usuario 'Pedro'.
~ $
El patrón "Observer"
Usted es el/la encargado/a de la hemeroteca de un laboratorio. Periódicamente se reciben revistas sobre diferentes temas y con una periodicidad variable: unas son semanales, otras quincenales y otras mensuales.
Una de sus funciones es hacer llegar las revistas a diferentes personas de diferentes departamentos. Por ejemplo, la revista "Genómica de las hormigas" debe llegar al laboratorio de genética, la revista "Cristalografía de minerales venusianos" va al departamento de cristalografía, etc.
Imagínese ahora que cada persona de cada departamento estuviese cada dos por tres llamándole para preguntarle si ha llegado su revista, o, peor aún, entrara en su despacho y revolviese su mesa y el archivo buscando su preciada revista.
Obviamente, las personas no trabajamos así, en este ejemplo, lo más lógico, cómodo y organizado es que Ud. mantenga una lista de las personas o departamentos y notifique a estos la llegada de las revistas. Cada departamento decide entonces qué hacer con la revista (fotocopiarla, escanearla, ..., incluso leerla)
Cuando desarrollamos programas hay distintos módulos o unidades funcionales que deben interaccionar entre ellos, pero esta interacción no siempre es tan limpia o aséptica como sería deseable. En ocasiones un módulo, clase, función (o lo que sea) llega a "meterse en el despacho" de otra unidad funcional.
Pongamos un ejemplo más "software". En el libro "Desing Patterns" que mencionábamos en el anterior artículo proponen dos ejemplos muy ilustrativos:
- Una hoja de cálculo puede tener varias vistas (formas de presentar los datos) activas en un momento dado: un gráfico de barras, una rejilla de datos, un gráfico por sectores, ...
Si los datos cambian, todas las vistas deben actualizarse. La forma más cómoda es tener un objeto "Datos" que informa a todos los objetos "Presentación" de los cambios que se producen. Estos objetos "Presentación" ya se ocuparán ellos de actualizarse.
Lo bueno de este patrón es que los objetos "Presentación" no deben "meterse en el despacho" del objeto "Datos" para consultar si estos datos han cambiado o no. - El otro ejemplo que se propone es un reloj. Tenemos un objeto "Temporizador" que cada segundo notifica a todos los objetos que le observan (un "RelojDigital", un "RelojAnalógico", ...) de que algo ha cambiado.
Distinguimos entonces el objeto observado y los objetos observadores. El objeto observado debe mantener una relación de los objetos que le observan y una forma de notificarles. Por su parte, los objetos observadores, sean del tipo que sean, deben implementar alguna funcionalidad para actualizarse en función del nuevo estado del objeto observado.
En el artículo "Five common PHP design patterns" nos proponen algunos ejemplos en PHP muy interesantes. Vamos a adaptar un poco el ejemplo correspondiente al patrón observer y "traducirlo".
<?php
interface IntfzObservador {
function hayCambios($observado, $datos);
}
class NotificadorUsuarios implements IntfzObservador {
public function hayCambios($sender, $args) {
// Código para notificar: mensaje en consola,
// registro en un fichero 'log', etc.
echo("Se ha añadido '$args' a la lista de usuarios.n");
}
}
class GrabadorBBDDUsuarios implements IntfzObservador {
public function hayCambios($sender, $args) {
// Código para grabar en BBDD.
echo("Se ha grabado el usuario '$args' en la base de datos.n");
}
}
class AltaSistemaUsuarios implements IntfzObservador {
public function hayCambios($sender, $args) {
// Código para crear la cuenta de usuario.
echo("Se ha creado una cuenta para el usuario '$args'.n");
}
}
class ListaUsuarios {
private $observadores = array();
public function anadirUsuario($nombre) {
foreach($this->observadores as $obs)
$obs->hayCambios($this, $nombre);
}
public function anadirObservador($observador) {
$this->observadores[]= $observador;
}
}
/** Código de pruebas **/
$nu = new NotificadorUsuarios();
$gbu = new GrabadorBBDDUsuarios();
$asu = new AltaSistemaUsuarios();
$lu = new ListaUsuarios();
$lu->anadirObservador($nu);
$lu->anadirObservador($gbu);
$lu->anadirObservador($asu);
$lu->anadirUsuario("Juana");
$lu->anadirUsuario("Pedro");
?>
Las clases observadoras, independientemente de su naturaleza, deben tener un método común para ser notificadas por el observado. Esto puede garantizarse definiendo una interfaz (IntfzObservador en el ejemplo) y forzando a que estas clases observadoras implementen la interfaz.
El código es autoexplicativo. Tenemos dos observadores que "reaccionan" de diferente forma a los cambios en el observado. Uno de ellos de dedica a notificar los usuarios nuevos, otro los graba en una base de datos, otro los da de alta en el sistema, ...
Cada vez que se añade el objeto ListaUsuarios añade un usuario, notifica a sus observadores y éstos hacen sus tareas, sin interferir con este objeto observado.
Veamos la salida de este programa:
~ $ php test.php
Se ha añadido 'Juana' a la lista de usuarios.
Se ha grabado el usuario 'Juana' en la base de datos.
Se ha creado una cuenta para el usuario 'Juana'.
Se ha añadido 'Pedro' a la lista de usuarios.
Se ha grabado el usuario 'Pedro' en la base de datos.
Se ha creado una cuenta para el usuario 'Pedro'.
~ $
lunes, 19 de noviembre de 2007
domingo, 4 de noviembre de 2007
Colores
En el colegio nos enseñaban que los colores primarios eran amarillo, rojo y azul, que mezclando azul y amarillo salía color verde ...Luego empezamos a trabajar con pantallas y nos encontramos con que los colores "primarios" son los del sistema RGB (rojo, verde y azul) y que rojo y verde da amarillo.
Cualquiera que sepa algo de diseño sabe que son dos sistemas de color diferentes, el aditivo y el sustractivo, y que los colores primarios de cada sistema no son los mismos, aunque coloquialmente se les llame igual.
Pero claro, a un pobre programador como yo, al que si le sacas de lo suyo está totalmente perdido, estas cosas se le escapan ;-)
El problema es que el "rojo" del sistema RGB (#FF0000) en realidad es "rojo anaranjado", el "azul" RGB (#0000FF) es "azul violáceo".
En esta figura se ve la "equivalencia" entre los dos sistemas. Las mezclas funcionan entre dos colores alternos. Por ejemplo, rojo + verde = amarillo, verde + azul = cian, ...
Para saber más, este "post" en malaciencia.info
viernes, 2 de noviembre de 2007
Tira nº 57: corte y confección
Ahora en serio: en mi blog estoy haciendo una serie "divulgativa" sobre patrones de diseño.
El primero que trato de explicar es el patron "factory".
martes, 30 de octubre de 2007
Patrones de diseño para torpes - 1ª parte
Hoy hablamos de los famosos patrones de diseño o design patterns. Hay montones de libros y artículos sobre el tema, empezando por el famoso libro "Desing Patterns", de Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides.
El caso es que no me acabo de enterar muy bien (a ratos soy un poco lerdo) y me pierdo un poco, así que he decidido explicarme a mí mismo algunos patrones de diseño típicos.
Una de las cosas que no me gustan es que las explicaciones y ejemplos que se proponen en muchos libros o artículos están relacionadas con objetos "sofware". ¿No es acaso la programación orientada a objetos una ayuda para representar o modelizar sistemas u objetos "reales"?
Pues voy a tratar de explicar los patrones de diseño con ejemplos cotidianos, no "software", a ver qué tal me sale.
Este patrón de diseño es muy útil cuando tenemos que crear (=instanciar) distintos objetos que tienen algo en común (=comparten una interfaz). Ya me he liado con tecnicismos.
Imaginemos que vamos con nuestra cámara de fotos y el coche teledirijido de nuestr@ hij@ a una tienda de electricidad para comprar pilas. El enfoque "sencillo" (=aplicando un patrón de diseño) es decirle al vendedor: "quiero pilas para estos cacharros". El enfoque complicado (=instanciar cada objeto por separado) es decirl: "quiero pilas AAA (de 1,5 V) para la cámara, una pila de petaca de 9V para el mando y pilas AA para el cochecito".
Analicemos el objeto demandado en cuestión: las pilas. ¿Qué caracteriza a una pila? Su voltaje, su tamaño y poco más. Es decir, las pilas tienen una interfaz común, pero son diferentes unas de otras. Si tuviésemos que modelizarlas usando clases tendríamos la clase PilaAAA, PilaPetaca, PilaAA y alguna más.
Cada uno de estos objetos instanciados deberíamos asociarlo a su receptor:
¿No sería más cómodo tener algo (=el dependiente) que se encargase de darnos las pilas con sólo decirle para qué las queremos?
Parece un gran avance, ¿no? Cada objeto cliente (la cámara, el mando a distancia y el cochecito) se despreocupan de saber qué características tienen las pilas que usan. Simplemente le piden pilas al dependiente y listo.
Es tarea del dependiente saber qué tipo de pilas tiene que devolver, y la forma de hacerlo (=implementación) es transparente para el cliente. Hoy puede que el dependiente mire un catálogo, mañana puede que consulte una base de datos y pasado mañana a lo mejor solicita un fichero XML de aparatos y pilas, pero esto no es algo que deba saber el objeto cliente.
Bien, pues simplificando bastante, el patrón "Factory" es esto mismo. Un objeto especializado se encarga de instanciar objetos para clientes, y estos utilizan los métodos que proporciona la interfaz del objeto recibido, pero sin saber nada de las interioridades del objeto, ni siquiera qué tipo de objeto es (=a partir de qué clase está instanciado).
Veamos un ejemplo un poco más "software". Imaginemos que tenemos una clase sencilla en una aplicación de blogs que se dedica a "pintar" en pantalla el título, autor y fecha de publicación de algunos envíos.
Estos envíos pueden estar guardados en una base de datos o provenir de un RSS, por ejemplo.
A la clase cliente (la que "pinta" en pantalla") le da igual el origen de los datos, sólo quiere los datos. Voy a poner un poco de código --utilizaré Python, que me gusta bastante ;-) y me parece muy claro.
Unas notas sobre la terminología "pythonera": los métodos se definen con def, las clases se instancian llamando al nombre de la clase, sin new. El constructor (algo parecido, realmente) es el método __init__. Por últimos, los métodos al definirse siempre deben llevar el self por delante. Realmente Python no es un lenguaje orientado a objetos puro, pero ni falta que le hace ;-)
Para finalizar, muy importante: esto no es una lección magistral. Es mi visión personal del patrón "Factory", que puede ser errónea e incompleta. Se admiten (se ruegan) sugerencias y comentarios.
El caso es que no me acabo de enterar muy bien (a ratos soy un poco lerdo) y me pierdo un poco, así que he decidido explicarme a mí mismo algunos patrones de diseño típicos.
Una de las cosas que no me gustan es que las explicaciones y ejemplos que se proponen en muchos libros o artículos están relacionadas con objetos "sofware". ¿No es acaso la programación orientada a objetos una ayuda para representar o modelizar sistemas u objetos "reales"?
Pues voy a tratar de explicar los patrones de diseño con ejemplos cotidianos, no "software", a ver qué tal me sale.
El patrón "Factory"
Este patrón de diseño es muy útil cuando tenemos que crear (=instanciar) distintos objetos que tienen algo en común (=comparten una interfaz). Ya me he liado con tecnicismos.
Imaginemos que vamos con nuestra cámara de fotos y el coche teledirijido de nuestr@ hij@ a una tienda de electricidad para comprar pilas. El enfoque "sencillo" (=aplicando un patrón de diseño) es decirle al vendedor: "quiero pilas para estos cacharros". El enfoque complicado (=instanciar cada objeto por separado) es decirl: "quiero pilas AAA (de 1,5 V) para la cámara, una pila de petaca de 9V para el mando y pilas AA para el cochecito".
Analicemos el objeto demandado en cuestión: las pilas. ¿Qué caracteriza a una pila? Su voltaje, su tamaño y poco más. Es decir, las pilas tienen una interfaz común, pero son diferentes unas de otras. Si tuviésemos que modelizarlas usando clases tendríamos la clase PilaAAA, PilaPetaca, PilaAA y alguna más.
mi_pilaAAA = new PilaAAA()
mi_pilaPetaca = new PilaPetaca()
mi_pilaAA = new PilaAA()
Cada uno de estos objetos instanciados deberíamos asociarlo a su receptor:
camara_fotos.setPila(mi_pilaAAA)
mando_distancia.setPila(mi_pilaPetaca)
cochecito.setPila(mi_pilaAA)
¿No sería más cómodo tener algo (=el dependiente) que se encargase de darnos las pilas con sólo decirle para qué las queremos?
dependiente = new Dependiente()
camara_fotos.setPila(dependiente.damePilas(this))
mando_distancia.setPila(dependiente.damePilas(this))
cochecito.setPila(dependiente.damePilas(this))
Parece un gran avance, ¿no? Cada objeto cliente (la cámara, el mando a distancia y el cochecito) se despreocupan de saber qué características tienen las pilas que usan. Simplemente le piden pilas al dependiente y listo.
Es tarea del dependiente saber qué tipo de pilas tiene que devolver, y la forma de hacerlo (=implementación) es transparente para el cliente. Hoy puede que el dependiente mire un catálogo, mañana puede que consulte una base de datos y pasado mañana a lo mejor solicita un fichero XML de aparatos y pilas, pero esto no es algo que deba saber el objeto cliente.
Bien, pues simplificando bastante, el patrón "Factory" es esto mismo. Un objeto especializado se encarga de instanciar objetos para clientes, y estos utilizan los métodos que proporciona la interfaz del objeto recibido, pero sin saber nada de las interioridades del objeto, ni siquiera qué tipo de objeto es (=a partir de qué clase está instanciado).
Veamos un ejemplo un poco más "software". Imaginemos que tenemos una clase sencilla en una aplicación de blogs que se dedica a "pintar" en pantalla el título, autor y fecha de publicación de algunos envíos.
Estos envíos pueden estar guardados en una base de datos o provenir de un RSS, por ejemplo.
A la clase cliente (la que "pinta" en pantalla") le da igual el origen de los datos, sólo quiere los datos. Voy a poner un poco de código --utilizaré Python, que me gusta bastante ;-) y me parece muy claro.
class EnviosRSS:
def __init__(self, url_rss):
# Hacemos algo para traer los datos de la url
self.post = lo_que_sea
def dameAutor(self):
return self.post.autor
def dameTitulo(self):
return self.post.titulo
def dameFecha(self):
return self.post.fecha
class EnviosBBDD:
def __init__(self):
# Hacemos algo para traer los datos de la base de datos
self.post = lo_que_sea
def dameAutor(self):
return self.post.autor
def dameTitulo(self):
return self.post.titulo
def dameFecha(self):
return self.post.fecha
class EnviosFactory:
def dameEnvios(self, url=''):
if url == '':
return EnviosBBDD()
else:
return EnviosRSS(url)
# código cliente
factory = EnviosFactory()
envios1 = factory.dameEnvios()
envios2 = factory.dameEnvios('http://davidasorey.net/index.php/feed/rss')
# pintamos los envios
print envios1.dameTitulo()
print envios1.dameAutor()
print envios1.dameFecha()
print envios2.dameTitulo()
print envios2.dameAutor()
print envios2.dameFecha()
Unas notas sobre la terminología "pythonera": los métodos se definen con def, las clases se instancian llamando al nombre de la clase, sin new. El constructor (algo parecido, realmente) es el método __init__. Por últimos, los métodos al definirse siempre deben llevar el self por delante. Realmente Python no es un lenguaje orientado a objetos puro, pero ni falta que le hace ;-)
Para finalizar, muy importante: esto no es una lección magistral. Es mi visión personal del patrón "Factory", que puede ser errónea e incompleta. Se admiten (se ruegan) sugerencias y comentarios.
miércoles, 24 de octubre de 2007
Comparativa de “Frameworks” para PHP
Volvemos con la palabreja de moda: framework. Tras el enorme éxito de Ruby On Rails y otros framework como Trails, Django o TurboGears, el mundillo PHP se ha puesto las pilas y han surgido algunos proyectos similares.
¿Por qué utilizar PHP como lenguaje base para un framework en vez de otros lenguajes con una orientación a objetos más definida o clara como Ruby, Python o Java? [1]
La razón principal, en muchos casos, es la amplia extensión de PHP en los servidores. Prácticamente todos los proveedores suministran planes de hosting con PHP y MySQL. Si no se dispone de un servidor dedicado o especializado, no es habitual poder contar con Ruby, Java o Python para hacer desarrollos.
En mi opinión, los frameworks para PHP con más aceptación son el Zend Framework, CakePHP y Symfony. Mi impresión es que Zend Framework es, sobre todo, una colección de clases, paquetes y herramientas, mientras que CakePHP y Symfony son más del estilo RoR.
Entre CakePHP y Symfony se puede decir que el primero es más sencillo y que el segundo ofrece más características. Sinceramente, la mejor forma de evaluarlos es dedicando unas horas a cada uno, pero no siempre tenemos tiempo para esto. Afortunadamente, he encontrado dos comparativas (en inglés) muy ilustrativas:
[1] PHP 5 ha mejorado mucho en lo que a programación orientada a objetos se refiere. Ya tenemos control de acceso en los métodos, gestión de excepciones, ...
¿Por qué utilizar PHP como lenguaje base para un framework en vez de otros lenguajes con una orientación a objetos más definida o clara como Ruby, Python o Java? [1]
La razón principal, en muchos casos, es la amplia extensión de PHP en los servidores. Prácticamente todos los proveedores suministran planes de hosting con PHP y MySQL. Si no se dispone de un servidor dedicado o especializado, no es habitual poder contar con Ruby, Java o Python para hacer desarrollos.
En mi opinión, los frameworks para PHP con más aceptación son el Zend Framework, CakePHP y Symfony. Mi impresión es que Zend Framework es, sobre todo, una colección de clases, paquetes y herramientas, mientras que CakePHP y Symfony son más del estilo RoR.
Entre CakePHP y Symfony se puede decir que el primero es más sencillo y que el segundo ofrece más características. Sinceramente, la mejor forma de evaluarlos es dedicando unas horas a cada uno, pero no siempre tenemos tiempo para esto. Afortunadamente, he encontrado dos comparativas (en inglés) muy ilustrativas:
- H3RALD.com -> Rails-inspired PHP frameworks
- PHPit.net -> Taking a look at ten different PHP frameworks
[1] PHP 5 ha mejorado mucho en lo que a programación orientada a objetos se refiere. Ya tenemos control de acceso en los métodos, gestión de excepciones, ...
jueves, 18 de octubre de 2007
Virtualización en Mac OSX
Existen numerosas soluciones de virtualización para el Mac OSX, algunas propietarias y otras libres (Parallels, VMware Fusion, Bochs, Qemu, ...)
Actualmente estoy utilizando Qemu. Según la documentación, puede emular a un procesador x86 con una frecuencia de 500 MHz. Más que suficiente para hacer pruebas sin tener que reinicar el equipo con otro OS.
Existe un "front-end" para Mac OSX y Qemu llamado Q. Tiene algunas características muy agradables, como una interfaz bastante amigable, la posibilidad de descargarse imágenes de máquinas virtuales preinstaladas, redimensionamiento de la pantalla automático, un cambio de host a anfitrión rápido, ...
En la siguiente captura se ve un Ubuntu corriendo en modo texto, iniciamos la sesión gráfica (startx), pasamos a pantalla completa y luego cambiamos de anfitrión a host varias veces. El efecto de cubo rotando está bastante conseguido.
[youtube p1b4SMkb-zM nolink]
Actualmente estoy utilizando Qemu. Según la documentación, puede emular a un procesador x86 con una frecuencia de 500 MHz. Más que suficiente para hacer pruebas sin tener que reinicar el equipo con otro OS.
Existe un "front-end" para Mac OSX y Qemu llamado Q. Tiene algunas características muy agradables, como una interfaz bastante amigable, la posibilidad de descargarse imágenes de máquinas virtuales preinstaladas, redimensionamiento de la pantalla automático, un cambio de host a anfitrión rápido, ...
En la siguiente captura se ve un Ubuntu corriendo en modo texto, iniciamos la sesión gráfica (startx), pasamos a pantalla completa y luego cambiamos de anfitrión a host varias veces. El efecto de cubo rotando está bastante conseguido.
[youtube p1b4SMkb-zM nolink]
miércoles, 17 de octubre de 2007
Microsiervos …
Me gusta(ba) mucho leer Microsiervos, pero, cada vez más, me recuerdan a los publireportajes que aparecen a veces en los periódicos simulando ser una noticia ...
viernes, 12 de octubre de 2007
La pesadilla de los “encoding” (2ª parte)
Decíamos en la anterior entrada que cuando un fichero puede codificarse con UTF-8. Existen dos variantes del formato UTF-8: con BOM y sin BOM. BOM son dos bytes (FE FF) al principio de un fichero que, simplificando mucho, indican el orden de los bytes.
Guárdese un fichero codificado en UTF-8 con el BOM y tendrá problemas con la mayoría de sus scripts en PHP o ficheros XML, ya que el fichero realmente no comenzará como "<?php" o "<?xml".
Imaginen ahora el siguiente entorno de trabajo: un servidor web más o menos moderno que sirve los documentos por defecto con la codificación UTF-8, un desarrollador con una estación de trabajo Windows o Linux y un diseñador con la estación de trabajo Mac. Si el desarrollador y el diseñador no vigilan el "encoding" con el que guardan sus ficheros habrá problemas con seguridad. Muchas herramientas de desarrollo y/o diseño Web guardan por defecto los ficheros codificados con ISO-8859-1, otras lo guardan en UTF-8 con BOM.
Por supuesto, existen soluciones, a nivel servidor (ficheros .htaccess con la directiva AddDefaultCharset) y a nivel estación de trabajo utilizando herramientas competentes que puedan lidiar con las diferentes codificaciones.
Esta es la típica página que se ve mal porque el servidor sirve en ISO-8859-1 y el fichero está codificado como UTF-8:
Se puede ver cómo los caracteres acentuados (ocupan 2 bytes en Unicode) son interpretados como 2 caracteres sencillos.
En el blog de Juque hay más ejemplos y se amplía más la información.
La conclusión final que obtengo es la siguiente: si no se puede garantizar una uniformidad en las plataformas de trabajo (que todo el mundo trabaje con el mismo "encoding"), lo más seguro es utilizar las entidades HTML de toda la vida (á en vez de á, ñ en vez de ñ, ...)
Guárdese un fichero codificado en UTF-8 con el BOM y tendrá problemas con la mayoría de sus scripts en PHP o ficheros XML, ya que el fichero realmente no comenzará como "<?php" o "<?xml".
Imaginen ahora el siguiente entorno de trabajo: un servidor web más o menos moderno que sirve los documentos por defecto con la codificación UTF-8, un desarrollador con una estación de trabajo Windows o Linux y un diseñador con la estación de trabajo Mac. Si el desarrollador y el diseñador no vigilan el "encoding" con el que guardan sus ficheros habrá problemas con seguridad. Muchas herramientas de desarrollo y/o diseño Web guardan por defecto los ficheros codificados con ISO-8859-1, otras lo guardan en UTF-8 con BOM.
Por supuesto, existen soluciones, a nivel servidor (ficheros .htaccess con la directiva AddDefaultCharset) y a nivel estación de trabajo utilizando herramientas competentes que puedan lidiar con las diferentes codificaciones.
Esta es la típica página que se ve mal porque el servidor sirve en ISO-8859-1 y el fichero está codificado como UTF-8:
Se puede ver cómo los caracteres acentuados (ocupan 2 bytes en Unicode) son interpretados como 2 caracteres sencillos.
En el blog de Juque hay más ejemplos y se amplía más la información.
La conclusión final que obtengo es la siguiente: si no se puede garantizar una uniformidad en las plataformas de trabajo (que todo el mundo trabaje con el mismo "encoding"), lo más seguro es utilizar las entidades HTML de toda la vida (á en vez de á, ñ en vez de ñ, ...)
miércoles, 3 de octubre de 2007
La pesadilla de los “encoding”
Estamos en el año 2007. Internet forma parte de las vidas de muchas personas. Pues, por increíble que parezca, algun@s todavía tenemos que lidiar con problemas cuyo origen se remonta a varias décadas atrás.
Antecedentes: en los años 60 se aprobó un código estándard para la codificación de caracteres alfanuméricos. Era una buena idea, puesto que hasta el momento, cada fabricante usaba más o menos el código que le daba la gana. Con este código, ASCII, se consiguió una cierta estandarización.
La idea era utilizar 7 bits (lo que nos da 2^7 = 128 códigos diferentes) para representar los caracteres y símbolos del lenguaje escrito. Por ejemplo, el 65 (0100 0001 en binario) representaba la letra A (en mayúscula), el 32 (0010 0000 en binario) representaba el espacio en blanco, etc.
Magnífica ocurrencia, si tu idioma es inglés. En seguida l@s europe@s nos dimos cuenta de que este sistema no era muy válido: muchos caracteres no tenían representación: eñes, cedillas (ç), vocales con diversos acentos (á, à, â, ä, ...)
La solución que se encontró fue rápida: ya que un byte tiene 8 bits y el ASCII sólo utiliza 7 (el octavo bit se destinó para control de errores), se decidió utilizar ese octavo bit para ampliar el rango de caracteres disponibles (2^8 = 256). Surgía la codificación ISO-8859.
También parecía una buena idea, pero no resultó ser tan idónea: algunos idiomas necesitaban una ñ, por ejemplo, pero otros necesitaban una ç. Algunos idiomas europeos sólo necesitaban un tipo de acentos, pero otros utilizaban más. El resultado de estas necesidades diferentes fue que no se llegó a una única codificación utilizando 8 bits. La codificación ISO-8859-1 (también llamada Latin-1) sirve para casi todos los idiomas de Europa Occidental, la ISO-8859-15 es una revisión de ésta que incluye el símbolo del euro (€). La codificación ISO-8859-16 (Latin-2) se adapta a idiomas de Europa Oriental.
Por otra parte, otros fabricantes decidieron hacer lo que les pareció con el 8º bit no utilizado. Añadieron nuevos símbolos o caracteres extraños al ASCII estándar. Surgen así diversos "codepages" parcialmente compatibles entre ellos (CP437, Windows-1252, ...) y con ISO-8859
Estas codificaciones extendidas supusieron una mejora, pero no fueron el remedio definitivo. Además de mantenerse ciertas incompatibilidades, no servían para codificar algunos idiomas no alfabéticos (idiomas fonéticos o ideográficos).
La siguiente idea fue Unicode: utilizar 2 byte completos (o más) para representar los caracteres o símbolos. Con 2 bytes (2^16) ya tenemos 65.536 posibilidades o símbolos diferentes. Unicode consigue representar y asignar un código único a prácticamente cualquier símbolo escrito en cualquier idioma humano. Además, mantiene la compatibilidad con ASCII y Latin-1: los 128 primeros caracteres de Unicode se corresponden con la codificación ASCII, y los 128 siguientes (hasta 256) se corresponden con Latin-1.
El problema de Unicode es la transmisión de los datos: es absurdo reservar siempre dos bytes para un carácter cuando la mayor parte de los caracteres Unicode que se pueden transmitir en un momento dado "caben" en un byte. Las diferentes formas de transmitir e interpretar los caracteres Unicode son los famosos UTF, siendo los más utilizados UTF-8 y UTF-16.
Seguiremos con el tema.
Antecedentes: en los años 60 se aprobó un código estándard para la codificación de caracteres alfanuméricos. Era una buena idea, puesto que hasta el momento, cada fabricante usaba más o menos el código que le daba la gana. Con este código, ASCII, se consiguió una cierta estandarización.
La idea era utilizar 7 bits (lo que nos da 2^7 = 128 códigos diferentes) para representar los caracteres y símbolos del lenguaje escrito. Por ejemplo, el 65 (0100 0001 en binario) representaba la letra A (en mayúscula), el 32 (0010 0000 en binario) representaba el espacio en blanco, etc.
Magnífica ocurrencia, si tu idioma es inglés. En seguida l@s europe@s nos dimos cuenta de que este sistema no era muy válido: muchos caracteres no tenían representación: eñes, cedillas (ç), vocales con diversos acentos (á, à, â, ä, ...)
La solución que se encontró fue rápida: ya que un byte tiene 8 bits y el ASCII sólo utiliza 7 (el octavo bit se destinó para control de errores), se decidió utilizar ese octavo bit para ampliar el rango de caracteres disponibles (2^8 = 256). Surgía la codificación ISO-8859.
También parecía una buena idea, pero no resultó ser tan idónea: algunos idiomas necesitaban una ñ, por ejemplo, pero otros necesitaban una ç. Algunos idiomas europeos sólo necesitaban un tipo de acentos, pero otros utilizaban más. El resultado de estas necesidades diferentes fue que no se llegó a una única codificación utilizando 8 bits. La codificación ISO-8859-1 (también llamada Latin-1) sirve para casi todos los idiomas de Europa Occidental, la ISO-8859-15 es una revisión de ésta que incluye el símbolo del euro (€). La codificación ISO-8859-16 (Latin-2) se adapta a idiomas de Europa Oriental.
Por otra parte, otros fabricantes decidieron hacer lo que les pareció con el 8º bit no utilizado. Añadieron nuevos símbolos o caracteres extraños al ASCII estándar. Surgen así diversos "codepages" parcialmente compatibles entre ellos (CP437, Windows-1252, ...) y con ISO-8859
Estas codificaciones extendidas supusieron una mejora, pero no fueron el remedio definitivo. Además de mantenerse ciertas incompatibilidades, no servían para codificar algunos idiomas no alfabéticos (idiomas fonéticos o ideográficos).
La siguiente idea fue Unicode: utilizar 2 byte completos (o más) para representar los caracteres o símbolos. Con 2 bytes (2^16) ya tenemos 65.536 posibilidades o símbolos diferentes. Unicode consigue representar y asignar un código único a prácticamente cualquier símbolo escrito en cualquier idioma humano. Además, mantiene la compatibilidad con ASCII y Latin-1: los 128 primeros caracteres de Unicode se corresponden con la codificación ASCII, y los 128 siguientes (hasta 256) se corresponden con Latin-1.
El problema de Unicode es la transmisión de los datos: es absurdo reservar siempre dos bytes para un carácter cuando la mayor parte de los caracteres Unicode que se pueden transmitir en un momento dado "caben" en un byte. Las diferentes formas de transmitir e interpretar los caracteres Unicode son los famosos UTF, siendo los más utilizados UTF-8 y UTF-16.
Seguiremos con el tema.
martes, 11 de septiembre de 2007
MacOS X
Bueno, pues me he comprado un iMac (bastante bien de precio, era el modelo de "exposición" y me lo dejaron más barato). Por ahora estoy usando bastante el S.O. que trae (MacOS X 10.4 "Tiger") y la verdad es que es una maravilla para un usuario final. Sencillo, agradable a la vista, aspecto unificado, aplicaciones muy fáciles de instalar, bastantes utilidades incorporadas ...
No conocía el MacOS X y ahora veo de dónde vienen muchas ideas y novedades que veo en el escritorio Linux. El panel de preferencias del sistema de KDE es "calcado" al del Mac, las virguerías gráficas de Beryl/Compiz son muy parecidas al "Expose" del Mac, los gDesklets de Gnome son similares al "Dashboard" del Mac, ... Qué lástima que sea un sistema cerrado.
Echo en falta:
Por lo demás, una compra satisfactoria y un descubrimiento muy agradable.
Actualización: ya tengo apt-get en mi Mac, gracias al proyecto Fink.
Ejemplo de uso: sudo apt-get install wget ¡Genial!
No conocía el MacOS X y ahora veo de dónde vienen muchas ideas y novedades que veo en el escritorio Linux. El panel de preferencias del sistema de KDE es "calcado" al del Mac, las virguerías gráficas de Beryl/Compiz son muy parecidas al "Expose" del Mac, los gDesklets de Gnome son similares al "Dashboard" del Mac, ... Qué lástima que sea un sistema cerrado.
Echo en falta:
- Poder toquetear un poco más fácilmente las tripas del sistema (aunque con la Terminal se puede hacer lo que se quiera)
- Ratón con más de un botón (he acabado comprando un ratón de PC de toda la vida)
Actualización: leer los comentarios - apt-get (a ver si investigo un poco más Fink y Darwin Ports)
Por lo demás, una compra satisfactoria y un descubrimiento muy agradable.
Actualización: ya tengo apt-get en mi Mac, gracias al proyecto Fink.
Ejemplo de uso: sudo apt-get install wget ¡Genial!
jueves, 16 de agosto de 2007
Tira nº 56: fin de las vacaciones
En mi caso no llego a tanto, pero sí que han sido 800 Mb en fotos. Lo de las cámaras digitales es de locos. Al final sacas fotos hasta de las señales de tráfico.
martes, 24 de julio de 2007
Gambas tutorial
Gambas is an IDE ("Integrated Development Environment") oriented towards RAD ("Rapid Applications Development"), like the popular propietary programs Microsoft Visual Basic or Borland Delphi.You may read the tutorial here: Gambas Tutorial.
lunes, 23 de julio de 2007
Pitch & Tunning Studio
Pitch & Tunning Studio es un pequeño programa que sirve para evaluar las diferencias que hay entre los distintos sistemas de afinación de la música occidental (pitagórico, temperado y natural, entre otros).
Está desarrollado con el lenguaje Tcl/Tk y la librería Snack [1]
Por cierto, creo que es el último programa que escribo con este lenguaje.
No llega a 400 líneas de código y he acabado mareado con la sintaxis extraña de Tcl. En mi opinión y para mi gusto, sirve para programas cortos y scripts sencillos, pero no me veo a mí mismo escribiendo (y manteniendo) algo que tenga más de 1000 líneas de código con Tcl.
Además, el aspecto de los "widgets" es horroroso ;-)
A ver si encuentro algo parecido a Snack pero que no esté "atado" a un "toolkit" determinado. Y si lo puedo usar con Python, mejor que mejor.
Nota 1: realmente es impresionante lo que se puede llegar a hacer con Snack. En la distribución estándar vienen bastantes ejemplos (en Windows, en el directorio c:tcldemosSnack y en Linux, bajo /usr/share/doc/libsnack2/examples). Mis preferidos son generator2.tcl y formant.tcl, un generador o sintetizador de ondas estéreo y un sintetizador de formantes:
Como decía más arriba: ¡qué pena que Snack esté tan ligado a Tk!
Está desarrollado con el lenguaje Tcl/Tk y la librería Snack [1]
Por cierto, creo que es el último programa que escribo con este lenguaje.
No llega a 400 líneas de código y he acabado mareado con la sintaxis extraña de Tcl. En mi opinión y para mi gusto, sirve para programas cortos y scripts sencillos, pero no me veo a mí mismo escribiendo (y manteniendo) algo que tenga más de 1000 líneas de código con Tcl.
Además, el aspecto de los "widgets" es horroroso ;-)
A ver si encuentro algo parecido a Snack pero que no esté "atado" a un "toolkit" determinado. Y si lo puedo usar con Python, mejor que mejor.
Nota 1: realmente es impresionante lo que se puede llegar a hacer con Snack. En la distribución estándar vienen bastantes ejemplos (en Windows, en el directorio c:tcldemosSnack y en Linux, bajo /usr/share/doc/libsnack2/examples). Mis preferidos son generator2.tcl y formant.tcl, un generador o sintetizador de ondas estéreo y un sintetizador de formantes:
Como decía más arriba: ¡qué pena que Snack esté tan ligado a Tk!
jueves, 12 de julio de 2007
miércoles, 11 de julio de 2007
WinMMA
Como comentaba en otras entradas, utilizo bastante el programa MMA. Al ser un programa en línea de comandos y con un fuerte "sabor UNIX" los usuarios de Windows pueden encontrarlo un poco árido y difícil de utilizar.
El proyecto WinMMA pretende ayudar a los usuarios de Windows que quieren utilizar MMA. Actualmente consta de un instalador que incluye MMA, documentación, un editor de texto (SciTE) preconfigurado y un editor "visual" (LeMMA) y otros archivos de soporte (intérprete de Python, librerías, etc).
El proyecto WinMMA pretende ayudar a los usuarios de Windows que quieren utilizar MMA. Actualmente consta de un instalador que incluye MMA, documentación, un editor de texto (SciTE) preconfigurado y un editor "visual" (LeMMA) y otros archivos de soporte (intérprete de Python, librerías, etc).
miércoles, 4 de julio de 2007
Tira nº 53: el anuncio de un regreso
Hola de nuevo.
Esto es un nuevo intento de continuar con "La tira de Penti y Atlo".
Intentaré que al menos sea quincenal, pero no prometo nada ;-)
domingo, 1 de julio de 2007
Depurar PHP con Eclipse
Curioseando un rato ya encontré la forma de depurar PHP con Eclipse. Eso de saber por dónde va el código a base de sentencias echo y var_dump no es muy serio.
La empresa Zend proporciona un "plugin" basado en PDT que incorpora un producto llamado "Zend Debugger". En el momento de escribir ésto la versión "estable" de PDT es la 0.7, si bien existe una versión 1.0 que sólo funciona con Eclipse 3.3. El plugin que proporciona Zend se basa en PDT 1.0, pero funciona con Eclipse 3.2.
La instalación es muy fácil, en la página de Zend se describe. Sobre una instalación de Eclipse sólo hay que irse al "Update Manager", poner la URL de Zend (http://downloads.zend.com/pdt) y listo.
Al grano. Veamos cómo se depura.
Tenemos un script muy sencillo (hola.php):
<?
$uno = "Hola, ";
$dos = "mundo";
echo $uno . $dos . "!";
?>
Veamos cómo se depura. Creamos un "PHP Project" y un archivo "PHP file".
Haciendo doble click en el margen del editor de código se añade un punto de interrupción.
Con el botón derecho, damos al menú "Debug as PHP Script". Se nos cambia a la perspectiva de PHP Debug y empieza la fiesta: podemos examinar y modificar el contenido de variables, poner más puntos de interrupción, saltar funciones, lo típico en un depurador.
Lo que todavía no he conseguido es depurar las peticiones enviadas por el navegador ("Debug as PHP Web Page"). Estamos en ello ;-)
La empresa Zend proporciona un "plugin" basado en PDT que incorpora un producto llamado "Zend Debugger". En el momento de escribir ésto la versión "estable" de PDT es la 0.7, si bien existe una versión 1.0 que sólo funciona con Eclipse 3.3. El plugin que proporciona Zend se basa en PDT 1.0, pero funciona con Eclipse 3.2.
La instalación es muy fácil, en la página de Zend se describe. Sobre una instalación de Eclipse sólo hay que irse al "Update Manager", poner la URL de Zend (http://downloads.zend.com/pdt) y listo.
Al grano. Veamos cómo se depura.
Tenemos un script muy sencillo (hola.php):
<?
$uno = "Hola, ";
$dos = "mundo";
echo $uno . $dos . "!";
?>
Veamos cómo se depura. Creamos un "PHP Project" y un archivo "PHP file".
Haciendo doble click en el margen del editor de código se añade un punto de interrupción.
Con el botón derecho, damos al menú "Debug as PHP Script". Se nos cambia a la perspectiva de PHP Debug y empieza la fiesta: podemos examinar y modificar el contenido de variables, poner más puntos de interrupción, saltar funciones, lo típico en un depurador.
Lo que todavía no he conseguido es depurar las peticiones enviadas por el navegador ("Debug as PHP Web Page"). Estamos en ello ;-)
sábado, 23 de junio de 2007
¿Punto de inflexión?
Es la primera vez que un desarrollo chapuza llega a los medios de información generalistas y al gran público. Por supuesto, estoy hablando de la página web del Congreso de los Diputados.
Lo que comenzó siendo una crítica de algunos desarrolladores a una web realmente mal hecha ha terminado siendo un tema de conversación y de preocupación para el ciudadano de a pie.
Lo triste es que no es la primera vez que ocurre, sobre todo en desarrollos para la administración, donde el control del producto final no suele ser tan estricto como en corporaciones privadas.
Todos/as los que vivimos de esto sabemos cómo se trabaja en las grandes consultoras y empresas de desarrollo de software (hay excepciones, por lo visto: no todo va a ser malo)
Proyectos mal planificados y peor gestionados. Venta de "humo". Buzzwords. Incompetentes dirigiendo equipos y proyectos [1]. Intereses creados --"partners". Becarios "vendidos" a los clientes como expertos. Subcontratación. ¿Seguimos?
Ya está bien de tomaduras de pelo. A ver si a partir de ahora los clientes, los usuarios, la administración y la opinión pública en general se van concienciando de que las cosas se pueden hacer bien, pero si hay voluntad de hacerlas bien. Lamentablemente, hoy por hoy, lo que impera en el mercado no es la calidad del producto sino los beneficios y la supuesta rapidez en el desarrollo.
Nunca se han tenido tantas metodologías, herramientas y técnicas disponibles para el desarrollo de software (OOP, UML, Patrones de Diseño, bla, bla, bla, ...) De nada sirven si lo que al final tenemos es una porquería de producto.
Si una empresa privada quiere malgastar su dinero contratando desarrollos con consultoras con renombre pero cutres en el fondo, peor para esa empresa. Pero un desarrollo para la administración lo pagamos todos/as. No puede consentirse que estas chapuzas salgan a la calle.
Es obligatorio por ley que las páginas web de la administración sean accesibles. No vale con colocar el iconito de WAI, como hacen en muchas webs. Es ilegal hacer eso.
[1] Acabo de leer un artículo sobre esto en Fogonazos (mis felicitaciones a su autor). Lo clava.
Lo que comenzó siendo una crítica de algunos desarrolladores a una web realmente mal hecha ha terminado siendo un tema de conversación y de preocupación para el ciudadano de a pie.
Lo triste es que no es la primera vez que ocurre, sobre todo en desarrollos para la administración, donde el control del producto final no suele ser tan estricto como en corporaciones privadas.
Todos/as los que vivimos de esto sabemos cómo se trabaja en las grandes consultoras y empresas de desarrollo de software (hay excepciones, por lo visto: no todo va a ser malo)
Proyectos mal planificados y peor gestionados. Venta de "humo". Buzzwords. Incompetentes dirigiendo equipos y proyectos [1]. Intereses creados --"partners". Becarios "vendidos" a los clientes como expertos. Subcontratación. ¿Seguimos?
Ya está bien de tomaduras de pelo. A ver si a partir de ahora los clientes, los usuarios, la administración y la opinión pública en general se van concienciando de que las cosas se pueden hacer bien, pero si hay voluntad de hacerlas bien. Lamentablemente, hoy por hoy, lo que impera en el mercado no es la calidad del producto sino los beneficios y la supuesta rapidez en el desarrollo.
Nunca se han tenido tantas metodologías, herramientas y técnicas disponibles para el desarrollo de software (OOP, UML, Patrones de Diseño, bla, bla, bla, ...) De nada sirven si lo que al final tenemos es una porquería de producto.
Si una empresa privada quiere malgastar su dinero contratando desarrollos con consultoras con renombre pero cutres en el fondo, peor para esa empresa. Pero un desarrollo para la administración lo pagamos todos/as. No puede consentirse que estas chapuzas salgan a la calle.
Es obligatorio por ley que las páginas web de la administración sean accesibles. No vale con colocar el iconito de WAI, como hacen en muchas webs. Es ilegal hacer eso.
[1] Acabo de leer un artículo sobre esto en Fogonazos (mis felicitaciones a su autor). Lo clava.
viernes, 11 de mayo de 2007
(Re)Descubriendo Tcl/Tk
En esto tiempos aciagos para los/as programadores/as, en los que cada dos días sale un lenguaje o herramienta nuevos, en los que para montar una sencilla web hay que lidiar con los omnipresentes patrones de diseño, montones de capas de abstracción y demás, se agradece la simplicidad y sencillez de los viejos tiempos.
Hacía mucho que no hacía nada con Tcl/Tk, y el otro día recordé que existe todavía la estupenda librería Snack. Es una librería de tratamiento y generación de sonido en tiempo real.
Así que, provisto del tutorial de Snack y la documentación de Tcl/Tk pertinente, me hice un pequeño afinador (cutre: sólo da notas de referencia, no "lee" las notas del instrumento):
(Captura de pantalla en Windows)
En 65 líneas de código simple tenemos casi un programa completo:
Código (renombrar a tuner.tcl)
Lo que más atención me llama es que a cada "widget" se le puede asociar una variable (global) de tal forma que, al cambiar la variable, se actualiza el elemento convenientemente. Por ejemplo, el "message" y el "spinbox" tienen asociados dos variables, newfreq y octave, respectivamente.
Desde el procedimiento beep modificamos newfreq y el texto de la etiqueta cambia.
Ocultamiento de información y encapsulamiento: ninguno. ¿Acaso es necesario siempre? ;-)
Recursos
Tcl significa "Tool Command Language" y Tk "ToolKit". Es un lenguaje de "script", con una sintaxis muy similar a la de cualquier "shell" (como Bash).
Hacía mucho que no hacía nada con Tcl/Tk, y el otro día recordé que existe todavía la estupenda librería Snack. Es una librería de tratamiento y generación de sonido en tiempo real.
Así que, provisto del tutorial de Snack y la documentación de Tcl/Tk pertinente, me hice un pequeño afinador (cutre: sólo da notas de referencia, no "lee" las notas del instrumento):
(Captura de pantalla en Windows)
En 65 líneas de código simple tenemos casi un programa completo:
Código (renombrar a tuner.tcl)
Lo que más atención me llama es que a cada "widget" se le puede asociar una variable (global) de tal forma que, al cambiar la variable, se actualiza el elemento convenientemente. Por ejemplo, el "message" y el "spinbox" tienen asociados dos variables, newfreq y octave, respectivamente.
Desde el procedimiento beep modificamos newfreq y el texto de la etiqueta cambia.
Ocultamiento de información y encapsulamiento: ninguno. ¿Acaso es necesario siempre? ;-)
Recursos
- Todavía hay en la red un tutorial en castellano (de lo poquito que he podido encontrar) de la Universidad de Oviedo. Data de 1998 (!) y está bastante bien. Lo bueno del mundillo Tcl/Tk es que las cosas no se quedan obsoletas tan pronto.
- Visual Tcl es un IDE para Tcl/Tk. Permite desarrollar las aplicaciones Tcl/Tk de forma "visual": pinchando y dibujando los "widgets". Funciona perfectamente y su última actualización fue en 2006.
lunes, 7 de mayo de 2007
Software musical en Linux
Soy músico aficionado (y creo que lo seguiré siendo toda mi vida). Tocaba la guitarra, me pasé al saxofón (tenor), luego al bajo eléctrico y, finalmente, al contrabajo. También intento tocar un poco la armónica, la flauta dulce y el ukelele.
Hay dos programas que utilizo a menudo para mis “tareas musicales”, Lilypond y Musical MIDI Accompaniment (MMA).
Lilypond es un programa de edición de partituras. Su utilización es muy diferente a otros programas con la misma finalidad. Las notas y otros símbolos musicales se escriben en un archivo de texto plano, y después se procesa con Lilypond este archivo. El resultado es un archivo PDF (también puede generar Postscript y ficheros MIDI) con una calidad muy buena. Muchos ejemplos musicales en estas páginas han sido elaborados con Lilypond.
Musical MIDI Accompaniment es un programa que sirve para generar ficheros MIDI con acompañamiento musical. Es una alternativa al programa comercial “Band in a Box”, de la compañia PG Music.
No existe mucha documentación en castellano sobre los programas Lilypond y Musical MIDI Accompaniment (MMA). Por ello me decidí a escribir sendos tutoriales de Lilypond y MMA. En las siguientes direcciones pueden consultarse:
Hay dos programas que utilizo a menudo para mis “tareas musicales”, Lilypond y Musical MIDI Accompaniment (MMA).
Lilypond es un programa de edición de partituras. Su utilización es muy diferente a otros programas con la misma finalidad. Las notas y otros símbolos musicales se escriben en un archivo de texto plano, y después se procesa con Lilypond este archivo. El resultado es un archivo PDF (también puede generar Postscript y ficheros MIDI) con una calidad muy buena. Muchos ejemplos musicales en estas páginas han sido elaborados con Lilypond.
Musical MIDI Accompaniment es un programa que sirve para generar ficheros MIDI con acompañamiento musical. Es una alternativa al programa comercial “Band in a Box”, de la compañia PG Music.
No existe mucha documentación en castellano sobre los programas Lilypond y Musical MIDI Accompaniment (MMA). Por ello me decidí a escribir sendos tutoriales de Lilypond y MMA. En las siguientes direcciones pueden consultarse:
- Tutorial de Lilypond en castellano.
- Tutorial de Musical MIDI Accompaniment (MMA) en castellano.
jueves, 3 de mayo de 2007
Desarrollo de temas para Wordpress
Estoy empezando a cacharrear con Wordpress, su API y la posibilidad de desarrollar temas personalizados.
Ya sé que Wordpress no es la herramienta más adecuada para utilizar como gestor de contenidos (CMS), pero es que me encanta su sencillez y facilidad de uso.
El mayor problema que me estaba encontrando era el siguiente: cuando se tienen varias categorías anidadas, al seguir el enlace de la categoría "madre", ésta mostraba todas las entradas de sus categorías "hijas", aunque ella misma no tuviese entradas. Esto está bien para un "blog", pero no era lo que yo necesitaba.
Lo que quiero es lo siguiente: al "pinchar" en el título de la categoría "madre" mostrar la descripción de la categoría o algo similar si no tiene entradas, pero no mostrar las entradas de sus "hijas".
Cacharreando un poco, ya he encontrado la manera de hacerlo. Ej. del fichero archive.php:
Estamos "dentro" del código y del
La función single_cat_title('', false) nos devuelve la categoría actual (por ejemplo, el nombre de la categoría "madre"), la función get_the_category() nos devuelve todas las categorías a las que pertenece una entrada, así que sólo hay que comparar si son la misma o no.
Nuestro archive.php queda así, más o menos:
Ya sé que Wordpress no es la herramienta más adecuada para utilizar como gestor de contenidos (CMS), pero es que me encanta su sencillez y facilidad de uso.
El mayor problema que me estaba encontrando era el siguiente: cuando se tienen varias categorías anidadas, al seguir el enlace de la categoría "madre", ésta mostraba todas las entradas de sus categorías "hijas", aunque ella misma no tuviese entradas. Esto está bien para un "blog", pero no era lo que yo necesitaba.
Lo que quiero es lo siguiente: al "pinchar" en el título de la categoría "madre" mostrar la descripción de la categoría o algo similar si no tiene entradas, pero no mostrar las entradas de sus "hijas".
Cacharreando un poco, ya he encontrado la manera de hacerlo. Ej. del fichero archive.php:
Estamos "dentro" del código y del
La función single_cat_title('', false) nos devuelve la categoría actual (por ejemplo, el nombre de la categoría "madre"), la función get_the_category() nos devuelve todas las categorías a las que pertenece una entrada, así que sólo hay que comparar si son la misma o no.
Nuestro archive.php queda así, más o menos:
<?php$categoria = get_the_category();
if (single_cat_title('', false) == $categoria[0]->cat_name) {
?>
martes, 24 de abril de 2007
Debian services control panel
Debian Services Control Panel es un pequeño programa que sirve para gestionar los servicios en una máquina que ejecute Debian (o alguna distribución derivada).
Está programado con GAMBAS.
Está programado con GAMBAS.
martes, 17 de abril de 2007
Esquinas redondeadas
A todos nos encantan las esquinas redondeadas en los diseños Web. Generalmente se hace con CSS e imágenes para componer las esquinas.
Vean el título de este artículo: la esquina superior derecha es en realidad una imagen especificada en la CSS.
Hasta donde conocía, la única forma de hacerlo era así, pero el otro día encontré un sitio donde explican cómo hacer esquinas redondeadas sólo con CSS. El truco es anidar varias etiquetas y darles diferentes márgenes y solapamientos.
Ésa es la versión básica. Para hacer más flexible el truco, se han programado una librería en JavaScript y una hoja CSS que simplifican en gran medida el uso de este "truco".
La página donde vi todo esto es ésta: Nifty Corners, de Alessandro Fulciniti.
Ejemplos:
El HTML es válido, por cierto. Tremendo lo que se puede hacer con CSS ...
Vean el título de este artículo: la esquina superior derecha es en realidad una imagen especificada en la CSS.
Hasta donde conocía, la única forma de hacerlo era así, pero el otro día encontré un sitio donde explican cómo hacer esquinas redondeadas sólo con CSS. El truco es anidar varias etiquetas y darles diferentes márgenes y solapamientos.
Ésa es la versión básica. Para hacer más flexible el truco, se han programado una librería en JavaScript y una hoja CSS que simplifican en gran medida el uso de este "truco".
La página donde vi todo esto es ésta: Nifty Corners, de Alessandro Fulciniti.
Ejemplos:
- http://www.html.it/articoli/niftycube/nifty1.html
- http://www.html.it/articoli/niftycube/nifty2.html
- http://www.html.it/articoli/niftycube/nifty3.html
- http://www.html.it/articoli/niftycube/nifty4.html
El HTML es válido, por cierto. Tremendo lo que se puede hacer con CSS ...
viernes, 13 de abril de 2007
Bases de datos con PHP y Perl
Revisando copias de seguridad me encontré con este artículo. Fue publicado en la revista DLinux de noviembre de 2000. Está totalmente obsoleto, pero puede tener algún interés arqueológico ;-)
He mantenido las erratas y la maquetación (por llamarlo de alguna manera) original.
Artículo: Accediendo a MySQL y Postgresql con PHP y Perl
He mantenido las erratas y la maquetación (por llamarlo de alguna manera) original.
Artículo: Accediendo a MySQL y Postgresql con PHP y Perl
Gambas tutorial
Gambas es una herramienta de desarrollo visual de aplicaciones muy similar a los conocidos programas comerciales Microsoft Visual Basic o Borland Delphi.El tutorial está en la siguiente página: Gambas Tutorial.
Tutorial de Django
Aviso: este tutorial se hizo en el año 2007, se mantiene esta entrada por interés "arqueológico".
En este tutorial desarrollamos una aplicación un poco más "avanzada" que la típica que se muestran en los tutoriales.
Debian services control panel
This program is a small and simple tool that manages the available "services" in a Debian.
Read more: Debian Services Control Panel
Read more: Debian Services Control Panel
jueves, 12 de abril de 2007
Informática retro
El otro día, ojeando algunas revistas viejas me encontré con estas joyas:
1977:
Anuncio de una minicomputadora HP 3000
Anuncio de un microcomputador Altair
1985:
Anuncio del IBM PC
Un AMSTRAD
Un equipo Inves
1996:
Un Acer intentado parecerse a un Mac ;-)
1977:
Anuncio de una minicomputadora HP 3000
Anuncio de un microcomputador Altair1985:
Anuncio del IBM PC
Un AMSTRAD
Un equipo Inves1996:
Un Acer intentado parecerse a un Mac ;-)
domingo, 25 de marzo de 2007
PHP orientado a objetos
Leyendo el estupendo libro PHP5 & MySQL Bible, en el capítulo dedicado a la programación orientada a objetos con PHP, me encuentro con una nota al margen muy interesante:
"Do Web-Scripting Languages Really Need OOP?"
Sinceramente, creo que a veces se abusa un poco del paradigma de orientación a objetos. Considero que es una herramienta más, pero que no siempre es la más adecuada. En el caso de PHP encuentro que utilizar clases es una forma muy cómoda y limpia de agrupar código y funcionalidades.
Vamos a hacer una pequeña prueba con PHP, a ver qué sale (nota: utilizamos PHP 5). La tarea es trivial: un "script" que pinte una tabla a partir de los parámetros pasados. No hacemos ninguna validación. Es código "guarrete", sólo para probar.
Versión procedimental, con funciones:
";
";
$t1 = microtime(TRUE);
echo "Tiempo empleado: " . ($t1 - $t0)*1000 . "";
}
pinta_tabla($_GET['x'], $_GET['y']);
?>
Versión orientada a objetos:
";
";
$t1 = microtime(TRUE);
echo "Tiempo empleado: " . ($t1 - $t0)*1000 . "";
}
}
$tabla = new Tabla($_GET['x'], $_GET['y']);
$tabla->pinta_tabla();
?>
Vemos que esencialmente, las dos versiones hacen lo mismo. Tienen el mismo número de operaciones de E/S (dos búsquedas de variables GET y seis llamadas a echo).
A priori, sin tomar tiempos, podríamos pensar que la primera versión (procedimental) debe ser un poco más rápida, ya que no crea objetos en memoria ni tiene que buscar métodos en los objetos, etc.
Vamos a probarlo en local utilizando alguna herramienta de "benchmarking" como ab (Apache Benchmark):
Utilizaremos el comando ab -n 100 -c 1 "http://localhost/tabla.php?x=10&y=10", donde:
Resultados, para -n 3000 y -c 1:
La diferencia al pintar una tabla de 10 x 10 es del 1,65%. Si la tabla a pintar es de 100 x 100, la diferencia es del 7,8%. En este último caso si que se nota más diferencia, pero no nos olvidemos que son milisegundos.
El ejemplo es muy sencillo y realmente casi todo el tiempo de ejecución se dedica a recorrer los dos bucles anidados y a "pintar" datos. Pero nos deja una cosa clara: utilizar clases para organizar o estructurar mejor nuestro código no supone mucha sobrecarga (al menos en estos casos tan sencillos).
Sería interesante repetir los resultados con diferentes versiones de PHP en diferentes S.O. Me lo pongo como deberes ...
"Do Web-Scripting Languages Really Need OOP?"
Sinceramente, creo que a veces se abusa un poco del paradigma de orientación a objetos. Considero que es una herramienta más, pero que no siempre es la más adecuada. En el caso de PHP encuentro que utilizar clases es una forma muy cómoda y limpia de agrupar código y funcionalidades.
Vamos a hacer una pequeña prueba con PHP, a ver qué sale (nota: utilizamos PHP 5). La tarea es trivial: un "script" que pinte una tabla a partir de los parámetros pasados. No hacemos ninguna validación. Es código "guarrete", sólo para probar.
Versión procedimental, con funciones:
<?php
function pinta_tabla($x, $y) {
$t0 = microtime(TRUE);
echo "
| ($i, $j) | ";
$t1 = microtime(TRUE);
echo "Tiempo empleado: " . ($t1 - $t0)*1000 . "";
}
pinta_tabla($_GET['x'], $_GET['y']);
?>
Versión orientada a objetos:
<?php
class Tabla {
var $x, $y;
function __construct($x, $y) {
$this->x = $x;
$this->y = $y;
}
function pinta_tabla() {
$t0 = microtime(TRUE);
echo "
| ($i, $j) | ";
$t1 = microtime(TRUE);
echo "Tiempo empleado: " . ($t1 - $t0)*1000 . "";
}
}
$tabla = new Tabla($_GET['x'], $_GET['y']);
$tabla->pinta_tabla();
?>
Vemos que esencialmente, las dos versiones hacen lo mismo. Tienen el mismo número de operaciones de E/S (dos búsquedas de variables GET y seis llamadas a echo).
A priori, sin tomar tiempos, podríamos pensar que la primera versión (procedimental) debe ser un poco más rápida, ya que no crea objetos en memoria ni tiene que buscar métodos en los objetos, etc.
Vamos a probarlo en local utilizando alguna herramienta de "benchmarking" como ab (Apache Benchmark):
Utilizaremos el comando ab -n 100 -c 1 "http://localhost/tabla.php?x=10&y=10", donde:
- -n es el número de peticiones
- -c es el nivel de concurrencia
Resultados, para -n 3000 y -c 1:
| Petición | Tiempo respuesta (ms) |
|---|---|
| http://localhost/tabla.php?x=10&y=10 | 2.552 |
| http://localhost/tabla-oo.php?x=10&y=10 | 2.594 |
| http://localhost/tabla.php?x=100&y=100 | 40.484 |
| http://localhost/tabla-oo.php?x=100&y=100 | 43.896 |
La diferencia al pintar una tabla de 10 x 10 es del 1,65%. Si la tabla a pintar es de 100 x 100, la diferencia es del 7,8%. En este último caso si que se nota más diferencia, pero no nos olvidemos que son milisegundos.
El ejemplo es muy sencillo y realmente casi todo el tiempo de ejecución se dedica a recorrer los dos bucles anidados y a "pintar" datos. Pero nos deja una cosa clara: utilizar clases para organizar o estructurar mejor nuestro código no supone mucha sobrecarga (al menos en estos casos tan sencillos).
Sería interesante repetir los resultados con diferentes versiones de PHP en diferentes S.O. Me lo pongo como deberes ...
Suscribirse a:
Entradas (Atom)