Archive for category Programación Web
Ruby on Rails – Layouts y Hojas de Estilo
Posted by Xavi in Programación Web on 12/09/2011
Casi todas las aplicaciones web tiene una característica en común (y nótese que he dicho CASI TODAS, no todas) y es que la mayoría de sus páginas responde a un mismo modelo. Esta similitud entre páginas de la misma aplicación no ha pasado por alto a los responsables de desarrollo de frameworks y, actualmente, buena parte de éstos ya incorporan diferentes herramientas que nos ayudan a lidiar con la repetición de código HTML que estas similitudes comportan.
El nombre escogido bajo el cual se gestionas la repetición de componentes y estructuras entre páginas de una misma aplicación es “layouts”
Layouts
Ruby on Rails (o RoR, un acrónimo que es posible que use de aquí en adelante) tiene un sistema de gestión de layouts muy sencillo que se aprende en un periquete. Evidentemente, detrás de este sistema básico se esconde la posibilidad de profundizar en la funcionalidad y realizar tantas piruetas como se quiera con la gestión de los layouts de nuestra aplicación.
Durante la generación de la aplicación, de hecho, ya tenemos una primera pista de por dónde van a ir los tiros pues dentro de la carpeta app/views podemos encontrar un subdirectorio llamado layouts.
Con un poco de experiencia en el desarrollo web (y más concretamente en Java 
) el primer impulso que uno podría tener sería el de pensar: “Oye, seguro que en el controlador puedo definir que layout quiero utilizar asignando el nombre del fichero a una variable o llamando a un método”. Sería lo normal… es a lo que nos han estado acostubrando desde pequeños… pues esta vez no nos hará falta; si no se quiere profundizar mucho en el tema, RoR nos permite utilizar un layout simplemente creando un fichero HTML con pedazos de Ruby embebido que se llame como el controlador que lo va a usar.
Por ejemplo, si tenemos un controlador llamado CondemorController (el archivo se llamará condemor_controller.rb) simplemente con tener un archivo, con las características que comentábamos en el párrafo anterior, llamado condemor.html.erb en la carpeta de layouts éste último será usado por el controlador para generar la página web de respuesta.
A todo esto, los primeros de la clase ya estarán pensado: “pues que co*azo de sistema, mi aplicación utiliza el mismo layout para todos los controladores”. Los que hayáis pensado esto, (podéis mandarme 50 euros y) os perdonaré, básicamente porqué yo mismo lo pensé cuando empezaba a trastear on RoR, pero esta gente se ha adelantado, se ha adelantado y permite que definamos un layout por defecto. En caso de no encontrar un archivo de layout que corresponda al controlador que está preparando la respuesta, se utiliza el layout por defecto de la aplicación para mostrar la respuesta al usuario.
Si lo pensamos bien, este método nos ofrece una gran variedad de combinaciones sin que esto conlleve un aumento en la complejidad de nuestra solución. Por un momento pensad la flexibilidad de este mecanismo para la creación de landing pages personalizadas o simplemente la creación de páginas especiales (como manuales o foros de ayuda) que no siempre necesitan ceñirse a la misma estructura que el resto de la aplicación. Es muy potente y muy simple, y la simplicidad a la hora de gestionar este tipo de estructuras nos puede ayudar mucho a aumentar nuestra productividad.
Hojas de estilos
Una herramienta básica en el uso de los layouts son las hojas de estilo. Las hojas de estilo (CSS) nos aportan una gran flexibilidad a la hora de definir el estilo gráfico de nuestras páginas web y bien aplicadas pueden hacer magia 
En RoR, las aplicaciones tienen un directorio llamado public dónde se deberían almacenar todos sus contenidos estáticos (CSSs, JSs, imágenes y otro tipo de contenido estático). En un primer momento podríamos pensar que, simplemente sabiendo como vamos a desplegar la aplicación, tendríamos suficiente en poner un path relativo en la etiqueta HTML para cargar los archivos CSS y listos; pero, imaginaros que el despliegue de la aplicación acaba siendo en un servidor con unos configuración un tanto peculiar, o que esperábamos que el domino apuntase a la carpeta public y de golpe apunta a la raíz de la aplicación (esto no debería pasar nunca… ehemmm). Para solucionar los problemas que podrían ocasionar situaciones como la anterior tenemos una función que nos permitirá cargar una hoja CSS sin tenernos que preocupar por la ubicación final de los ficheros de la aplicación. Esta función se llama stylesheet_link_tag y a continuación os escribo un pequeño ejemplo de como podría utiilzarse en un archivo de layout:
...
<head>
<title>Aplicación con estilo</title>
<%= stylesheet_link_tag “style”, :media => “screen” %>
</head>
<body>
...
NOTA: El archivo que se carga con esta función es style.css y se encuentra en la carpeta public de la aplicación.
En el ejemplo podemos ver como el uso de la función no representa un gran esfuerzo en comparación con los quebraderos de cabeza que puede ahorrarnos. Dadle una oportunidad.
Y con esto terminamos una entrega más de este pequeño paseo por Ruby on Rails!
Me estoy divirtiendo mucho con este mini-proyecto y espero estar en situación de anunciaros la disponibilidad del software dentro de poco; ahora mismo tengo que acabar de añadir las cabeceras de la licencia y avanzar un poco más en el desarrollo, bueno, bastante más para poder ofrecer algo funcional, para que engañarnos
Seguid atentos!
Ruby on Rails – Controladores y Vistas
Posted by Xavi in Programación Web on 07/09/2011
Ruby on Rails es un framework para el desarrollo web que implementa el patrón Modelo-Vista-Controlador orientado a la web (en según que documentación también puede ser que lo encontréis como patrón MVC tipo 2). Esto quiere decir que hay una separación efectiva entre el componente que recibe y gestiona las peticiones realizadas desde el navegador (controlador), el componente que se encarga de construir la interfaz que se presentara al usuario (vista) y la capa que gestiona el comportamiento del núcleo de la aplicación (modelo).
A continuación vamos a explicar los controladores y como generarlos automáticamente…
Controladores
Tal y como comentábamos, los controladores son los encargados de recibir las peticiones de los usuarios y disparar las acciones para poder devolver la respuesta a los usuarios. Estos controladores se implementan mediante clases en la carpeta app/controllers y necesitan implementar unos métodos que se encargarán de ejecutar lo que llamaremos “acciones”.
Para saber que controlador y que método del controlador tiene que llamar, Rails (por defecto) divide las URL de la manera que vamos a explicar a continuación:
Dada la URL: http://servidor/controlador/acción
Si Rails se está ejecutando en el servidor “servidor”, éste llamará al método “acción“ de la clase ControladorController (en el archivo controlador_controller.rb).
Del párrafo anterior podemos deducir que la creación de controladores implica la creación de archivos con nombres concretos. Para evitar problemas con los nombres de los archivos y facilitar la vida a los desarrolladores, la generación de estos componentes está automatizada en el framework que estamos estudiando. Como aun no tenemos ni un sólo controlador (si arráncaramos el servidor web ahora mismo sólo veríamos la página por defecto que incluye Rails en su servidor web) vamos a crear uno desde cero.
Para generar el controlador nos situamos en la raíz del proyecto y ejecutamos el siguiente comando:
script/generate controller index index
La nomenclatura de los controladores y las acciones es libre, pero en este ejemplo vamos a utilizar el controlador IndexController y la acción index para definir la acción que responderá a las peticiones que se realicen a la raíz de nuestra aplicación (veremos como definir que controlador y que acción llamar en las peticiones a la raíz de la aplicación al final de este artículo). La razón por la cual utilizo estos nombres es porqué son los que se utilizan por defecto en el Zend Framework y la implementación del patrón MVC del ZF y Rails son, bajo mi punto de vista, muy parecidas.
La salida de la consola cuando ejecutemos la operación anterior debería ser la siguiente:
En la captura de pantalla anterior podemos observar como a parte del fichero index_controller.rb también se han creado ficheros para tests, helpers y vistas.
Pero, qué son las vistas? les hechamos un vistazo en un momento. Dejadme que muestre el contenido de nuestro controlador y vamos en seguida
El contenido del fichero del controlador es el siguiente:
class IndexController < ApplicationController
def index
end
end
El código, evidentemente está vacio (el dia que salga un framework que escriba el código de lo que el desarrollador está pensado habremos llegado DEMASIADO lejos 
) pero podemos ver como IndexController hereda de una clase llamada ApplicationController (propia de Rails) y que el método index ya está también definido.
Ahora que nos hemos cercionado de que nuestro controlador no está haciendo nada, vamos a mirar que secretos nos esconden las vistas…
Vistas
Las vistas, básicamente son ficheros *.erb (Embedded Ruby) que contienen su parte estática en HTML y su parte dinámica en código Ruby. Como bien os podéis imaginar, el resultado de la ejecución de sus partes dinámicas determina la página web que se mostrará al usuario en respuesta a su petición. Para personalizar el pequeño test que estamos realizando vamos a modificar el contenido que el generador automático haya guardado en el fichero index.html.erb por el siguiente contenido:
<h1>Index Controller</h1>
<p>Hello World! That's just an static view</p>
Para ver los efectos de este cambio podemos situarnos otra vez en la raíz de nuestro proyecto y ejecutar el comando para ejecutar el servidor de desarrollo que Rails nos proporciona por defecto.
script/server start
Una vez arrancado el servidor, al visitar la página http://localhost:3000/index/index deberíais poder ver una imagen parecida a la siguiente:
One more thing…
Como en el anterior artículo nos quedamos un poco cortos vamos a tirar un poquito más del carro y vamos a ver muy poquito de lo que Rails ofrece de forma automática. Para ello vamos a tener que definir una variable de clase en el controlador, por ejemplo, en el método index (el único que tenemos hasta ahora) y lo vamos a dejar de la siguiente manera:
def index
@variable = "dynamic";
end
Y el contenido de la vista lo vamos modificar para que quede así:
<h1>Index Controller</h1>
<p>Hello World! That's just a <%=@variable%> view</p>
Si no hemos parado el servidor, simplemente recargando la página que hemos consultado antes vamos a ver el resultado de los cambios:
El hecho de que la vista pueda acceder a las variables de las instancias de los controladores es algo que Rails nos provee de forma completamente transparente para los desarrolladores. Este ejemplo puede saber a poco a muchos de los que estéis acostumbrados a la programación y es que, realmente, esto es sólo una minúscula parte de la punta del iceberg de todas las cosas que Rails ha ido automatizando en el proceso de desarrollo de una aplicación web.
A parte de esta simple modificación para hacer la vista un poco más dinámica también os avanzo como hacer que el controlador “index” y su acción “index” se utilicen para responder las peticiones que se hacen a la raíz del sistema. Esto, implica un cambio en la configuración del comportamiento de la aplicación en si misma y, por lo tanto, vamos a tener que editar el fichero config/routes.rb.
El cambio necesario para que la aplicación se comporte como decíamos implica encontrar la línea de código que pone:
# map.root :controller => "welcome"
Y sustituirla por la siguiente:
map.root :controller => "index", :action => “index”
Sin reiniciar el servidor, visitando http://localhost:3000/ veremos que el resultado de la acción “index” de nuestro IndexController ya se muestra cuando visitamos la raíz del servidor.
Bueno, esto ha sido todo por hoy, en el horizonte tenemos templates, scaffolds y mucho más, no faltéis!
Guía rápida de GIT – Parte II
Posted by Xavi in Linux, Programación Web on 05/09/2011
Siguiendo con la introducción a GIT que se publicó hace unos días, hoy vamos a ver como realizar unas cuantas operaciones más.
Si en la primera parte de esta guía introductoria vimos como configurar nuestro usuario, crear un repositorio y enviar nuestras modificaciones a un repositorio remoto en esta vamos a ver cómo descargar todo el contenido de un repositorio remoto, actualizar la copia local y cómo realizar branches y tags.
Manos a la obra!
Trabajando con un repositorio remoto
Los sistemas de control de versiones centralizados, como Subversion, tienen en su diseño una gran vocación de trabajar en red y así poder organizar el trabajo en equipo. Justamente por la facilidad a la hora de poner en marcha un repositorio a través de la red, a veces se abusa de estos sistemas y se decide (erroneamente) utilizar este tipo de sistemas para la gestión documental de los proyectos.
GIT provee, al igual que Subversion, una gestión de la descarga inicial y actualización desde repositorios remotos, pero al ofrecer un abanico más amplio de posibilidades es necesario aprender un grupo de comandos adicional. Siguiendo la comparación en paralelao con Subversion, podríamos empezar la revisión de estas funcionalidades de GIT con el equivalente a la operación checkout del hermano “centralizado”.
Cuando queremos descargar todo el contenido de un repositorio GIT, hace falta disponer del método de acceso (recordemos que generalmente se utiliza el protocolo HTTP o conexiones seguras como SSH pero puede haber otros métodos) y ejecutar el comando clone
git clone http://usuari@servidor/repositorio.git
Este comando nos va a generar una copia con lo que en ese momento podamos encontrar en el repositorio alojado en el servidor remoto y debemos tener en cuenta que puede tardar unos minutos.
Si, por el contrario, ya tenemos una copia de un proyecto y queremos actualizar sus contenidos el comando que deberemos usar es el siguiente:
git pull
En este comando podemos observar que, aunque GIT nos obligue a realizar ciertas operaciones de forma explícita (que en otros sistemas de control de versiones quizá son prescindibles), a veces tiene implementadas pequeñas funcionalidades que nos facilitan la vida cuando tenemos que lidiar con él (como en este caso, que recuerda el servidor remoto del que se descargó el repositorio).
Tags
El significado que puede tener la palabra “tag” en un sistema de control de versiones es muy diferente del que puede tener en nuestras redes sociales preferidas . El concepto de tag, utilizado desde hace tiempo en los sistemas de control de versiones, sirve para marcar un estado concreto del desarrollo que nos interese marcar para facilitar el acceso al mismo. Estos estados normalmente se asocian a hitos de proyectos o a versiones estables que se quieren poner a disposición de los compañeros de desarrollo o público en general.
La creación de tags en Subversión es un proceso prácticamente manual. Para definir uno de estos estados “destacados” se copia todo el código del repositorio en una carpeta destinada a albergar ese tag y se deja ahí hasta el fin de los días. GIT gestiona de forma mucho más eficiente este tipo de operaciones y nos permite definir un tag simplemente con unla ejecución de un comando -y sin una copia masiva de ficheros-.
git tag nombretag
git push --tags
Estrictamente la creación del tag únicamente requiere la ejecución del primer comando, pero nosotros hemos añadido un segundo comando para enviar el tag al servidor remoto. Hemos añadido este comando porqué este es el funcionamiento habitual de los tags, pero es verdad que usuarios más habituados al uso de sistemas de control de versiones pueden ver en los tags “locales” una oportunidad de mejorar la gestión del desarrollo a nivel personal.
Branches
El uso que principalmente se da a los branches es el de separar el desarrollo de componentes o funcionalidades de la rama principal del proyecto. Para esto se crea un branch, se desarrolla el componente o funcionalidad correspondiente y posteriormente se juntan las modificaciones del branch con el código en la rama principal. Esta última operación normalmente implica la correción de conflictos surgidos de la evolución del software en paralelo y puede tomar más tiempo de lo esperado.
Siguiendo con la comparación que estamos haciendo con Subversion, encontraremos que con GIT es mucho más sencillo generar branches que los que resultaba hacerlo con SVN. Las diferencias són muy parecidas a las que nos hemos encontrado en el caso de los tags, mientras que en Subversion es necesario copiar todo el código a un directorio destinado a ese branch, en GIT podemos generar uno en el acto y cambiar nuestro árbol de ficheros al nuevo branch en cuestión de segundos.
Vamos a ver un ejemplo de la creación de un branch en GIT:
git branch nombrebranch
git checkout nombrebranch
Igual que con los tags, el único comando obligatorio es el primero. Pero, hay que tener en cuenta que la creación del branch, en GIT, no implica un cambio del actual árbol de directorios al nuevo branch, simplemente lo crea. Para realizar ese cambio tenemos el comando checkout (no confundir con la operación checkout de SVN!).
Hasta aquí ningún problema, los branches son fáciles de crear y GIT permite estar trabajando en uno nuevo en cuestión de segundos pero… que fácil seria la vida del desarrollador si no tuviesemos que hacer nunca la operación maldita, EL MERGE.
La operación merge (enemiga natural de los equipos de desarrolladores ) consiste en traspasar los cambios de un branch a otro. Habitualmente esto se hace para enviar los canvios realizados para implementar un nuevo componente a la rama principal y para realizar esta tarea (de forma automática) ejecutamos el comando siguiente:
git merge nombrebranch
NOTA: Para realizar esta operación con este número de parámetros, debemos estar trabajando en un branch diferente a “nombrebranch”. Si no es así, hay otras formas de llamar el comando merge pero requieren un poco más de conocimiento de GIT.
Si no existen conflictos entre un branch y otro (yes! I had a dream… A dream where two branches do not have to conflict with each other!! ) la operación merge habría acabado aquí; pero en el caso de existir (9 de cada 10 desarrolladores se encuentran conflictos cuando hacen un merge, el restante simplemente no ha desarrollado nada), GIT nos marcaría los archivos con conflictos y seríamos nosotros los encargados de editar esos archivos, añadir los cambios al repositorio y confirmarlos.
Añadir los cambios al repositorio y, posteriormente, confirmarlos requiere la ejecución de un par de comandos que ya vimos anteriormente pero que no está de más recordarlos:
git add fichero-con-conflictos-resueltos
git commit -m “he resuelto los conflictos”
Bueno, y hasta aquí hemos llegado. Pensad que el 90% o más de las funcionalidades que se usan de los sistemas de controles de versiones han sido explicadas con más o menos detalle en esta guía básica repartida en dos partes. Y como creo que he cumplido con el título de la guía (Guía básica), vamos a cerrar aquí esta introducción a GIT. En caso de describir funcionalidades más avanzadas os las comunicaré bajo otros títulos más acordes al nivel de las explicaciones .
Espero que esta guía os sirva y controlad (vuestras versiones!)
Primeros pasos con Ruby y Rails
Posted by Xavi in Programación Web on 03/09/2011
Hace años la programación web tenía mucho más que ver con la artesanía que con la programación. Cualquier pequeño desarrollo requería un número de lineas de código que nunca nadie más volvería a utilizar (y seguramente comprender). Pues bien, para facilitar la vida a los desarrolladores, empezaron a llegar lenguajes de programación más ágiles para el desarrollo web como PHP y, posteriormente, frameworks que nos facilitaban aun más la vida al traer un gran número de funcionalidades ya implementadas (como en el caso de Zend Framework para PHP o GWT para Java).
De entre todos estas tecnologías de (relativa) reciente aparición, un minoritario lenguaje de programación, Ruby, se encontró por sorpresa con un ligero pero eficiente framework para el desarrollo web (cosas que pasan en la vida ), Rails. Y de este binomio surgió una herramienta que considero que pude ser clave en los próximos años.
Por el interés que me ha suscitado tanto Ruby como Rails, intentaré presentar las operaciones más básicas de este framework junto con el lenguaje de programación que lo hace posible -en un número aun indeterinado de artículos-. El resultado de éstos estarà disponible como software libre en un repositorio público que aun está por decidir (pero que muy probablemente será GitHub).
Empezamos?
Antes de empezar a explicar como meternos en Ruby y Rails podría soltar un rollo teórico de unos cuantos párrafos (que si Ruby es un lenguaje completamente orientado a objeto, que si Rails es un framework que implementa el patrón MVC, que si no hace falta relanzar el servidor para probar cambios, etc, etc.) pero prefiero ir comentando este tipo de cosas a medida que vayamos avanzando. Desde mi punto de vista es un poco más ameno y da menos miedo.
Instalando Ruby y Rails
Para empezar a desarrollar en Rails es necesario tener instaladas las librerías de Ruby. Para eso deberemos instalar los siguientes paquetes en Linux:
- ruby (o ruby1.8): Paquete básico que contiene el core de Ruby.
- rubygems: Nos permitirá utilizar el comando gems más adelante, básico para desarrollar en Rails.
- libopenssl-ruby: Dependencias necesarias para el uso de según que algoritmos de encriptación.
- ruby1.8-dev: Cabeceras de Ruby.
- libsqlite3-dev: Sistema ligero y flexible de bases de datos que nos ayudará en el desarrollo en local de nuestra aplicación en Rails. Realmente este paquete no sería necesario pero lo vamos a utilizar.
NOTA: Antes de empezar a discutir sobre versiones voy a dar una explicación sobre el uso de la versiones en este proyecto. He decidido utilizar la rama de Ruby 1.8 y Rails 2.2 porqué son las versiones estables en el momento en que empecé con esto. En cuanto esté un poco más familiarizado ya me animaré a escribir sobre las mejoras que Rails 3.1 o Ruby 1.9 nos pueden aportar.
Para instalar estos paquetes en Ubuntu podemos utilizar apt-get o aptitude indistintamente pero tened en cuenta que para otras distribuciones de Linux el nombre de estos paquetes puede variar sustancialmente. Una vez hayamos instalado estos paquetes vamos a utilizar el comando gems -igual en todas las plataformas-.
Con las dependencias instaladas, vamos a proceder a instalar Rails utilizando el propio gestor de paquetes de Ruby: Gems. Este gestor nos permite instalar diferentes librerías y frameworks de Ruby en nuestro equipo sin tener que sufrir por las diferencias entre plataformas. Así, utilizando este gestor podemos ejecutar el siguiente comando directamente en la consola para instalar Rails:
sudo gem install rails --version 2.2.3
Si hemos tenido éxito con todas estas operaciones ya nos podemos empezar a crear nuestra aplicación.
Crear un nuevo proyecto
El fucionamiento de Rails en cuanto a la creación del proyecto y sus diferentes componentes es bastante parecido al de las herramientas por línea de comando de Zend Framework (os había comentado ya que soy bastante fan del ZF?). De este modo, para crear una nueva aplicación en Rails sólo tenemos situarnos en el directorio dónde vayamos a guardar este proyecto y ejecutar el siguiente comando:
rails webapp
Esto nos generará un arbol completo de nuestra nueva aplicación. Explorad su contenido minuciosamente y cuando no entedáis nada volved para el siguiente artículo
Bueno… como creo que os dejo con demasiado por hacer os pongo un pequeño resumen de lo que podéis encontrar en el árbol de directorios del proyecto, que no soy tan malo!
Primero los directorios:
- app: Básicamente es el directorio dónde vamos a desarrollar la aplicación, dentro de esta carpeta podemos encontrar las clases correspondientes a modelos, controladores, scripts relacionados con las vistas y todo tipo de archivos relacionados con la aplicación a desarrollar.
- config: En este directorio se encuentran los archivos dónde vamos a definir a que base de datos nos conectamos, en que entorno nos encontramos (sí, Rails nos permite definir diferentes entornos como “ddevelopment”, “testing” y “production” para facilitarnos la vida) o que routing van a seguir las peticiones HTTP que reciba la aplicación.
- db: En este directorio vamos a ver el schema de la base de datos que definamos a medida que desarrollemos la aplicación y otros archivos que nos ayudarán con el mantenimiento de la misma (si tienes curiosidad sobre esto último busca información sobre “migrations” en la documentación de Rails).
- doc: Directorio dónde vamos a generar la documentación de nuestra aplicaciónm (esa documentación que todos los desarrolladores amamos generar!).
- lib: Módulos y librerías externas que podamos necesitar al largo del desarrollo.
- log: Pues eso, el directorio dónde seguramente van a ir a parar los logs de nuestra apliación (por lo menos en desarrollo).
- public: Si has trabajado alguna vez con ZF, este directorio actual exactamente igual en Rails que en el framework de PHP. Básicamente se encarga de almacenar los recursos que tienen que ser accesibles por el servidor web (css, imágenes, js adicionales…).
- script: Contiene los scripts que se encargan de arrancar el servidor de pruebas y puede almacenar otros scripts útiles para la gestión de la aplicación (despliegue u otras operaciones importantes).
- test: Todos los tests de la aplicación (unitarios y de otros tipos que ya veremos) van a ir almacenados en esta carpeta.
- tmp: Archivos temporales. Si tu aplicación genera “basurilla” no persistente puedes almacenarla ahí.
- vendor: Directorio para el almacenamiento del código de Ruby, Rails y gemas que utilices en tu proyecto.
Y los dos archivos generados:
- Rakefile: Equivalente del Makefile pero para Ruby.
- README: Un fichero de readme es un fichero de readme, no le daremos más vueltas pero la lectura de su contenido inicial está muy recomendada.
Hoy pretendía empezar a tocar algo de código pero el post estaba empezando a crecer mucho así que espero veros por aquí en unos días.
Cheers and Rubies!!
Guía rápida de GIT (a.k.a. GIT for dummies)
Posted by Xavi in Programación Web on 30/08/2011
Hay tecnologías que se meten en tu vida, que no las quieres pero se meten en tus estudios, tu trabajo y no hay más remedio de lidiar con ellas con el mejor humor posible; en cambio, hay otras que se te cruzan por delante y te apetece incorporarlas a tu dia a dia desde el momento en que te enteras de su existencia.
Para mi, GIT pertenece a este segundo tipo de tecnologías. Hacía tiempo que tenía ganas de meterme a fondo en este sistema de control de versiones, así que he aprovechado mis primeros pasos en un lenguaje de programación nuevo para escribir esta pequeña guía (me la he escrito para mi pero espero que también os guste a vosotros ).
Instalación
Para instalar las herramientas básicas de GIT en Ubuntu (probado en 11.04) sólo hace falta ejecutar el siguiente comando en el terminal.
sudo apt-get install git-core git-gui git-doc
En principio no vamos a utilizar la interfaz gráfica pero el paquete no ocupa mucho (y no estaba convencido que no tuviese que recurrir a ella durante los primeros días).
Configuración de usuario
A nivel de identificación de usuarios GIT no es diferente a otros sistemas de control de versiones. Éste require el envío del usuario que realiza según que acciones para poder implementar un control de acceso fiable (dependiendo del repositorio). Para proporcionar estos datos a todas las operaciones que realicemos desde un mismo equipo podemos ejecutar los siguientes comandos:
git config --global user.name "Nombre Apellidos"
git config --global user.email "alias@dominio.com"
La alternativa a esto es mandar el autor en cada operación con un parámetro extra peeero… no lo recomiendo, es mucho más cómodo esto y como tenemos cuidado de no ir revelando la contraseña de nuestro usuario (verdad? ) no vamos a tener problemas.
Creación del repositorio y primer “commit”
GIT, al ser un sistema de control de versiones distribuído, nos permite trabajar sin la necesidad de estar conectados a un servidor que alberga un repositorio central. De esta manera lo primero que debemos hacer es crear un repositorio en nuestra máquina (más tarde ya nos encargaremos de sincronizarlo con un servidor expuesto a Internet).
Para crear un repositorio en nuestra máquina bastará con la ejecución del siguiente comando. La primera vez recomiendo que esta operación se realice en un directorio vacío para controlar 100% como funciona, cuando hayamos adquirido más experiencia ya nos atreveremos a saltarnos pasos
git init
Hasta aquí fácil, verdad? Pues vamos a empezar a usar el control de versiones y sincronizarnos con un repositorio remoto.
Versiones en local y sincronización con servidor remoto
Una vez en marcha el repositorio local, crearemos un archivo en el directorio (para el ejemplo vamos a usar “file” como nombre del archivo) y haremos un commit local en nuestra máquina (no se envían a un servidor remoto de forma automática):
git add file
git commit -m "Nuestro primer commit"
NOTA: se sobreentiende que el fichero “file” lo tenéis que crear antes de ejecutar estos comandos.
Una vez creada la primera revisión vamos a sincronizarlo con un servidor remoto. Para realizar esta operación primero tenemos que decirle a GIT dónde encontrar este repositorio y que nombre vamos a utilizar para referirnos a él:
git remote add central usuario@servidor:path/repositorio.git
Antes de seguir vamos a analizar brevemente el comando. “git remote add” es el nombre entero del comando puesto que lo que queremos es añadir la dirección de un repositorio remoto a nuestro entorno de desarrollo, “central” es el alias que vamos a utilizar para referirnos al repositorio remoto y “usuario@servidor:path/repositorio.git” es el método que vamos a utilizar para acceder al repositorio (debemos tener en cuentra que los repositorios GIT son directorios como cualquier otro y que debemos utilizar sistemas como SSH o HTTP para acceder a ellos).
Cuando ya hemos definido como vamos a acceder y referirnos a él, ya podemos intentar sincronizar nuestras modificacione en local con el servidor remoto. Para eso mandaremos todos los cambios de nuestra rama a la rama del repositorio “central”.
git push -u central master
Igual que hemos hecho antes, vamos a analizar este comando por partes. “git push -u” básicamente lo que hace es enviar todos los cambios de una rama hacía otra y “central master” lo único que define es el destino y el orígen de los cambios que queremos enviar.
Cabe destacar que la rama principal que se crea al ejecutar “git init” se llama master. Este nombre se puede cambiar en el momento de la creación de repositorio pero es un valor por defecto que por lo que he podido observar se respeta bastante dentro de la comunidad de usuarios de GIT.
Y… esto es todo por hoy! Espero seguir ampliando esta breve explicación sobre GIT en los siguientes artículos pero no prometo nada. El trabajo, los estudios y otras ocupaciones se podrían entrometer
Espero que os haya sido de ayuda!!
Módulos para Drupal 7 – El navegador de archivos
Posted by Xavi in Programación Web on 27/02/2011
Un componente básico para blogs y CMS para el público general es un gestor para subir, modificar y eliminar archivos (habitualmente imágenes). En Drupal no existe un gestor de archivos por defecto, así que también debemos recurrir a la instalación de módulos independientes. En este post vamos a ver el módulo IMCE:
El módulo IMCE permite gestionar archivos desde una interfaz bastante intuitiva (bastante… para la gente habituada al entorno web-servidor) con sólo instalarlo. Vamos a ver alguna de sus características:
Como podemos ver en la captura anterior, la interfaz nos permite subir archivos, generar miniaturas, eliminar archivos y redminesionar imágenes. La última opción que podemos ver en la imagen (Insert file) se trata de la posibilidad de insertar la imagen en un editor de texto WYSIWYG (en el caso de que el archivo que hayamos escogido se trate de una imagen).
Quizás una de las características que más se hecha de menos es la de crear directorios o subdirectorios a través de la interfaz gráfica. Se puede navegar por una jerarquía de directorios en el caso que hayan sido creados con anterioridad, pero no se pueden crear desde este módulo.
La segunda captura nos muestra un ejemplo del diálogo de subida de una imagen al servidor. He considerado que esta captura era una buena manera para introducir una de las funcionalidades más interesantes del módulo IMCE, el redimensionado de imágenes. IMCE nos provee una interfaz sencilla para la creación de miniaturas y redimensionado de imágenes (sobreescribiendo la actual o creando una copia).
En el apartado de configuración de IMCE podemos definir el tamaño predeterminado para la generación de miniaturas para así adaptarlas a la estructura de nuestro site:
Y si necesitamos una resolución para una ocasión especial, podemos recurrir a la opción redimensionar sin tener que modificar la configuración general del módulo para un caso concreto :
Como podéis ver, IMCE nos provee un conjunto reducido pero muy potente de herramientas para la gestión de nuestros archivos y, sobretodo, de nuestras imágenes.
La integración con CKEditor es un poco rebuscada porqué el diálogo para insertar imágenes de CKEditor no se integra con IMCE pero se puede abrir desde un botón y la opción “Insert File” devuelve la ruta de la imágen seleccionada al diálogo. En la siguiente captura podemos ver el botón desde dónde se puede acceder al módulo IMCE en la inserción de imágenes en el editor:
- Página web del módulo en Drupal: http://drupal.org/project/imce
- Página web del desarrollador del módulo: http://ufku.com/
Mirad también los módulos que se recomiendan en la página del módulo en Drupal, valen la pena!
Módulos para Drupal 7 – Login
Posted by Xavi in Programación Web on 22/02/2011
El módulo que trataremos hoy sirve para mejorar la experiencia de los usuarios (o de los administradores) en todo lo que tenga relación a la identificación o el registro de los usuarios. Este módulo se llama LoginTobogan y está completamente preparado para la versión 7 de Drupal.
LoginTobogan proporciona las siguientes mejoras:
- Login de los usuarios utilizando el correo electrónico
Esta es una funcionalidad que muchas páginas deberían implementar. A veces es complicado recordar el nombre de usuario (aunque este siga siendo necesario por qüestiones de privacidad). - Presentación de los formularios de identificación/registro en una misma página
Esta página cambia entre el formulario de login y de registro por JavaScript pero la apariencia se tiene que acabar de afinar (vaya, que el estilo es feo decojonesnarices). - Modificación de las opciones de registro
Se añaden la repetición del correo electrónico y la posibilidad de que el usuario defina su password. Esta última característica puede ser un poco problemática ya que los usuarios son capaces de identificarse desde el mismo mo
Módulos para Drupal 7 – Editor WYSIWYG
Posted by Xavi in Programación Web on 20/02/2011
Tengo que confesar que hace tiempo intenté “meterme” a fondo en la versión 6 de Drupal y fracasé estrepitosamente; nunca conseguí hacerme amigo de los módulos Views y CCK pero parece que los tiempos han cambiado
Y con este cambio, casualmente, me he visto involucrado en dos proyectos que requieren algo más que un WordPress (damn it!). Mi primera idea fué huir despavorido hacía Joomla (siempre me pareció un poco más accesible) pero la reciente aparición de la versión 7 de Drupal me dió confianza suficiente para intentarlo otra vez. Total, al ser una versión nueva, todos partíamos de cero!
Pues bien, la experiencia está siendo bastante grata, he decidido lanzarme a por Drupal definitivamente aunque, como en todo, haya luces y sombras. Por ejemplo, el módulo CCK (integrado ahora en el core de Drupal) parece que tiene más ganas de conocerme y el módulo Views… bueno… sigue siendo el módulo Views, es muy suyo, pero algún dia encontraremos un punto de encuentro, seguro. La experiencia está siendo mucho más agradable pero he detectado que el ecosistema de módulos aun no ha conseguido ponerse al dia y eso da bastantes dolores de cabeza la verdad.
Esta falta de soporte a la nueva versión por parte de los módulos me ha animado a arrancar una série de artículos explicando mi experiencia con esos módulos (a veces en versiones alpha1 :-S ) y como sortear algunos de los problemas más comunes.
Dicho esto, vamos a por el primero de todos: El Editor WYSIWYG
Un Editor WYSIWYG en Drupal 7
Para añadir un editor WYSIWYG en Drupal yo he encontrado dos alternativas interesantes:
- El módulo WYSIWYG
- El módulo CKEditor
Módulo WYSIWYG
Con el módulo WYSIWYG vamos a tener que instalar el módulo para luego subir el editor que más nos guste (como TinyMCE, el mismo CKEditor o cualquier otro de los soportados). Una desventaja que tenemos al utilizar el módulo WYSIWYG es que la integración del módulo que nos permite subir imágenes es bastante más laborioso.
La configuración básica de WYSIWYG es muy intuitiva y los menús aparecen en lugares dónde uno espera encontrar las opciones de configuración pero, a medida que se piden más cosas, la cosa se complica. El ejemplo más claro lo tenemos con el módulo IMCE, que nos permite subir imágenes y archivos al espacio de disco destinado al gestor de contenidos.
Para activar el módulo IMCE, si hemos elegido el módulo WYSIWYG, debermos instalar un módulo que haga de puente entre el editor y el gestor de archivos y, posteriormente, instalar y configurar el gestor de archivos.
Da la sensación de que el módulo WYSIWYG es un módulo desarrollado para aspirar a entrar en el core de Drupal. El nivel de abstracción que proporciona hace necesario la instalación y configuración de módulos extra de la misma manera que los componentes internos de la plataforma.
- Web del plugin: http://drupal.org/project/wysiwyg
- Web del bridge para utilizar IMCE: http://drupal.org/project/imce_wysiwyg
Módulo CKEditor
La particularidad principal del módulo CKEditor es que no instala el editor automáticamente, al igual que pasa con el módulo WYSIWYG, se tiene que subir a posteriori. Esto es bastante extraño si tenemos en cuenta que sólo soporta el mencionado editor y debemos tener en cuenta también que no hace falta más configuración que subir el editor en la carpeta que se indica en las instrucciones de instalación (leedlas!).
La configuración de CKEditor es un poco más complicada que el módulo WYSIWYG pero únicamente porqué la ubicación de los menús de configuración es un poco rebuscada. Una vez correctamente configurado, es muy sencillo habilitar el soporte para gestores de archivos (soporta menos que WYSIWYG) y las tareas de mantenimiento son, realmente, mínimas.
A continuación podéis ver que la configuración para que el editor funcione es realmente sencilla (sólo es necessaria el primer atributo):
En la siguiente imagen os podéis hacer una idea de lo personalizable que puede llegar a ser el módulo si queremos entrar en detalles:
- Web del plugin: http://drupal.org/project/ckeditor
- Web del editor (para conseguir el editor): http://ckeditor.com/
Conclusiones
Cómo ya he avanzado en el apartado del módulo WYSIWYG, éste parece un módulo con aspiraciones a ser incluído en el core de Drupal; proporciona tanta flexibilidad y alternativas que el mantenimiento de este addon constituye una tarea independiente del mantenimiento de la salud del gestor de contenidos. Se trata de una genial alternativa para aquellos que experimentan con Drupal por placer o con vistas a evolucionar sus implementaciones constantemente.
Por otra parte tenemos el módulo CKEditor, que proporciona menos posibilidades pero que hace la vida del desarrollador mucha más fácil. El soporte a gestores de archivos es muy reducido pero soporta el que me gusta a mi así que… perfecto! Las opciones de CKEditor son muchas, pero debemos pensar que nos reducimos a este editor concreto.
Es díficil entender como Drupal se resiste a incluir ciertas funcionalidades en el núcleo de su plataforma. Un editor visual y un gestor mínimos de archivos no me parece algo descabellado, WordPress ha hecho muy buen trabajo con esto y creo que deberían seguir su ejemplo. Claro que seguramente pagando, santa Acquia canta…
Por cierto, si siempre te has preguntado que @#$! significa WYSIWYG… búscalo. Yo lo encontré
Google Storage for developers planta cara a Amazon S3
Posted by Xavi in General, Programación Web on 20/05/2010
Corrían rumores de que Google podía presentar una alternativa al servicio de almaceniamiento de Amazon, pero eran muy pocos los que creían que esto realmente podía pasar (me incluyo en el grupo de los incrédulos). Y Google anunció ayer en el Google I/O la disponibilidad de Google Storage for developers, un servicio de almacenamiento on-line con unas características muy parecidas a Amazon S3. Vamos a ver algunas de sus características:
- Almacenamiento por buckets/objetos: Exactamente igual que su vecino de Amazon.
- Nombre único del bucket en todo el servicio: Igual.
- Ausencia de carpetas o jerarquía pero capacidad de introducir el caracter “/” en el nombre del archivo para simular un árbol de directorios: Igual.
- Privacidad de los objetos 100% y inmutabilidad de los objetos: No recuerdo que Amazon detallara el punto de la privacidad (no estoy seguro), pero en cuanto a la inmutabilidad siguen siendo servicios equivalentes (hace falta reescribir el objeto para modificarlo).
A estas características básicas vamos a añadir un listado de las operaciones básicas. Veremos que siguen cortadas por el mismo patron que S3:
- Crear y eliminar buckets
- Listar buckets y objetos
- Subir y descargar objetos
- Eliminar objetos
- Definir listas de control de acceso (ACL) para los objetos
- Definir metadatos de los objetos
Y una serie de características adicionales, algunas de las cuales sí que marcan alguna diferencia con Amazon:
- Autenticación basada en cookies (no recuerdo que esto este disponible en S3 pero no estoy seguro de ello).
- Soporte a las cuentas de Google para establecer el nivel de seguridad de los objetos.
- Es necesaria una Developer Key (un par de clave de acceso y clave secreta).
- API REST (no existe una API SOAP y no parece que entre en los planes de Google).
- Soporte para SSL.
- Herramientas por linea de comandos y librería basadas en Python (Boto).
- Aplicación web para gestionar buckets y objetos (!!!).
La lista de precios también sigue el mismo patrón que Amazon pero se ofrece una cuota inicial gratuita (“solo” 100 GB de almacenamiento y 300 GB de transferencia al mes). Los precios son los siguientes:
- Almacenamiento: 0’17 US$/GB al mes
- Transferencia (subida): 0’10 US$/GB
- Transferencia (descarga): 0’15 US$/GB en América y EMEA y 0’30 US$/GB en APAC
- Peticiones (PUT,POST,LIST): 0’10 US$/1.000 peticiones
- Peticiones (GET,HEAD): 0’10 US$/10.000 peticiones
¿La mala noticia? Disponible para desarrolladores en los U.S. y con cola de admisión… espero que no tarden lo mismo que Amazon en traer los servicios a Europa!!
Amazon S3 amplia su abanico de posibilidades (RRS)
Posted by Xavi in Programación Web on 19/05/2010
Amazon S3 es un servicio de almacenamiento de objetos que fue definido por Amazon como “highly durable” pero nunca habían aportado datos ni estadísticas relacionadas con la durabilidad de los objetos que se almacenaban. Hoy, para anunciar una ampliación del abanico de posibilidades que ofrece el servicio han dado los primeros datos.
Amazon Web Services publica en su blog que la durabilidad de un archivo en su servicio de almacenamiento es del 99’9999999% (7 nueves) o, como exponen en el auncio, que de cada 10.000 objetos que almacenemos puede perderse uno (de media) cada 10 millones de años. Esta persistencia de ficheros en S3 la podemos considerar como muy alta… mucho más de lo que un gran número de aplicaciones necesitan realmente.
En ocasiones, todos los datos volcados en Amazon tienen su respaldo en máquinas que están más cerca del equipo responsable y simplemente se alojan en Amazon para su difusión por Internet (y su posible reposición está más que asegurada). En estos casos, esforzarse para mantener un porcentaje tan alto de durabilidad es un derroche de recursos que el cliente final no tiene porqué pagar.
¡Dicho y hecho!
A partir de hoy mismo, Amazon pone a disposición de los clientes la opción de reducir la durabilidad de sus archivos a 99’9999% (4 nueves) a cambio de una reducción en el precio del almacenamiento. Esta reducción va asociada a un parámetro que debe definirse de forma explícita (por defecto la durabilidad seguirá como antes) y es de un 33% del precio original. En el intervalo más caro (hasta 50 TB al mes), el almacenamiento “normal” cuesta 0’15€/mes por GB y el nuevo almacenamiento 0’10€/mes por GB.
Lo encontrareis en la página de S3 así como en el artículo del que he leído esta información, pero el nuevo sistema de almacenamiento se llama Reduced Redundancy Storage o RRS para los amigos.
-
You are currently browsing the archives for the Programación Web category.
¿Me sigues? :-)
Comentarios recientes