Funcionamiento Básico

Lo primero que hago es ir al tutorial titulado “Bazaar in five minutes” que suena muy prometedor.
la parte de instalacion dice que probablemente el programa ya está en mi distribución y que la instalación deberia ser facil. Estoy algo malcriado por debian y normalmente asumo esas dos cosas, veamos.

#  aptitude install bazaar

Presto! Bazaar instalado. Tambien hay instrucciones para MacOS X y ese otro sistema que mucha gente usa.
Luego bazaar nos pide que nos presentemos!

# bzr whoami "Lucas Caro <lucas@triplesmart.com>"

Una vez presentados, chequeamos por las dudas

# bzr whoamiLucas Caro <lucas@triplesmart.com>

Parece que esta todo bien, creemos un proyecto entonces

# mkdir -p myproject/subdirectory && cd myproject && touch test{1,2,3}.txt subdirectory/test4.txt

e inicializamos bazaar:

# bzr init

Esto nos crea un directorio .bzr con muchos archivos dentro que guardan la informacion de bazaar. Paso siguiente, agregamos todos los arvhivos a bazaar con

#bzr add

Que sin argumentos agrega todo recursivamente (muy conveniente) al repositorio. Lo unico que falta es hacer commit del repositorio, pero, ¿Dónde está guardando bazaar el repositorio, las versiones, etc? Parece que en el .bzr tenemos un directorio branch que es donde se guarda todo, y al hacer commit estamos guardando un snapshot del código (o version) tal y como está ahora. Parecido a lo tradicional, pero con Bazaar el proyecto se guarda dentro del arbol de directorios.

# bzr commit -m "Initial Import"

Guarda los cambios con el respectivo mensaje. Hasta ahora, parece ser un sistema de control de versiones que no necesita que un administrador cree un repositorio, administre usuarios, etc. veremos como se las arregla.

Cuando queremos hacer un cambio o editamos un archivo, tenemos a nuestra disposición un comando para ver las diferencias entre nuestra copia de trabajo y el repositorio

# bzr diff

nos dice estas diferencias. y siempre podemos hacer commit para unificar nuestros cambios con el repositorio.

Flujos de Trabajo

Por lo que vimos hasta ahora, bazaar sirve muy bien al desarrollador solitario, pero ¿qué pasa con los equipos que trabajan juntos en un mismo proyecto? Veamos como publicar un proyecto de bazaar:
El trabajo en equipo se basa en tener un branch principal en un servidor y publicar o descargar de este repositorio.
Bazaar nos ofrece el comando push para exportar nuestro branch a un repositorio, usando

# bzr push --create-prefix sftp://your.name@example.com/~/public_html/myproject

podemos publicar a un servidor sftp y sera creado un branch que podemos usar de principal en dicho servidor. Y cualquiera con acceso al sftp puede descargarse el branch con:

# bzr branch http://www.example.com/myproject

Hasta ahora es muy cómodo el desarrollo, mantenimiento, publicación e importación de repositorios.

# bzr merge

Nos permite actualizar nuestro branch local con los cambios del branch principal (el ultimo usado con push o branch), podemos chequear los cambios con diff y si nos parece bien, con un commit los incorporamos a nuestro repositorio local.

Para publicar los cambios al repositorio oficial, si no es nuestro proyecto, podemos usar

$ bzr send -o mycode.patch

Para obtener un archivo patch con los cambios y luego enviarlo a quien corresponda para que los incorpore. Está bien, no es un proceso muy automatizado, pero es solo una forma, en la guia de usuario podemos ver los tipos de flujo de trabajo que podemos usar con bazaar. Básicamente son:

• Solo: para el desarrollador solitario que necesita control de versiones y publica paquetes. Se tiene un control de versiones sin setup y con control de cambios muy fácil de utilizar.
• Partner: Para trabajar al estilo peer-to-peer, con dos personas que trabajan en sus copias y hacen merge de los cambios de la otra persona cuando sea necesario.
• Centralizado: Basicamente el mismo workflow que cvs o subversion, todos los desarrolladores trabajan en el mismo branch, hacen update y luego commit para guardar los cambios en el servidor.
• Centralizado con commit local: Al trabajar de forma centralizada, se puede hacer un commit –local para guardar cambios en el repositorio local y luego enviar todo el set de cambios al repositorio centralizado.
• Descentralizado con copia principal compartida: Cada desarrollador trabaja con su copia local y luego la envian a la copia principal cuando los cambios están listos.
• Descentralizado con árbitro humano: Cada desarrollador tiene su propio branch y acceso de solo lectura al repositorio principal. Cuando un desarrollador quiere publicar sus cambios, le pide autorización al árbitro, quien debe revisar el código, y luego publica los cambios en el repositorio principal.
• Descentralizado con árbitro automátizado: Como el anterior pero una vez enviado al árbitro, éste hace un merge, compila y corre el suite de test, y el código se publica en el servidor principal si y solo si pasa todos los tests. Muy bueno para proyectos grandes y para test driven development. Si los casos de test estan bien mantenidos, este workflow garantiza mayor estabilidad y robustez del código. Bazaar provee una herramienta para esto llamada Patch Queue Manager (PQM) para hacer el trabajo de árbitro automatizado.

Ya tenemos un vistazo más general de las cosas que se pueden hacer con bazaar y parece ser una herramienta muy completa y que da muchas opciones para desarrollo. Me gustó mucho lo del PQM y la automatización de tests. Además parece flexible y configurable y promete ser una herramienta muy útil y sobre todo, facil de usar y configurar y con una gran cantidad de plugins y mucho potencial.

Antes de seguir, veamos a que llamamos módulo.

Un módulo es un grupo de funcionalidades, agrupadas por alguna razón en especial. La idea es tener módulos para tareas que siempre usamos y queremos “tirar” dentro de un nuevo proyecto. Un módulo podría ser un sistema básico de usuarios, la expansión del mismo a un sistema de grupos y permisos más elaborado, una lista de email, páginas cms, etc, etc. Básicamente un paquete de funcionalidad que queremos agregar a un sitio.

Por que no usar plugins? Bueno, los módulos podrían ser plugins, ya que hasta ahora no hemos hablado de la estructura del módulo en si, podemos decir que el módulo, aparte de los archivos mencionados en el post anterior, puede contener cualquier archivo que necesite ser instalado en nuestro directorio APP. Con esto podemos tener módulos con controllers, models, views, y también con helpers, behaviors, components, vendors, imágenes, css, scripts, y casi cualquier cosa que nos imaginemos, sin el problema que representa copiar archivos de un proyecto a otro.

Teniendo en cuenta que la instalación, mantenimiento y desinstalación serán automáticas, el único problema que nos queda es que los archivos de distintos módulos no se solapen. A esto lo podemos lograr al tener ciudado y ser metódicos a la hora de crear los módulos, pero nuestro sistema también deberia avisarnos si un módulo que estemos por instalar sobreescribirá un archivo de otro módulo ya instalado, o cualquier archivo ya existente.

Resumiendo el proceso de instalación tenemos:

1. Descargar la versión requerida del repositorio (Pedir usuario, password y versión de ser necesario)
2. Chequear que el módulo sea instalable (Tenga los archivos necesarios y se cumplan las dependencias)
3. Si el módulo ya se encuentra instalado, se pregunta al usuario que curso de acción tomar.
4. Ejecutar script pre_install del módulo.
5. Guardar copias de los archivos existentes si son del mismo módulo.
6. Informar si existe un archivo que no corresponde a otra version del modulo y será reemplazado.
7. Instalar archivos nuevos.
8. Guardar en la DB de modulos los datos del nuevo módulo con estado “instalando”
9. Procesar el archivo schema.sql del módulo.
10. Ejecutar script de post_install
11. Registrar el módulo como instalado.

