Inspiración (viejuna)

Hay un montón de formas diferentes de encontrar la inspiración, unos hacen deporte, otros leen, otros trabajan… Da igual, todos en algún momento hacemos algo concreto para buscarla y a veces encontrarla es tan fácil como mirar atrás.

Hoy, en este apunte corto, quería compartir un anuncio de Apple que me parece brillante y que vale la pensa recordar:

Hace tiempo que no soy usuario de productos de esta compañía pero hay que reconocer que su trabajo de márqueting es espectacular. En el siguiente vídeo podemos ver al mismo Steve Jobs presentando la campaña:

Y para que no sea un artículo demasiado corto… el mejor anuncio de todos los tiempos:

¿O no?
 

“Conector” y “Easy Startup” recursos para emprendedores en Barcelona

Soy de la opinión que hay algo de burbuja en el círculo emprendedor. Desconozco como funciona en otras ciudades pero la cantidad de eventos alrededor de las “Startup” en Barcelona me parece un poco desproporcionado. Que no se me malinterprete! Creo que es un buen mecanismo para intentar mejorar los índices de ocupación y para motivar a personas que seguramente fuera de este clima de euforia emprendedora no darían el paso y que estoy seguro que nos nutrirán de grandes empresas en un futuro.

Dicho esto, me gustaría compartir un par de recursos que me han parecido interesantes para las personas que están pensando en hacer crecer su idea:

El primero me llega a través de la página TodoStartUps, se trata de una nueva aceleradora en Barcelona llamada Conector. Esta nueva aceleradora cuenta con la participación de Carlos Blanco, Xavier Verdaguer, Gerard Olivé, Marc Ros, Risto Mejide, Miguel Vicente y Marc Vidal. Según explica éste último en su blog la sede inicial se ha situado en Barcelona pero se espera que la iniciativa se expanda por otras ciudades alrededor del mundo.

Seguro que el número de proyectos interesados en entrar a esta aceleradora estará muy por encima del número de proyectos que tienen pensado “guiar” pero para aquellos que consigan entrar se trata de una gran oportunidad.

Logo Conector

El segundo recurso me llega por métodos más tradicionales (mi pareja me lo comentó durante la cena) y se trata de una iniciativa del grupo Nuñez y Navarro para facilitar el acceso de las Startup a alguna de sus oficinas. A falta de más información la página web de esta iniciativa, Easy Startup, promete 6 meses gratis de alquiler de las oficinas durante el primer año “como emprendedor”. No sabemos más sobre las condiciones pero a bote pronto parece una buena oportunidad para facilitar el flujo de caja de empresas recién nacidas.

Logo EasyStartup

Enlaces:

Suma y sigue

Hace dos años que no escribo regularmente en este blog. Es verdad que han cambiado muchas cosas en dos años (a nivel personal y profesional) y que el blog en Inglés ha acaparado buena parte de mi atención, pero siendo sincero conmigo mismo esto no es excusa suficiente para tanto tiempo desatendiendo mis necesidades comunicativas.

La sinceridad con uno mismo es importante. No quiero decir que la sinceridad con los demás no lo sea, pero engañarse a uno mismo es muy feo; al final, TÚ eres la persona con la que vas a estar más tiempo en esta vida. Y es esta necesidad de sincerarme es la que me empuja a escribir este artículo.

Hace tiempo que dejé de escribir en este espacio porque perdí la pasión por lo que estaba haciendo. Dedicaba muchas horas a la semana a cosas sobre las que no tenía ganas de postear, otras horas las dedicaba a cosas sobre las que era mejor no postear, no vaya a ser que se me escape información confidencial y la liemos! Cuando llegaba a casa no tenía energía suficiente para ponerme a desarrollar con los lenguajes de programación que deseaba aprender o simplemente probar cosas nuevas, como os comentaba, simplemente no me apetecía…

Hasta hace unos días.

