fav.or.it Lector de feeds

fav.or.it feed reader lector de feeds

Gracias a la web del Zend Framework, llego hasta este interesante proyecto de un lector de feeds al estilo Google Reader, realizado con el Framework de Zend y con un alto uso de AJAX (principalmente prototype).

Las capturas de pantalla y los videos tienen muy buena pinta y ya me he apuntado para ser de los primeros en probarlo.

Cuando parece que ya está hecho todo en un determinado tema, siempre hay gente capaz de innovar y mejorar lo existente. Y eso también saben verlo los inversores.

Cache en WordPress usando el Zend Framework

Zend Framework
Desde hace tiempo, este blog está superando los 1000 visitantes diarios y las 2300 páginas vistas. Eso empieza a plantearme algunos problemas, sobre todo teniendo en cuenta la cantidad de recursos que consume el wordpress y que a mí me gusta mucho optimizar el rendimiento del servidor.

Es por eso que he estado buscando alguna forma de añadir cache de páginas al blog. Las opciones que he encontrado han sido:

Pero ninguno de los dos me ha convencido. Lo que yo busco es algo que sea muy eficiente pero a la vez muy simple. Ni siquiera necesito interfaz de administración.

Y es ahí cuando me he dado cuenta de lo evidente… Tanto tiempo usando el Zend Framework y su cache de páginas y no se me había ocurrido aplicarlo al wordpress :P

La instalación es muy sencilla, simplemente he bajado el Zend Framework y he copiado la carpeta “library” a mi directorio raíz de wordpress. Después he creado una carpeta donde irán las páginas cacheadas (en mi caso ha sido: wp-content/cache) que debe tener permiso de escritura (0777).

Y ahora viene lo importante. Hemos de modificar el index.php de wordpress para añadir el código que nos permite usar la cache. Este es ahora mi index.php:


<?php
set_include_path ('library' . PATH_SEPARATOR . get_include_path ());

require_once ‘Zend/Cache.php’;

$frontendOptions = array(
‘lifetime’ => 3600*6,
‘debug_header’ => false, // for debugging
‘default_options’ => array(
‘cache_with_session_variables’ => true,
‘cache_with_cookie_variables’ => true
),
‘regexps’ => array(
‘^/$’ => array(‘cache’ => false),
‘^/2007/’ => array(‘cache’ => true),
‘^/category/’ => array(‘cache’ => true),
‘^/2008/’ => array(‘cache’ => true)
)
);
$backendOptions = array(
/* cache_dir debe ser una ruta absoluta por temas del ob_start */
‘cache_dir’ => dirname($_SERVER[‘SCRIPT_FILENAME’]) . ‘/wp-content/cache/’
);

// getting a Zend_Cache_Frontend_Page object
$cache = Zend_Cache::factory(‘Page’, ‘File’, $frontendOptions, $backendOptions);
$cache->start();

/* Short and sweet */
define(‘WP_USE_THEMES’, true);
require(‘./wp-blog-header.php’);
?>

Podeis encontrar documentación sobre el sistema de cache del Zend Framework aquí. Pero básicamente lo que hago es cachear todos los posts y los listados de las categorías durante 6 horas (3600 segundos * 6). De esta forma, durante esas 6 horas, si se accede a alguno de los posts del blog o a alguna categoría, se tomará la copia de cache y se evitará el pasar por todo el codigo de wordpress, incluida la conexión a la base de datos.

Lo malo de esta solución es que cuando vuelva a actualizar wordpress, tendré que acordarme de no pisar el index.php.

Magento e-commerce, el sustituto de oscommerce

Magento e-commerce

Desde hace ya bastantes años, en el terreno del comercio electrónico y las tiendas online, hay un vencedor indiscutible: oscommerce. Durante todo este tiempo ha sido la alternativa más usada para la creación de las tiendas virtuales de pequeños y grandes negocios.

Aunque han aparecido otras alternativas, no han logrado hacerle sombra.

De la mano de los chicos de Varien y basada en el Zend Framework aparece ahora un sistema de última generación al que han llamado Magento.

Magento viene de serie con interesantes características:

  • Flexibilidad sin limitaciones
  • Arquitectura escalable
  • Soporte de la comunidad y soporte de pago.
  • Integración sencilla con aplicaciones de terceros.
  • Funcionalidades de última generación (URLs amigables para buscadores, Ajax y javascript para la interfaz, tags para los productos, comentarios de los consumidores, sistema de valoración de los productos, wishlist, etc.).

Es posible ver una tienda de demostración y varios videos explicativos.

Aunque todavía está en fase de pruebas, Magento ya parece ser una seria alternativa al omnipresente oscommerce. Sin duda su aspecto gráfico es mucho más profesional y detalles como el alta rápida de clientes (nada que ver con el tocho-formulario de oscommerce), la modularidad de su código y la integración de facilidades Javascript y web 2.0 (p.ej. la nube de tags) en su interfaz la convierten en un serio rival.

