« Octubre 2005 | Inicio | Diciembre 2005 »

Noviembre 30, 2005

Desarrollo con Ruby on Rails en Mac OSX (IV): Comenzando el desarrollo

Pues ya sólo falta probar la instalación por completo generando el modelo para la aplicación e intentando conectar a la misma. Lo primero será, por tanto, generar el modelo.

GenerarModelo.jpg

Como puede verse en la siguiente imagen, la estructura del proyecto es clara y bien organizada. Cada cosa está en su sitio.

UbicacionModelo.jpg

El siguiente paso, es generar el controlador:

GenerarControlador.jpg

Para tener una aplicación mínimamente funcional, en la que están implementadas ya las cuatro operaciones básicas (alta, baja, modificación y consulta) tan sólo hay que editar el controlador de mi aplicación, regalo_controller.rb, y añadir una línea:

scaffold.jpg

¡Y ya está!. Alta, baja, modificación y consulta, en dos minutos. Sobre decir que ahora es cuando debe comenzar el trabajo de verdad, pero ya tenemos un prototipo visible, a los pocos minutos de comenzar el desarrollo. ¿Somos ágiles o no?.

Para comenzar a introducir registros, hay que atacar la url http://localhost/test/regalo/new, y comenzar a toquetear:

primerListado.jpg

Resumiendo: he instalado Rails (media hora más o menos), he instalado MySQL (un poco más largo, por los problemas con las herramientas de administración, pero en total ha sido una hora), he compilado el binding para MySQL (varias horas de google y unos minutos de resolución) y he realizado la primera iteración del desarrollo propiamente dicho (¡cinco minutos!).

Ahora empieza lo bueno...

Desarrollo con Ruby on Rails en Mac OSX (III): MySQL y Rails

Este paso ha sido el de resolución más corta, pero el de investigación previa a la solución más larga. Dicho de otra forma, horas de google, para encontrar una solución que se tarda un minuto en aplicar.

Por ahora, he instalado Ruby on Rails y MySQL en el ordenador, y he creado la base de datos con la tabla que voy a necesitar.

Ahora tengo que configurar la aplicación RoR para que utilice MySQL. Para ello, hay que editar el fichero correspondiente: /Users/ctarda/RoR/TestBlog/config/database.yml

DBConfig.jpg

Ahora viene la parte complicada. Si yo generase (como así hice) el modelo de aplicación en este momento, e intentase ejecutarla, obtendría un error ya que tal y como está todo, Rails no es capaz de conectar con la base de datos. ¿Por qué?. Porque no hay ningún binding para MySQL instalado.

Para instalar el binding, tendría que cambiar a la carpeta /usr/lib/ruby/gems/1.8/gems/mysql-2.7 y compilarlo (sudo make; sudo makeinstall). El problema es que no compila, y devuelve un error "can't find ruby headers".

Tras horas, repito, horas de google, encontré este post en el que explican brevemente que mi problema puede venir por la combinación Mac OSX 10.4.3 y XCode 2.2. La solución pasa por vincular las cabeceras del Ruby universal a las del ruby para powerpc. Sí, para mí también es chino. Y siento no poder ser más conciso en este punto, pero para mí tanto el problema como la solución al mismo están bordeando el mundo de la "magia".

