|

Drake: ejecuta aplicaciones CakePHP en Drupal

drake.pngDrake es un módulo de Drupal que nos permite ejecutar aplicaciones realizadas con CakePHP, se trata de un puente entre ambos.
Drupal es uno de los mejores CMS en PHP, pero que dispone de un pequeño framework, mientras que CakePHP es uno de los mejores frameworks de PHP pero que no dispone de gran funcionalidad como CMS. Por ello nace Drake, que se encarga de unirlos para conseguir desarrollar mejores aplicaciones.
Drake solo admite Drupal 5 debido a que sería costoso dar soporte a versiones de Drupal 4 y Drupal 5, ya que el API de Drupal 5 es bastante diferente al de la versión 4. La instalación parece muy sencilla, por lo que no creo que presente muchas dificultades su uso.
Drake
Vía / PHPDeveloper.org

SiteVista: testing de tus páginas en navegadores

sitevista.pngSiteVista es un servicio de pago que nos permite enviar una url y ver cómo se muestra en diversos navegadores, resoluciones de colores y tamaños de ventana.
Entre los navegadores admitidos se encuentran Internet Explorer (versiones 6, 5.5, 5 (Win y Mac) y 4), Netscape Navigator (versiones 8, 7, 6 y 4), Firefox, Mozilla y Safari. Las resoluciones que admite son 640×480, 800×600 y 1024×768 y los colores 256, high color y true color.
La velocidad de respuesta no está mal del todo, a parte de que te muestren estadísticas sobre uso de navegadores que te pueden ayudar a decidir si das soporte a un navegador o no.
Entre las características que ofreceran en un futuro, encontramos cosas que no he visto en otros sitios parecidos a este, como videos que muestran la carga con limitación de ancho de banda, como se verían las páginas por personas con problemas de visión y mp3s que reproducen lo devuelto por screen readers.
A parte tienen un sistema parecido al de las páginas web, que comprueban cómo quedan los correos en diferentes clientes (Google Mail, Hotmail, MS Outlook, …)
SiteVista
Vía / BitSignals

links for 2007-03-20

|

Microsoft pagará a empresas por usar su buscador

live2.pngMicrosoft pretende probar un programa por el cual se pagará a las empresas para que usen su buscador web Live.
A cambio de que se use su buscador, Microsoft ofrece créditos para servicios o training. Lo que pretende conseguir es que a cambio de estos créditos, los usuarios envien comentarios de valor sobre el uso del buscador web.
Incialmente ofrecerá una cantidad fija de 25.000$ a la empresa y entre 2$ y 10$ por cada computadora anualmente, dependiendo esta última cantidad de la cantidad de búsquedas que realice. Así, por ejemplo una empresa con 10.000 ordenadores y desde la que se hagan muchas búsquedas, podrá ganar unos 120.000$, y una empresa con 50.000 ordenadores y un nivel de búsquedas normal, podrá ganar unos 200.000$.
Estoy de acuerdo con opiniones sobre lo absurdo de esta medida, porque aunque yo ya he visto que los administradores te añaden en el IE una barra de búsquedas, no quita que la gente pueda usar el Firefox, o que instale la de Google, o cualquier otra cosa que evite lo que Microsoft y la empresa pretenden.
Microsoft: Use our search and we’ll pay you

Consejos para diseñar una base de datos