En Abril de este mismo año empecé un MBA para complementar mi formación técnica. En mi cerebro estaba todo muy bien planificado: “ya he realizado un máster en el ámbito tecnológico, ahora me paso un año aprendiendo a manejar números, me planto con una carrera y dos máster antes de los 30 y a currar que son dos días” pues… mierda (con perdón), cuando piensas que lo tienes todo bajo control es que estás totalmente equivocado.

En el programa del MBA se han empeñado en hacernos crecer en base a competencias (principalmente de liderazgo) y eso, si te lo tomas en serio te remueve por dentro y te hace pensar. Sí, lo digo en serio, te hace pensar sobre que imagen tienes de ti mismo, cómo quieres tratar a los demás, que valores aprecias en la compañía en la que quieres trabajar, que quieres ser “de mayor” y un largo etcétera.

Así que después de este rollo suelto una pregunta al aire: ¿Realmente os habéis parado a pensar sobre eso alguna vez? Va en serio! Porque pensaba que yo sí y no era verdad!

Se que no era verdad porque cuando alineas las cosas que haces con tus valores y, en consecuencia, con las cosas que te motivan los días parece que se hacen más largos. De golpe y porrazo puedes hacer un montón de cosas, duermes menos sí pero cuando te levantas lo haces con optimismo con ganas de saber qué vas a descubrir, aprender o hacer ese día. No se trata de trabajar tus horas y pensar que la vida está ahí fuera, se trata de ser la mejor versión de tu mismo e intentar encontrar un sitio en el que te encuentres a gusto, que se adapte a tu forma de trabajar, en la que se respeten tus inquietudes, que te valoren por lo que eres y por lo que puedes aportar.

Se que no era verdad porque ahora me puedo levantar entre las 6 menos diez y las seis para hacer media hora de ejercicio antes de ir a trabajar y por la noche seguir siendo persona cuando llego a casa. Hace unos días en mi cabeza eso era completamente inviable.

Se que no era verdad porque estoy escribiendo este artículo aunque y lo voy a colgar independientemente de que los pocos lectores que me quedan vayan a pensar que me he pegado un golpe en la cabeza.

Ante este volcado de información uno podría pensar: “eso quiere decir que todo lo que va a escribir este tío a partir de ahora van a ser pajas mentales como este artículo”. Pues no. Mi idea no es esa, pero sí es verdad que voy a empezar a tratar otros temas que atraen mi atención como el mundillo emprendedor, la motivación, el management o el coaching a parte de temas puramente tecnológicos. Durante los días en que he estado reflexionado acerca de este cambio se me ha cruzado la idea de ser un “traidor” o algo parecido por no mantenerme fiel al objetivo inicial del blog. Después de mucha reflexión he acordado conmigo mismo que no me siento así y no me siento culpable por no sentirme así; no me siento un traidor porque todo el mundo tiene derecho a evolucionar y buscar cosas nuevas y, al fin y al cabo, el blog se llama iXavi (es decir, mi versión personalizada para mi mismo :).

Espero que nadie se asuste y que pueda seguir aportando mis reflexiones cada vez más a menudo.

Movimientos

No hace mucho anuncié que me había decidido a abrir un par de espacios adicionales en iXavi. No siempre hablo de lo mismo y no siempre me gusta hacerlo de la misma manera así que abrí un espacio para comentar “cosillas” técnicas en inglés y otro para comentar temas más diversos en catalán.

Aunque haya tenido poco tiempo para escribir en ambos espacios sigo con el convencimiento de que son un buen instrumento para dar salida a mis pensamientos, peeeeero (siempre hay un pero ;-) ) he decidido cambiar el proveedor de estos espacios. Hasta ahora alojaba yo mismo estos dos espacios pero, al ver que el uso que les iba a dar era puramente de blog, he decidido apostar por Blogger para esta nueva etapa.

No voy a mentir, he rajado mucho sobre Blogger, MUCHO! Soy fan de WordPress en su forma más dura, instalándolos a pelo en cualquier clase de hosting pero… sinceramente… ya me peleo suficiente con despliegues de aplicaciones PHP en el trabajo; vamos a dejar que Google y Python se encargen de ellos durante un tiempo, a ver como va :-)