El caso es que una vez aplicado ese parche ( cd /usr/lib/ruby/1.8/powerpc-darwin8.0;
sudo ln -s ../universal-darwin8.0/*), ya sí he podido compilar el binding de MySQL.

Ahora ya puedo comenzar el desarrollo en sí. Pero en el siguiente post.

Desarrollo con Ruby on Rails en Mac OSX (II): MySQL

La instalación de MySQL debería haber sido un paso más de la preparación del entorno, sin mayor importancia en teoría, pero al final ha sido la única parte verdaderamente dolorosa del proceso. En realidad, no ha sido la instalación en sí, sino la puesta en marcha de la base de datos y su integración con el RoR.

Continuamos con la instalación del entorno de desarrollo en el punto en el que nos quedamos en el post anterior.

El primer paso será descargar el instalador de MySQL, y ejecutarlo.

InstaladorMySQL.jpg

Si se quisiera que la base de datos se arrancara automáticamente al arrancar el sistema, habría que ejecutar también el instalador de MySQL Startup Item, que se incluye en el paquete.

Como indica la documentación, para que la instalación se pueda realizar, es necesario que exista en el sistema un usuario que se llame mysql, usuario que parece ser ya existe a partir de la versión 10.4.2 de Mac OSX, por lo que en mi caso, no ha sido necesario crearlo.

Una vez instalada la base de datos, habrá que arrancarla:

ArrancaMySQL.jpg

Si se quisiera parar:

ParaMySQL.jpg

A partir de este punto supongo que todo lo que voy a contar hay que tomarlo con precaución. Me explico. Las herramientas propias de MySQL para administrar la base de datos, como MySQL Administrator no han funcionado nada bien. Tampoco CocoaMySQL. Utilizando el administrador he podido crear usuarios de la base de datos, pero no tablas, y utilizando CocoaMySQL sólo he podido conectarme a la base de datos con el usuario anónimo. Doy por hecho que los problemas vienen por algún error en el proceso que voy a describir. Si alguien lo ve claro, por favor, que deje un comentario explicando cómo se debería hacer correctamente.

Bien, retomamos el proceso tras la instalación y el arranque de la base de datos. El primer paso va a ser crear el usuario root de MySQL:

Creando_root.jpg

Tras varios intentos, he conseguido arrancar MySQLAdministrator y conectar a la base de datos como root. Momento que voy a aprovechar para crear un usuario para los proyectos RoR (el usuario será ruby, y el password rails, impresionante despliegue de originalidad):

MySQL AdministratorScreenSnapz001.jpg

A continuación, creo el esquema para mi proyecto, que he llamado wishlist. Y creo la tabla para los datos, tabla que he llamado regalos. No he sido capaz de crear la tabla utilizando ninguna de las herramientas para administrar MySQL, por lo que después de muchos intentos, he terminado por ir a la solución rápida pero segura: logarme "a mano" en mysql desde el terminal (como el usuario rails), y crear la tabla haciendo un CREATE TABLE.

Para que la aplicación RoR pueda acceder sin problemas a los datos de la tabla, ésta debe tener una clave primaria (ojo, es importante hacerla AUTO_INCREMENT). La estructura de la tabla será:

descripTabla.jpg

Es importante fijarse en el nombre de la tabla: regalos. En el próximo post veremos el porqué de la importancia de ese nombre. Pero antes de eso, tendremos que configurar Rails para que pueda conectar con la base de datos MySQL. Y eso sí que ha sido un grano en el culo...

Noviembre 28, 2005

Desarrollo con Ruby on Rails en Mac OSX (I): El entorno

No sé muy bien cuánto hay de moda en Rails. Se habla mucho de lo rápido que puede ser el desarrollo utilizando este framework, de lo buena que es su implementación del modelo-vista-controlador, de lo sencillo que es el lenguaje... demasiadas cosas como para no probarlo.

Por eso, he decidido desarrollar una aplicación sencilla escrita en Ruby on Rails. La aplicación me va a permitir administrar mi lista de regalos para navidad. No la lista de los regalos que yo voy a hacer, sino de los que quiero que me hagan (así que, quien corresponda, que vaya tomando nota...). El desarrollo, no podría ser de otra manera, va a ser iterativo, de forma que comenzaré por hacer lo mínimo imprescindible para poder dar visibilidad, y a partir de ahí pretendo ir enriqueciendo la aplicación con todo lo que necesitará tener: autentificación de usuarios, AJAX (pensé que nunca escribiría ese palabro en este blog), regalos asignados a miembros de una lista de "regaladores" que también sea administrable... El paquete completo, por decirlo de alguna forma.

Pero lo primero que hace falta es un entorno de desarrollo. En este caso, la máquina en la que va a estar corriendo el servidor va a ser mi adorado Mac Mini (1.42 GHz y 512 MB RAM; Mac OSX 10.4.3). El servidor web a utilizar pretendo que sea el Apache que está instalado en el sistema, en vez del servidor propio de Rails, porque por una parte me siento cómodo configurando el Apache, y por otro lado no he leído cosas muy buenas de WEBrick (que así se llama). Además, el ordenador tiene instaladas las XCode Developer Tools (versión 2.2), requisito indispensable para que el "tinglado" funcione (y posteriormente, un grano en el culo a la hora de hacer el binding con la base de datos, como se verá).

Comenzamos. Abróchense los cinturones, y todas esas cosas.

Lo primero que hay que hacer es descargar algún paquete con Ruby on Rails, como por ejemplo este paquete, realizado por Tony Arnold. Por cierto, el procedimiento de instalación es muy similar al explicado en este post del propio Tony Arnold.

Una vez descargado el paquete, hay que proceder a instalarlo:

InstaladorScreenSnapz001.jpg

Posteriormente, hay que actualizar las gems:

TerminalScreenSnapz001.jpg

Hay que tener en cuenta que el usuario con el que se está logado normalmente no tiene permisos suficientes para actualizar las gems. De ahí el tener que hacer un cambio temporal de usuario al root (sudo), que pedirá la contraseña de dicho usuario.

El proceso de actualización de las gemas es sencillo aunque el feedback del mismo puede considerarse más bien escaso. Como para muchas otras cosas, vigilar el uso de CPU suele dar más pistas sobre lo que está pasando que el propio feedback del proceso. Por cierto, hay que aceptar todas peticiones que se hacen durante el proceso de actualización. Calculo que, en mi caso, la actualización se realizó en unos 5-6 minutos.

Bien, una vez actualizadas las gemas, creamos una aplicación de prueba (no tan de prueba en este caso, ya que es sobre la que voy a realizar el desarrollo). Si todo se genera sin problemas, se podrá suponer que vamos por el buen camino:

TerminalTest.jpg

Como se puede ver en la imagen, creo una carpeta llamada RoR en el raiz de mi usuario, y posteriormente, tras cambiar a esa carpeta, genero una aplicación llamada TestBlog (mal nombre, lo sé, pero ya no tiene remedio). Una vez concluya la generación de archivos (son bastantes) se podría arrancar el servidor "incorporado" de la siguiente forma:

TerminalServer.jpg

Cosa que yo no voy a hacer, ya que, como ya he dicho con anterioridad, pretendo que el servidor a utilizar sea el Apache que incorpora el sistema. Pero antes de configurar Apache para que mi aplicación Rails funcione correctamente, hay que dar los permisos necesarios a la misma.

El problema es que Apache es un proceso propiedad del usuario www, pertenenciente al grupo www, por tanto tendré que asignar los archivos de mi aplicación a ese grupo. Igualmente, tendré que asignar permisos de escritura a los logs:

TerminalPermisos.jpg

Esto empieza a ir por buen camino. Ahora hay que configurar Apache. Lo primero que habrá que hacer es añadir el módulo fast_cgi al archivo de configuración (/etc/http/httpd.conf):

FastCGIScreenSnapz001.jpg

También hay que incluir los Aliases de la aplicación (en la sección <IfModule mod_alias.c>):

TextMateAliases.jpg

Ahora, hay que editar el fichero .htaccess de la carpeta donde esté instalada la aplicación Rails (en mi caso /Users/ctarda/RoR/TestBlog). La línea:

TextMateReWrite1.jpg

debe cambiar a (nótese el cambio de cgi a fast cgi)

TextMateReWrite2.jpg

Además, hay que añadir estas líneas:

TextReWrite3.jpg

Ya estamos terminando. Sólo falta arrancar Apache:

ArrancandoApache.jpg

y atacar la aplicación generada:

Congratulations.jpg

Si has llegado hasta este punto, enhorabuena (por aguantar despierto sobre todo). Ya has configurado Apache como servidor para tus aplicaciones Ruby on Rails. Pero por ahora no hemos creado más que el esqueleto de una aplicación que, obviamente, no hace nada de nada.

Para poder seguir avanzando, tendremos que instalar una base de datos, y comenzar a desarrollar nuestra aplicación. La base de datos que he elegido ha sido MySQL (porque es la que está instalada en el servidor de "producción" que voy a utilizar). Y con esa elección es donde han comenzado los problemas, problemas que veremos en el siguiente post, pero que se resumen con la siguiente frase: el paquete que he instalado no incluye un binding para MySQL, binding que no puedo instalar por un fallo en la configuración de las XCode Tools 2.2.

Pero eso lo veremos en el siguiente post.

Noviembre 26, 2005

CÛmo escribir cÛdigo imposible de mantener...

...y asegurarse un trabajo de por vida. Un link de hace bastante tiempo, que habÌa perdido, y que acabo de reencontrar:

How to write unmaintenable code

Noviembre 23, 2005

[Cocoa] Manejo de memoria y excepciones

Objective-C, como cualquier programador iniciado en el mismo sabe, es un lenguaje que, a diferencia de java o actionscript, no tiene recolector de basura, no maneja la memoria por sí mismo, sino que es responsabilidad del programador el liberar los recursos que haya utilizado con anterioridad.

El manejo de memoria no es especialmente complicado, aunque sí requiere atención y un toque de rigurosidad por parte del programador. Eso no evita, que haya situaciones en las que sea fácil producir leaks de memoria, al no preveer alguna situación especial en el programa, como por ejemplo, al lanzar una excepción.

Bien, pues sirvan los dos párrafos anteriores como introducción a este post de Chris Hanson titulado Cocoa memory management & exceptions

Noviembre 17, 2005

A lo mejor hay que hacerlo así

Igual hay que olvidarse del Pragmatic Programmer. A lo mejor, este post de ESTRATEgA no está muy desencaminado.

Tal vez lo mejor, efectivamente, sea tener una estrategia de distanciamiento total con respecto a la empresa en la que se trabaja, no sólo el "desenchufar" cuando se sale y se va uno a su casa, sino llevarlo un poco más allá. Y no sólo con la empresa, sino con la propia capacidad de aprendizaje y crecimiento personal.

Una parte de mí dice que no, pero basta con mirar alrededor para ver que como mínimo, hay que planteárselo.

Las dos opciones son casi igual de tentadoras: por un lado, intentar mantener cierto nivel de ética laboral, de implicación con lo que se hace, y por otro, intentar sobrevivir de la forma más cómoda posible. A mí, personalmente, siempre me ha parecido que la única opción era la primera, la de intentar hacer las cosas lo mejor posible, pero ¿no será un esfuerzo en vano?. Es fácil caer en el desánimo en determinadas circunstancias, por lo que la segunda opción siempre va a ser también muy tentadora.

Sin embargo, la diferencia existe, y aunque a corto plazo no lo parezca, a medio y largo plazo la única opción viable es la de intentar acercarse en lo posible al Pragmatic Programmer. ¿Por qué?. Por dos motivos:

  • El mantenimiento. ¿Qué es mejor, tener un proyecto boomerang, de esos que siempre están volviendo con bugs, con código escrito a desgana y sin una calidad mínima, o hacer algo lo más sólido posible, pese a que el entorno y las circunstancias de contorno sean desfavorables, y cuyo mantenimiento y nivel de errores sea lo más bajo que se pueda?.

  • La satisfacción de hacer algo bien. Momento corto, siempre condicionado con un sinfín de "peros", y que en realidad se produce en contadas ocasiones, pero que merece la pena intentar repetir.

Parece claro, ¿o no?. ¿Alguien se quiere mojar?.

EDITADO:
En Navegapolis tocan otro aspecto del mismo tema. O a lo mejor no es del mismo tema, pero merece la pena leer ese post de todas formas.

Noviembre 16, 2005

Activando apache y php en Mac OSX

Mac OSX incorpora "de serie" tanto una instalación de Apache, como una versión un poco pasada de php, la 4.3.11.

El caso es que, más o menos actualizado, php está incluído en la instalación del sistema, por lo que en determinadas circunstancias, y para salir de un apuro (como es mi caso hoy), puede venir bastante bien.

El archivo de configuración de Apache por defecto tiene comentados tanto la carga del módulo php, como la extensión de los archivos php. Por tanto, vamos a ver cómo editarlo desde el terminal.

En primer lugar, hay que abrir una sesión del terminal (la aplicación se encuentra en /Aplicaciones/Utilidades/Terminal. Una vez abierta, hay que ir a la carpeta en la que se encuentra instalado Apache:

cd /etc/httpd

A continuación, hay que editar el archivo httpd.conf, pero hay que tener en cuenta que el propietario de dicho archivo es el usuario root del sistema, por lo que para poder editarlo (cambiando los cambios, claro), habrá que hacerlo de la siguiente forma:

sudo pico httpd.conf

Lo que preparará la edición del archivo http.conf con el editor de archivos pico. Pico pedirá la introducción de la contraseña del root, contraseña que, una vez introducida, permitirá modificar y guardar los contenidos de ese archivo.

Ahora, hay que buscar (Ctrl+W) la línea:

#LoadModule php4_module libexec/httpd/libphp4.so

Y eliminar de la misma la almohadilla, que es el carácter que indica que esa línea es un comentario

A continuación habrá que hacer la misma operación con la siguiente línea:

#AddModule mod_php4.c

Hay que eliminar la almohadilla. A continuación, hay que indicarle a Apache que la extensión php es válida. Eso se hace añadiendo dicha extensión a la siguiente sección del archivo:

<IfModule mod_dir.c>

DirectoryIndex index.html

</IfModule>

Modificándola de la siguiente forma:

<IfModule mod_dir.c>

DirectoryIndex index.html index.htm index.php

</IfModule>

Ahora ya sólo falta cerrar y guardar el archivo (Ctrl+O para guardar, y Ctrl+X para salir), y arrancar Apache, lo que se puede hacer desde el panel de preferencias del sistema, en la sección de "Compartir" (activando "compartir web" ), o directamente en el terminal:

sudo apachectl start

Posteriormente, para detener Apache basta con introducir la siguiente orden:

sudo apachectl stop

O, para reiniciarlo:

sudo apachectl restart

¿El resultado?. Si se coloca un archivo con extensión php y una llamada a phpinfo( ) en la carpeta web de mi usuario, se obtiene lo siguiente:

phpInfo.jpg

Gran parte del proceso viene mucho mejor explicado aquí, aunque utilizando BBEdit. Ni la mitad de geek que utilizando el terminal

Noviembre 03, 2005

Ya en su quiosco

Sí, design-nation sale al quiosco. En el número de noviembre de MacWorld España, aparece publicado un artículo escrito por éste su seguro servidor. Se trata de el Primer Contacto con el Macromedia Studio 8.

Pese a ese artículo, la revista, como siempre, está llena de contenidos interesantes, como una revisión de los servicios .Mac, un informe sobre qué Mac o que iPod elegir (aunque eso es fácil: todos) o un artículo sobre cómo evitar los problemas con iMove HD.

Lo dicho, en el MacWorld de Noviembre.

Noviembre 01, 2005

Poster de patrones de diseño

A estas alturas seguro que has oído hablar (como mínimo) de la serie Head First, en concreto de Head First Design Patterns que probablemente sea la mejor introducción para entender los patrones de diseño.

La semana pasada, cuando estaba buscando otras cosas en amazon, me encontré con esto: Head First Design Patterns Poster.

designPatternsPoster.jpg

Como su propio nombre indica, es un poster (bastante grande, por cierto) que contiene los gráficos (extraídos del libro), no los diagramas UML de los patrones, sino los gráficos de los ejemplos del libro, así como el número de la página en la que aparece ese patrón tanto en el Gang of Four como en el Head First Design Patterns.

Resume de forma visual 18 patrones, y ahora mismo luce enfrente de mis ojos clavado en la pared...

(Por cierto, ninguno de los enlaces es patrocinado, y por tanto NO me llevo comisión).