Esta es la linea general a seguir por el script de instalación del módulo. Aspiramos a un script que se pueda usar de la siguiente forma

module-get install|update|uninstall <module-name> [version]

Y creo que en sin querer bautizé a mi script. La idea es usar el mismo script para las tres tareas, instalar, actualizar y desinstalar un módulo. El parámetro de versión seria opcional y si no está presente, el script instalará la ultima versión del módulo especificado.

Para terminar (por ahora), cabe aclarar que las operaciones de instalar, actualizar y desinstalar deberían ser “lo más atómicas posible”, es decir que si algo nos impide seguir con la instalación, este script debería poder dejar las cosas tal y como estaban antes de que comienze a hacer cambios (tanto en archivos como en db).

Dicho sistema debe ser de fácil mantenimiento y actualización. Inspirado en el sistema de paquetes de Debian, los módulos deben tener dependencias,scripts de pre y post instalación/desinstalación, auto configuración de la base de datos, y un sistema de registro que nos diga qué módulos están instalados y cuáles no.

Usaremos una base de datos sqlite, que se integrará al sistema cake sin problemas y podremos mantener la información de todos los módulos instalados.

La primera tabla que necesitamos es modules (hare todo en inglés para mantener la consistencia con el resto del sistema) cuya estructura es (o podría ser) la siguiente:
modules(id,codename,name,version,description,status)
Con esto podemos guardar datos sobre los módulos instalados o a medio instalar.

El directorio APP/conf me parece el lugar ideal para guardar los datos de los módulos, así, tendremos todo en APP/conf/modules, un archivo sqlite (modules.sqli) y subdirectorios con el nombre de cada módulo instalado.

Dentro de cada directorio de módulo tendríamos los siguientes archivos:

• module_specs.php
• db_schema.sql
• install_scripts.php

El primero (module_specs.php) es el que indicará a nuestro script de instalación los detalles del módulo. Debe contener valores para las variables:

• $name: opcional, el nombre del módulo. El default es el nombre del directorio.
• $description: opcional, la descripción del módulo.
• $depends: un array de nombres de módulo de los que éste depende.

El archivo db_schema.sql contiene las ordenes sql para crear la(s) tabla(s) necesaria(s) para el módulo. También puede contener datos iniciales para las mismas.

Este sería el esquema básico para el sistema de módulos para cakephp (hasta ahora podría usarse independientemente del framework).
En el próximo post describiré el proceso de instalación de módulos.

Estoy usando la nueva versión (1.4.7) de esta fantástica herramienta para bloggers, y la verdad que se pasaron con los agregados. Hace no mucho les pedí que agregaran un par de facilidades para la escritura, y la verdad que los desarrolladores han sido más que receptivos a la hora de escuchar mis sugerencias, y ya tengo version nueva con todo lo que había pedido y más!

Entre las mejoras que destaco están la de poder agregar elementos HTML personalizados, muy útil para mi

código

asi como la posibilidad de agregar tags, aparte de categorías a un post en particular.

Estas dos características más la posibilidad de especificar ping urls personalizadas hacen de este release algo realmente útil, completo y cómodo para los bloggers.

Recomendado 100%.

Podés leer más en el gato de grandes botas, ele-zeta y el rallador.

Un gran salto hacia atrás en el diseño web cordobés.

En mi caso, la aplicación completa usará localización, entonces agrego al principio de app_controller.php:

