Archive for junio, 2008

Blueprint: CSS sencillo

Últimamente he estado probando un poco Blueprint, un proyecto de código libre alojado en Google Code. En esta entrada voy a presentar esta librería o “framework” para trabajar con CSS.

Lo primero que quiero destacar es que yo no soy diseñador ni maquetador, y por tanto voy a dar una visión bastante superficial.

Bien, ¿y para qué sirve Blueprint?. Pues Blueprint es una herramienta que divide nuestro área de diseño en una cuadrícula, lo que nos facilita el diseño y situación de los distintos elementos de nuetsra página. Realmente no es una cuadrícula porque la división es únicamente horizontal.

Existen otras herramientas similares como 960 Grid System o YUI Grids CSS.

En el caso de Blueprint, la configuración básica nos fija un ancho de 950px dividido en 24 columnas de 30px con 10px entre ellas.

Para utilizarlo basta con añadir sus archivos css en la cabecera de nuestras páginas:

	<link type="text/css" rel="stylesheet" href="css/blueprint/screen.css" />
	<link rel="stylesheet" href="css/blueprint/print.css" type="text/css" media="print">
	<!--&#91;if IE&#93;>
	<link rel="stylesheet" href="css/blueprint/ie.css" type="text/css" media="screen, projection">
	<!&#91;endif&#93;-->

Ahora, marcamos con un div class="container" la zona controlada por Blueprint. Como podemos ver en las rutas habremos situado screen.css, ie.css y print.css en css/blueprint y es conveniente poner también src/grid.png, ya que si añadimos la clase showgrid nos pone de fondo una cuadrícula muy útil en tiempo de diseño.

Y ahora empezamos a maquetar la página con la ayuda de Blueprint.

<div class="container showgrid">
	<div class="span-15">
		<p>Lorem...</p>
		<p>Proin...</p>
		<p>Nam... </p>
	</div>

	<div class="span-9 last">
		<p>Duis...</p>
		<p>Fusce...</p>
	</div>
</div>

Como vemos un poco de código tiene un resultado bastante notable. Las clases span-15 y span-9 dan la anchura a cada parte (15 + 9 = 24) y con la clase last (obligatoria) le indicamos que es el último elemento de una fila.

Existen otras posibilidades para dejar columnas libres delante (prepend-1) o detrás (append-2) y algunas más.

Para terminar un apunte. He comentado la configuración básica de Blueprint, que es la que aparece en los css comprimidos que se adjuntan. Pero si no se ajusta a nuestros gustos o necesidades, en la descarga del producto se adjunta unos scripts en Ruby que nos generan los css con una configuración que le suministramos.

Anuncios

19 junio 2008 at 8:00 pm 2 comentarios

Instalando CakePHP

En esta nueva entrada sobre CakePHP, voy a tratar sobre el tema de su instalación. Además aprovechamos que acaba de salir del horno (nunca mejor dicho) la primera candidata a estable de la versión 1.2.

Nota: Yo para esta entrada estoy utilizando una Ubuntu virtualizada sobre Virtual Box. Algunos detalles de la configuración de apache o permisos, varía según el sistema operativo utilizado. Por ello no voy a entrar en detalles. Si alguien quiere detalles extra, intentaré resolver sus dudas.

Para instalar CakePHP necesitamos tres cosas:

  • Servidor web. Lo habitual Apache (2.2.8 en el momento de escribir esta entrada).
  • PHP. Puede ser 4 ó 5. En esta entrada utilizaré la versión 5 (5.2.4-2 en particular) que es la que se recomienda actualmente.
  • Base de datos. CakePHP soporta las bases de datos más comunes, pero en esta entrada utilizaré la omnipresente MySQL (5.0.51a-3).

No necesitamos nada más, pero una herramienta para gestionar el MySQL nos vendrá bien. Yo voy a utilizar phpMyAdmin (2.11.3-1).

Antes de realizar la instalación propiamente dicha, tenemos que configurar un par de detalles en el apache:

  • Debemos asegurarnos que se puede sobrescribir las propiedades de nuestro directorio, para lo que necesitamos poner AllowOverride All.
  • Debemos habilitar el módulo rewrite de apache. No es obligatorio, pero sí recomendable.

Bien, una vez que hemos cubierto los requisitos para instalar CakePHP el siguiente paso es descargarse desde la página de CakePHP el paquete con la aplicación (cake_1.2.0.7125-rc1.zip, aunque hay otros formatos disponibles).

Descomprimimos el archivo en el directorio correspondiente al servidor web y cambiamos los permisos si es necesario. Ahora podemos lanzar nuestra primera prueba.

Las partes importantes son:

  1. Se nos pide que cambiemos la Security.salt ( sal en criptografía) para no usar la que viene por defecto. Ponemos otra cualquiera en el archivo que se nos indica y ya está.
  2. Se comprueba si el directorio tmp dentro de app tiene permisos de escritura. Es necesario, ya que en este directorio se guardan logs, caches y demás.
  3. Nos indica el mecanismo utilizado para cache de los varios que se pueden seleccionar. File está bien.
  4. Nos indica que no tenemos configurada la base de datos. Nos centramos en esta.

La solución que se nos sugiere es renombrar database.php.default en app/config a database.php. El problema es que si sólo hacemos eso, nos van a aparecer errores de conexión.

Necesitamos crear una base de datos en el MySQL y configurar a CakePHP para que la utilice.

Para lo primero utilizo phpMyAdmin. La manera más rápida y fácil es en privilegios crear un nuevo usuario con la opción de crear una base de datos con el mismo nombre y otorgar todos los privilegios.

Para lo segundo editamos el database.php visto anteriormente y damos los valores correspondientes:

class DATABASE_CONFIG {