Eso es todo por hoy, podéis acceder a estos espacios en las mismas direcciones que antes en.ixavi.com y cat.ixavi.com pero las suscripciones RSS sí han cambiado (aquí en inglés y aquí en catalán).

Espacios nuevos en iXavi

Después de un tiempo (más de dos años ya :-) ) con el mismo formato, he decidido dotar a iXavi de un par de espacios más.

Estos dos espacios se pueden encontrar en en.ixavi.com y cat.ixavi.com. El primero de ellos tiene exactamente la misma intención que este espacio pero el contenido va a ser publicado en Inglés (ya era hora de que me animara a ello no?) y el segundo de ellos tiene un objetivo más personal y es el espacio en el que voy a dejar salir mis opiniones sobre el mundo en general y va a sustituir la desaparecida xaviland.com (y como podréis deducir de su nombre, va a estar en Catalán).

Si os pasáis por estos nuevos espacios vais a ver que los cambios respecto al site original van cambiando poco a poco pero por ahora van a tener exactamente el mismo look.

Gracias a todos!!

Problemas con tarjetas Wi-fi Broadcom en Ubuntu 11.10 (beta 1)

Por un tema de trabajo a largo plazo, este fin de semana he decidido actualizar mi equipo a la primera beta de la versión de Ubuntu que se va a liberar en Octubre. Esta decisión es un poco arriesgada pero espero que en pocas semanas ya estén arreglados todos los pequeños fallos de esta versión, Ubuntu casi siempre tiene una versión más que usable unos días antes de la release definitiva. Pero no nos vamos a engañar, una persona sin experiencia en gestionar equipos con GNU/Linux ya se hubiese tirado de un puente con las pequeñas cosas que me he encontrado al hacer el upgrade.

Uno de los principales problemas, como siempre, ha sido el comportamiento de la tarjeta Wireless Broadcom. De hecho, estoy a punto de tirarla al rio, pisarla repetidamente con unas botas, tirarla al Llobregat o al Besòs y comprarme una Intel (sí, de esas que enchufas al equipo y simplemente funcionan) pero Septiembre es un mes muy malo para gastar así que antes de cobrar este mes he tenido que encontrar una solución para seguir conectándome a mi red casera :-).

Por experiencia empírica al final me he dado cuenta de que me puedo conectar a cualquier Wi-fi mientras tenga el portátil conectado a la corriente pero que la conexión se va al traste en el momento en el que lo desconecto de la corriente. Así, leyendo por los foros de Ubuntu, he descubierto que, ya en versiones anteriores del sistema, la gestión de energía de estas tarjetas es bastante proclive a generar desaguisados de este tipo. Y efectivamente, no hay que ser un experto en BASH para leer el contenido del fichero /usr/lib/pm-utils/power.d/wireless y darse cuenta que los cuatro comandos que ahí se especifican no pueden ser suficientes para garantizar una conexión estable.

Entonces qué? os estaréis preguntando, nos pasamos dicho archivo por la piedra? NOOOOO… hay una solución mucho más elegante y refinada que nos dejará este archivo intacto y nos permite conectarnos a las redes independientemente de la fuente de energía que estemos utilizando. Esta solución se basa en crear un fichero vacío llamado wireless en el directorio /etc/pm/power.d. En principio esto debería sobreescribir el funcionamiento del anterior fichero y dejar de “liarla parda” con la gestión de energía de la tarjeta de conexiones inalámbricas.

Es posible que este parche (porqué es simplemente un parche) os haga que el equipo consuma un poco más de lo que consume con el control de la tarjeta activado pero yo no he notado un cambio significativo.

wifi-logo

Ruby on Rails – Layouts y Hojas de Estilo

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.

layout image

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

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:

script/generate controller index index

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 :-D ) 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

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 :-D ) 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!! :-D ) 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

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? :-)

Ruby Logo

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!!