uses('L10n');
class AppController extends Controller {

Luego de esto, necesitamos crear archivos para manejar el texto localizado, cake maneja esto en el directorio APP/locale. Cada lenguaje tiene un conjunto de cadenas de texto con sus repectivas claves, o id. Cada lenguaje es un subdirectorio dentro de APP/locale con el código de tres caracteres correspondiente al lenguaje (ISO 639-2, ver lista).

Cada subdirectorio de lenguaje debe contener un archivo default.po dentro del directorio LC_MESSAGES con las cadenas y sus claves. Por ejemplo, mi .po para inglés es APP/locale/eng/LC_MESSAGES/default.po

Hay que tener en cuenta que cada clave debe ser única y debe tener un valor asociado.

Los archivos .po deber tener un encoding ISO-8859-1 y los strings no pueden tener más de 1014 caracteres y deben estar formados de la siguiente manera:

msgid "clave o id del texto"
msgstr "cadena asociada en el idioma  actual."

Luego te tener esto listo, debemos indicar a cake el lenguaje a utilizar. podemos hacer esto en el controller, mi método preferido: en app_controller.php

function beforeFilter(){
        $this->L10n = new L10n();
        $languages=array('es','en');
        $paramLang=strtok($_SERVER['HTTP_HOST'],'.');
        $lang = $this->Session->check('lang') ? $this->Session->read('lang'):'en';
        if(isset($paramLang) && in_array($paramLang,$languages) ){
            $lang = $paramLang;
            $this->Session->write('lang',$lang);
        }else{
            $this->Session->write('lang',$lang);
        }
        $this->L10n->get($lang);
        Configure::write('Config.language', $lang);
    }

me permite guardar el lenguaje en sesión, y cambiarlo con subdominios. Una vez elegido el método para guardar y cambiar el lenguaje actual, las líneas