Yo de momento ya me la he descargado y estoy echándole un vistazo a su código que tiene muy buena pinta.

El Zend Framework y el diseñador híbrido

Hoy me he encontrado con este interesante artículo en la Zend Developer Zone, donde se comenta la necesidad creciente de ser un poco “híbrido” a la hora de desarrollar en la web. Por una parte tener buenos conocimientos de programación y por la otra buen gusto y cuidado de la estética cara al usuario. Todo ello, aplicado a la metodología de trabajo del Zend Framework. La única pega es que está en inglés.

Zend Framework 1.0, por fin

Como muchos esperábamos, hoy se ha liberado la versión 1.0 del Zend Framework.

Durante todo este tiempo de desarrollo, el sistema MVC ha ido cambiando para finalizar siendo flexible, robusto y muy sencillo de usar.
Son buenas noticias para todos los que usamos este Framework y si tú aún no lo has probado, es un buen momento para considerarlo. Te aseguro que no te defraudará.

actualización: me había adelantado al anuncio oficial :)

Liberado el Zend Framework 1.0.0 RC1

Zend Framework¡Ya queda menos para la 1.0! Para todos lo que usamos a diario este framework estamos de enhorabuena, porque sin duda con cada release gana en calidad, estabilidad y rendimiento (se han corregido más de 90 problemas desde la 0.9.3).

Estas son algunas de las novedades en esta entrega:

  • Zend_Controller tiene una nueva funcionalidad llamada ViewRenderer, que facilita el diseño de las acciones en los controllers. Para entenderlo mejor, leeros este artículo.
  • Zend_Gdata cambia su formato por uno más orientado a objetos.
  • Zend_Db gana en consistencia en su interfaz.
  • Zend_Filter_Input aparece como una nueva clase (aunque con un nombre antiguo). Se usará para declarar reglas para filtrar y validar grupos de datos. Será como una caja negra de la cual sólo saldrán los datos que pasen los filtros establecidos.
  • Zend_Service_StrikeIron es un nuevo cliente de web service que entra en la incubadora.

¡Corre! ¡Descárgalo!

Manejando el error 404 con el Zend Framework

Zend FrameworkTras adoptar la plataforma de desarrollo de Zend al programar tus aplicaciones, una de las primeras dudas que surgen es cómo manejar el caso de las páginas no encontradas con esta filosofía. En principio el Framework deja total libertad al programador y únicamente muestra un error o excepción “Invalid controller specified” . Tras la adición del sistema de plugins, esta se convierte en una de las formas más fáciles de controlar este tipo de errores. Por ejemplo:

class Mi_Controller_Plugin_NoRoute
   extends Zend_Controller_Plugin_Abstract
{
   function preDispatch(Zend_Controller_Request_Abstract $request)
   {
       $frontController = Zend_Controller_Front::getInstance();
       $dispatcher = $frontController->getDispatcher();

       if (!$dispatcher->isDispatchable($request))
       {
           $request->setControllerName('index');
           $request->setActionName('noroute');
       }
   }
}

De esta forma (propuesta por Rob Allen), lo que hacemos es redirigir todos los errores 404 al controlador “Index” y a la acción “noroute”. Así podemos manejarlos en un único lugar para toda la aplicación.

Otra de las alternativas propuestas (en mi opinión menos elegante) es la siguiente:

try {
	$front->dispatch();
} catch (Exception $e) {
	require_once dirname(__FILE__) . '/../application/Core/controllers/IndexController.php';
	$controller = new IndexController($front->getRequest(), $front->getResponse());
	if ($e instanceof Zend_Controller_Dispatcher_Exception) {
		$controller->error404Action();
	} else {
		throw $e;
	}
	$response = $front->getResponse();
	/* @var $response Zend_Controller_Response_Abstract */
	echo $response->__toString();
}

En esta ocasión, lo que hacemos es capturar la excepción del tipo Zend_Controller_Dispatcher_Exception que es lanzada cuando no se encuentra el controlador o la acción especificadas en la url.

Personalmente prefiero la primera opción, ya que me parece mucho más versatil y elegante y puede usarse para manejar otro tipo de errores parecidos. De hecho es la que uso en mis proyectos (aunque con algunas modificaciones). Pero sólo es una preferencia personal, ya que la segunda opción también permite capturar distintos tipos de excepciones y dispone de las mismas posibilidades.

Mientras más proyectos hago basados en este Framework, más me gusta la potencia y sobre todo la versatilidad y libertad que te ofrece. Pero lo que más me gusta es que programar en php ha dejado de ser monótono y ahora vuelve a ser muuy divertido ;)