    var $default = array(
        'driver' => 'mysql',
        'persistent' => false,
        'host' => 'localhost',
        'login' => 'tcymu',
        'password' => 'tcymu',
        'database' => 'tcymu',
        'prefix' => '',
    );

Tras hacer esto podemos volver a probar…

Bueno, parece que ya tenemos CakePHP preparado para realizar la primera aplicación, aunque eso queda para una entrada futura.

12 junio 2008 at 7:23 pm 1 comentario

OSGi: Primeros pasos (y 2)

Bien, continuamos avanzando en el camino que empezamos en la primera entrada. Para empezar, os quería comentar mi opinión respecto a OSGi, basada en este pequeño estudio que he hecho. Esta tecnología favorece el diseñar e implementar aplicaciones en forma de módulos, lo que ayuda de cara a la reutilización y encapsulación de servicios. Al igual que la inyección de dependencias favorece la buena práctica de utilizar interfaces, OSGi favorece la buena práctica de modularizar. Hecho este pequeño inciso, pasamos al punto donde lo dejamos. Crear nuestro primer módulo. El código de mi primer módulo será:

package org.tcymu.osgi;

import java.util.logging.Logger;
import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;

public class FirstBundle implements BundleActivator {
  Logger logger = Logger.getLogger(this.getClass().getName());

  public void start(BundleContext arg0) throws Exception {
    logger.info("Arrancando FirstBundle");
  }

  public void stop(BundleContext arg0) throws Exception {
    logger.info("Parando FirstBundle");
  }
}

Como vemos basta con implementar BundleActivator, con sus métodos start y stop. En nuestro caso sacamos una traza de log en cada caso. Seguidamente necesitamos crear un descriptor para el jar de nuestro primer módulo. El contenido de nuestro MANIFEST.MF es:

Manifest-Version: 1.0
Bundle-SymbolicName: org.tcymu.osgi.FirstBundle
Bundle-Version: 1.0.0
Bundle-Activator: org.tcymu.osgi.FirstBundle
Import-Package: org.osgi.framework

Le damos a nuestro módulo un nombre y una versión, le señalamos la clase activadora mediante Bundle-Activator y le indicamos los paquetes requeridos mediante Import-Package Bien, con esto ya podemos empaquetar nuestro módulo en un jar de la manera que más rabia nos dé. En mi caso lo he empaquetado mediante el export de Eclipse.

Ahora ya podemos instalar el módulo en Felix, para lo que usamos install y que nos devuelve el identificador de nuestro módulo dentro del contenedor.

Con ese identificador podemos arrancar el módulo mediante start, pararlo mediante stop o desinstalarlo mediante uninstall

.

Bien, pues ya hemos visto cómo crear un módulo. Dejaré para más adelante el crear módulos dependientes de otros módulos y otras acciones más avanzadas. Por cierto, para salir de Felix, si no lo habéis descubierto todavía, se debe ejecutar shutdown.

9 junio 2008 at 8:58 pm 3 comentarios

OSGi: Primeros pasos

Tras los anuncios de varios proyectos importantes (Eclipse, GlassFish, SpringSource Application Platform) de su paso a OSGI, parece que estas siglas están bastante de moda dentro del mundo Java. En esta entrada intento dar una visión resumida y fugaz de lo que es OSGi. Quizás la mejor definición y la más concisa es la que aparece en la cabecera de la web de OSGi: Sistema de módulos dinámicos para Java. Básicamente lo que aporta OSGi o mejor dicho OSGi Service Platform (el estándar que publica la OSGi Alliance) es un contenedor sobre el que corren distintos módulos, con sus versiones, sus paquetes exportados (utilizables por otros módulos) y sus dependencias. Existen distintas implementaciones de dicho estándar, siendo las más conocidas Equinox (de Eclipse) y Felix (de Apache). Para esta entrada voy a utilizar Felix, pero sin ninguna razón de peso para su elección. Descargamos el zip desde su sitio web y descomprimimos en el directorio de nuestra elección. Podemos encontrar una estructura bastante típica con su bin, config y doc. Para lanzarlo, necesitamos una consola situada en el directorio raíz de Felix y ejecutar java -jar bin/felix.jar.

Arranque de Felix

Lo primero que se nos pregunta es un nombre de perfil. Podemos poner cualquier cosa. Felix persiste bajo ese nombre y en nuestro directorio personal algunos datos como los módulos cargados. Esto es propio de Felix y Equinox por ejemplo no nos pedirá ningún perfil.

Si en la consola que se nos presenta introducimos help, nos mostrará un listado de los comandos disponibles, como por ejemplo ps (de qué me sonará a mí) que nos muestra el estado de los módulos en ejecución.

Ayuda y ps en Felix

Hay que destacar que tampoco esos comandos son estándares y en Equinox en lugar de ps tendremos que ejecutar ss.

De cara a implementar nuestro primer módulo, debemos conocer las características que tenemos que cumplir para que nuestro módulo pueda funcionar en Felix (o Equinox, que esto ya es parte del estándar) .

  • Tener una clase activadora. Será una clase que implemente BundleActivator (en el ejemplo veremos sus métodos que os adelanto no son demasiado complicados).
  • Definir en el MANIFEST.MF (el descriptor de un jar) algunas propiedades que serán utilizadas por nuestra plataforma OSGi para instalar el módulo.

Bueno, pues aunque pensaba incluir en esta primera entrada la realización del primer módulo, lo dejaré para una posterior (aunque pretendo que no tengáis que esperar mucho).

Actualización: Segunda parte

4 junio 2008 at 8:46 pm 1 comentario


Mi perfil

View Miguel Orbegozo's profile on LinkedIn

Feedjit

Feeds

Otros…

BlogESfera Directorio de Blogs Hispanos - Agrega tu Blog

Bitacoras.com

Add to Technorati Favorites