        $this->L10n->get($lang);
        Configure::write(’Config.language’, $lang);

son las que indican a cake que debe usar el lenguaje especificado para imprimir las cadenas asociadas cuando usamos __().

Lo primero que encuentro en mi recién creado proyecto, es un montón de archivos .ctp en la vista. En la nueva versión, los .thtml se llaman ahora .ctp (por cake template), pero siguen siendo archivos php y la idea debajo es la misma.

Además, en estos archivos .ctp hay llamadas a una nueva función __(), que maneja la localización y traducciones, la función se declara de la siguiente forma:

__(string $string_id, boolean $return = false)

Y nos permite imprimir el texto asociado al id para el idioma actual. Una cosa importante a notar es que si no existe el texto con el id indicado, esta función imprimirá dicho texto, asi que es buena costumbre usarla siempre para el texto que queramos mostrar en nuestra aplicación.

Por lo demás, las vistas son prácticamente iguales que en cake 1.1, archivos php para mostrar html y el contenido que nos pasa el controlador.

Cake 1.2 trae también nuevos y mejorados helpers, por ejemplo, el FormHelper tiene funciones mucho más completas (y se movió todo lo relacionado a forms a este helper) como:

• create() para abrir un form
• end() para cerrarlo
• input() para crear inputs automágicos (solo $form->input(”nombre_del_campo”) nos crea el campo de formulario correcto, un gran reemplazo para los distintos métodos de cake 1.1, que todavía podemos usar de ser necesario.

El nuevo HtmlHelper ya no tiene métodos relacionados con formularios, y esta disponible por default para todas las vistas. El mismo nos provee functiones para imprimir html bien formado, incluyendo charsets, meta, doctypes, estilos (css), imagenes, divs, links, urls, parrafos, tablas, etc.

Tambien tenemos los ya conocidos JavascriptHelper y AjaxHelper que nos ayudan a agregar efectos dinámicos a la aplicaicón, usando prototype y script.aculo.us y no han cambiado mucho.

NumberHelper, TextHelper y TimeHelper mejorados y con más funciones que nos ayudan a dar formato a sus respectivos tipos de datos siguien facilitandonos la vida en el maravilloso mundo de cakephp.

Me toca en este momento actualizar a la versión 1.2. La versión 1.1 es la versión estable desde hace tiempo, pero la nueva 1.2 es un beta que podría ser considerado “la versión oficial impuesta por el uso”. Muchos sitios están usando cake 1.2 y no es el objetivo de este post hablar de cake, sino documentar mi experiencia del paso de 1.1 a 1.2.

La versión 1.2 trae muchas características nuevas, incluyendo algunas que a veces son totalmente necesarias, como internacionalización (i18n) y localización (l10n).

Entre las más notables entonces tenemos:

• Mejoras en la validación: se agregan reglas para validación automática como alfanumérica, email (brillaba por su ausencia), url (idem), y en definitiva se provee de métodos de validación mucho más completos (por ejemplo la validación “custom” que nos permite usar expresiones regulares. La lista es gigante, y puede encontrarse aqui.
• Mejoras en el manejo de caché: cake 1.1 tiene un sistema básico de cache que es ampliado enormemente en la versión 1.2. Ahora podemos elegir entre distintos métodos de caching, e incluso cambiarlos dinámicamente.
• Soporte para temas: ahora es muy fácil asignar distintos grupos de vistas y crear temas totalmente distintos.
• Se agrega una consola cake, desde la cual ejecutamos el nuevo script bake, que está bastante mejorado.
• Se incluye una suite de testing que en estos días es un requerimiento más para el desarrollo.
• Facilidades para generación de rss y xml
• paginación: directamente en el core de cake.
• Mejoras en autenticación
• Componente email: para generar emails facilmente y desde templates.
• Mejoras en los helpers, se mueven funciónes para mejorar cohesión y se agrega funcionalidad a los helpers existentes.
• Manual! si, cake 1.2 sale con un manual completito y bastante bueno cuya versión beta está temporalmente aca

Bueno, suficiente por ahora sobre lo nuevo. instalemos cake:

Primero lo primero, yo tengo la siguiente estructura de directorios:

~/cake_1.2 : aqui va la ultima version de cake 1.2
 ~/public_html : aqui crearemos el nuevo sitio.

entonces, estando en ~/cake_1.2/cake/console tenemos el nuevo script cake que es la consola de la que hablaba antes.

cd ~/cake_1.2/cake/console

lo ejecutamos, queremos especificar que vamos a usar el comando bake, y queremos crear un sitio en ~/public_html

./cake -app ~/public_html/demosite bake

Luego nos hace preguntas sobre nuestro sitio, y en general los defaults estan bien, asi que le damos enter, enter, y ya tenemos nuestro sitio. Y si vamos al browser (con apache instalado y userdirs andando) a http://localhost/~nuestro_login/demosite deberiamos ver la bienvenida de cake. Yo lo tengo configurado como subdominio, asi que entro como demosite.localhost. Como sea que tengamos nuestro servidor de desarrollo, al ir al sitio vemos la bienvenida de cake:

Sweet, “Demosite” got Baked by CakePHP!

Si todo está bien, vemos mensajes de confirmación sobre

• el directorio tmp (Your tmp directory is writable.)
• el cache (The FileEngine is being used for caching. To change the config edit APP/config/core.php)
• la base de datos (Your database configuration file is NOT present.)

Claro que todavia no seteamos la base de datos, para esto, creamos la db y usuario con nuestra herramienta preferida, volvemos a la consola y tipeamos nuevamente:

./cake -app ~/public_html/demosite bake

Y nos pregunta sobre la base de datos (de forma más bonita que el 1.1), le ponemos
name: default,
driver: en mi caso mysql o postgres, el que usemos en el servidor de prueba.
persistent connection: lo que corresponda segun sus necesidades, yo le pongo no
database host: localhost o el servidor de bases de datos que corresponda
port: n usa el puerto default
user y password: lo que corresponda aqui.

Si todo sale bien, vemos un mensaje de confirmación y cuando refrescamos el sitio nos dice “Your database configuration file is present.” y “Cake is able to connect to the database.”

En este momento tenemos el sitio básico de cake funcionando y conectado a la db. Es muy parecido a la version 1.1 pero a mi me resultó un poco más cómodo tener el CAKE_CORE_PATH bien configurado por bake

Con esto terminamos la instalación básica de cakephp 1.2 que no es mucho más que hacerlo con la 1.1 y ya podemos empezar a crear nuestro sitio.

Como conclusión, no es muy distinto de instalar cake 1.1 solo que el nuevo bake es más inteligente.