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

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.

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!

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

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!

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

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

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

Dicho esto voy a presentaros una de las ROMs que he probado estos días en el Nexus: MIUI. Esta ROM tiene bastante fama y atrae un buen número de las miradas dirigidas al mundo de las ROMs alternativas.

La primera sensación que da esta ROM es de tener los detalles gráficos muy cuidados. La interfaz gráfica es muy limpia y sorprende la fluidez con la que se maneja. En la imágen siguiente podemos ver una captura de pantalla de mi terminal con esta ROM.

NOTA: Las ROMs MIUI permiten tomar capturas de pantalla directamente desde el terminal y sin la instalación de ningún añadido.

A continuación, cuando empezamos a jugar con las configuraciones de esta ROM nos damos cuenta de la flexibilidad de ésta y del potencial que tiene a la hora de personalizar nuestro terminal. Es en este punto donde también se pone de manifiesto una de sus características/defectos que, desde mi punto de vista, le resta punto: el aroma a iPhone que desprenden algunos de sus elementos de diseño. Para ilustrar esto os pongo una captura de los menus de configuración:

Sinceramente, el rendimiento de esta ROM me ha sorprendido muy gratamente y detalles como el hecho de que incluya ya la última versión del Market o que se actualice todos los viernes de forma programada me hace otorgarle una muy buena nota. Y alguién más debe pensar lo mismo porqué este mismo año se va a poner a la venta un terminal con esta ROM de serie. ¡Ah! se me olvidaba, tiene un gran reproductor de música, le da mil vueltas al reproductor de música por defecto en mi opinión.

Y aun así, no será la que se quede en mi terminal, pues no ofrece acceso al código fuente y esa es una de las grandes virtudes de Android. Cada uno que elija su camino

• MIUI Oficial: http://en.miui.com/
• MIUI Reino unido: http://miuiandroid.com/
• MIUI en Castellano: http://miui.es/

El euipo de AlphaRev ha publicado recientemente una nueva versión de los HBOOT Oxygen y CyanogenMod7 para la Desire (tienes una Desire y aun no conoces el trabajo de AlphaRev? abre el enlace de su página oficial o del thread en XDA ya!) y comunicaron por Twitter y otros canales la conveniencia de actualizarse.

Las instrucciones para actualizar si ya teníamos el HBOOT de AlphaRev instalado son muy sencillas por lo que no genera ningún tipo de temor el hecho de actualizarlo… hasta que pasa lo que pasa… que te quedas sin móvil… durante los minutos que tardas a llegar hasta aquí.

Para evitar que nos pase esto, primero vamos a repasar los pasos que se describen en la página de AlphaRev:

1. Hacer un backup desde el recovery (Nandroid)
2. Descargar y verificar (md5) la imagen del HBOOT
3. “Flashear” la imagen del HBOOT (fastboot flash hboot nombre_del_archivo_del_hboot.img)
4. Ejecutar: fastboot reboot-bootloader (y esperar a que reinicie, tarda muy poco)
5. Ejecutar: fastboot erase cache
6. Entrar en el recovery, hacer wipe de todo y restaurar el backup

Pues bien, si haces esto con la versión 7 de Cyanogen instalada, la restauración del backup NO funciona y el telefono se queda completamente colgado. Si este es el caso, saca y mete la batería (para devolver la vida a tu móvil) y sigue estos sencillos pasos:

1. Hacemos wipe de todo (aunque no creo que sea imprescindible)
2. Instala la versión 7 de Cyanogen desde cero (flash .zip from sd), yo utilicé la versión 7.0.3
3. Ahora sí, intenta restaurar el backup creado antes de que todo esto ocurriera

Yo conseguí restaurar el backup sin perder nada de nada, pero la sensación de perder completamente el control de la Desire es muuuy desagradable

Evidentemente, no me hago responsable de ladrillos que puedan surgir por culpa de seguir estos pasos. Este procedimiento me ha funcionado a mi (y, en el futuro, quizás a alguna víctima más que encuentre por el trabajo, pero aun no tengo más información que mi experiencia personal).

Esto conlleva algunas ventajas pero también algunas desventajas. Una de ellas es ver como en el calendario que se muestra en la barra del sistema las semanas empieza por domingo. Realmente no se trata de un problema pero… ya que utilizamos software libre ¿por qué no vamos a adaptarlo al 100% a nuestros gustos y preferencias?

Manos a la obra…

Primero de todo vamos a editar el fichero “/usr/share/i18n/locales/en_US” y dónde encontremos:
first_weekday 1

Debeis poner:
first_weekday 2

Cómo podréis observar, el valor que ponemos coincide con el valor de la linea que empieza con “first_workday”. ¿Es casualidad? pues no, first_workday define el primer dia laborable de la semana y, por lo tanto, es normal que coincidan si queremos que nuestras semanas empiecen en lunes.

Una vez guardada esta modificación debemos ejecutar el comando “sudo locale-gen”. Esperamos que termine de generar todas las alternativas, reiniciamos la sesión (o ejecutamos “pkill gnome-panel” en el terminal, pero eso yo no lo he dicho!) y… lunes como primer dia de la semana!

Si tienes como primer dia de la semana el lunes y quieres cambiarlo a domingo, en lugar de cambiar el valor de first_weekday de 1 a 2, hazlo al revés