Diseñar una base de datos no es algo sencillo y sí muy importante, ya que un mal diseño conlleva dificultades para desarrollar la aplicación o una aplicación compleja. Unos consejos que realmente son muy necesarios y muchas veces no se llevan a cabo.

  • Mal diseño: el diseño es lo fundamental, primero hay que saber qué es lo que se necesita mostrar para luego diseñar correctamente la base de datos. Yo personalmente me he encontrado con diseños iniciales muy básicos que luego han ido parcheando y haciendo modificaciones drásticas para ajustarlas a un modelo que era el mismo desde el inicio de la aplicación.
  • Ignorar la normalización: la normalización es fundamental para un buen rendimiento y una sencilla programación.
  • Nomenclatura no estándar: los nombres deben significar algo para que sea sencillo de comprender a simple vista. A parte, la nomenclatura debe ser constante en todo el diseño.
  • Falta de documentación: esto es una constante en todo el mundo de la programación, y en las bases de datos no va a ser menos. Que tu sepas que significa una tabla o un campo, no quiere decir que otra persona que entre en el proyecto vaya a saberlo con la misma facilidad que tú.
  • Una tabla que agrupa a muchas: un error normal es pensar que un diseño con muchas tablas es más complejo, y que es mejor meterlo todo en una única tabla.
  • Usar un identificador como única clave primaria: no siempre es correcto usar únicamente un identificador numérico secuencial como clave primaria única.
  • No usar las características de SQL para proteger la integridad de los datos: hay que tener en cuenta las reglas de campos nulos, tamaños de los campos y claves secundarias en el diseño para obtener una mejor integridad de datos.
  • No usar procedimientos almacenados para obtener los datos: es una forma de separar la capa de la base de datos de la capa del usuario. Aportan seguridad, encapsulamiento, mantenibilidad y rapidez. Yo también añadiría el uso de vistas.
  • Falta de pruebas: algo para mí muy importante es hacer pruebas de estres, para saber si la base de datos va a aguantar el volumen de datos que necesitará la aplicación. Comprobar el tiempo de ejecución de las sentencias para añadir índices, etc…

Podéis ver todos estos puntos muy bien explicados y de forma extensa en el artículo original.

Ten Common Database Design Mistakes

links for 2007-03-17

Agiliza Google Analytics en tu página

Es cierto que a veces la carga del script de Google Analytics retrasa el carga completa de la página. La gente de AskApache, que suelen sorprenderme con sus entradas, nos ofrecen un truco para mejorar la velocidad de carga del script urchin.js.

Este script, que se carga del sitio de Google Analytics, a veces tarda en cargarse, por lo que una solución para agilizar esta carga es ponerlo en nuestro servidor y acceder en local.

Claro, que el problema es que este script se suele modificar con cierta frecuencia, por lo que deberíamos tener la última versión en cada momento.

Crearemos una shell que borre el script de local, obtenga de nuevo el script alojado en Google Analytics y lo guarde en la ruta de local. A parte crearemos un job para el cron que ejecute este script cada 12 horas.

#!/bin/sh
rm /home/user/websites/askapache.com/z/j/urchin.js
cd /home/user/websites/askapache.com/z/j/
wget http://www.google-analytics.com/urchin.js
chmod 644 /home/user/websites/askapache.com/z/j/urchin.js
cd ${OLDPWD}
exit 0;

La línea para el cron:

11 12 * * * /home/user/websites/1day.sh >/dev/null 2>&1

Faster Google Analytics with a local urchin.js

links for 2007-03-16

|

Jaws: otro CMS en PHP

jaws.pngJaws es un CMS en PHP con el cual podremos crear nuestros propios sitios web.
Su interfaz es muy amigable, con un diseño limpio e iconos muy web 2.0, por lo que parece que su administración, por lo poco he visto en la demo, no representa mucha complicación.
jaws-control-panel.png
Dentro de Jaws podemos distinguir en gadgets, que son módulos que añaden funcionalidades a nuestra aplicación, y plugins, que modifican el texto de los gadgets.
Entre los gadgets oficiales tenemos uno para gestionar la inclusión de banners, blogs, chat, FAQ, navegador de ficheros, glosario, menu, organizador de fotografías y varios más. Además existen otros dos componentes que nos ayudarán en nuestros desarrollos: Wiki para la creación de XHTML válido mediante clases de PHP y Omni para la gestión de sesiones.
Un nuevo CMS a tener en cuenta, esperemos que la comunidad de desarrolladores la enriquezcan al igual que pasa con Drupal, WordPress u otros.
Jaws