Categor铆as
c贸digo abierto Mundo 2.0

Usando git en (pre)producci贸n

Desarrollando con git

Desarrollar es un trabajo pesado, eso lo sabemos todos. Sobre todo, si queremos cumplir con todas las聽buenas pr谩cticas que deber铆amos.

Una de esas buenas pr谩cticas es聽llevar un control de versiones de tu software. No porque necesites separar la versi贸n 1 de la 2, sino porque llevar un control de versiones exhaustivo te ayudar谩 despu茅s a encontrar errores, a poder revertir cambios, y a que otros (o t煤 mismo dentro de dos meses) puedan revisar tu c贸digo para ayudarte a mejorar.

Muchos de nosotros, cuando estamos desarrollando algo, lo hacemos en un estado que llamamos de聽preproducci贸n. Esto s贸lo quiere decir que nuestro desarrollo no est谩 abierto a todos, visible. Por tanto, es un sitio de pruebas, donde nos da igual que se escupan errores por pantalla, o que la p谩gina est茅 descuadrada.

Cuando estamos haciendo ese trabajo podemos hacer 100-200 cambios al d铆a, y llevar un control de versiones de cada uno de los cambios que hacemos se puede convertir en algo pesado. 驴C贸mo lo convertimos en algo asequible? Automatiz谩ndolo.

El scripting

Soy de los que usan git聽(y SVN) desde聽consola. Para m铆 es mucho m谩s r谩pido porque juego con el聽scripting.

Por un lado, tengo una serie de alias definidos:

  • alias fp=’git format-patch’
  • alias ga=’git add .’
  • alias gc=’git commit -a -m’
  • alias gp=’git push origin master’
  • alias log=’git log –pretty=oneline’
  • alias sinc=’sh /Users/raven/Git/sinc’
  • alias st=’git status’

De esta forma, cada vez que tengo un cambio nuevo, los comandos a ejecutar son los siguientes:

> ga
> gc "mensaje de descripci贸n del commit"
> gp

Mi estructura de directorios incluye, en mi carpeta de usuario, una carpeta /Git donde tengo todos los repositorios de trabajo. Para cada uno de ellos tengo un peque帽o script que lanza una sincronizaci贸n con el servidor, de forma que si he cambiado algo all铆,聽ese cambio se reflejar谩 en mi directorio local.

As铆, s贸lo tendr茅 que ejecutar聽un comando, y se actualizar谩 mi copia local. Todos los scripts de actualizaci贸n los tengo en la carpeta /Git, en vez de dentro de cada uno de los repositorios, para que no interfieran con las copias.

git/raven.es> sh ../raven.sh

Ese archivo raven.sh tiene el siguiente contenido, que cambia para cada uno de los repositorios:

expect -c 'spawn rsync -avrhz -e "ssh -p" --progress --delete --exclude-from "/Users/raven/Git/exclude.txt" MIUSER@MISERVER:MIDIRECTORIO/raven.es/ /Users/raven/Git/raven.es/ ; expect password ; send "MIPASSWORD;\n" ; interact'

Este archivo exclude.txt tiene, en cada l铆nea, nombres de archivos o directorios que se ignorar谩n en la sincronizaci贸n, y puede tener el contenido que necesit茅is. En mi caso, el archivo tiene el siguiente contenido:

sources
public_html/database.*
core.*
.svn
.git
stats
backup_site
backup
*/backup
versiones-backup
uploads
blogs.dir
upgrade
logs
cgi-bin
*.tar.gz
hiccup
wp-content/uploads/
wp-content/blogs.dir/
wp-content/upgrade/
error_log
*/error_log
cache
*/cache

Automatizando a煤n m谩s

En mi directorio Git tambi茅n tengo un archivo, sinc, que lanza la sincronizaci贸n de todos los repositorios, lanzando uno a uno los sincronizadores individuales.
Aqu铆 las posibilidades son m煤ltiples. Dependiendo de vuestra forma de trabajar, os puede interesar lanzar la sincronizaci贸n y el git add en la misma orden, o hacerlo todo en bloque. Pod茅is fabricaros vuestro propio script a medida.

Lo que ten茅is que recordar es una cosa importante. Si hay algo que hac茅is muchas veces de forma parecida, invertid tiempo en automatizarla. En muy poco tiempo notar茅is la diferencia.

Categor铆as
c贸digo abierto Mundo 2.0 programaci贸n WordPress

Adi贸s, post-formats, adi贸s

Con mucha pena nos toca decir en esta semana adi贸s con la manita a los post-formats en WordPress 3.6. Muchos comentaron en la Meetup de WP Marbella聽que el nuevo formato de聽tumblrizaci贸n de WordPress no les gustaba, y en el chat de este mi茅rcoles se tom贸 la decisi贸n de apartarlos del聽core.

Post-formats

Aparte de que esto pueda quedar muy chulo, si hubiera aparecido por el a帽o 2008 o 2009 casi todos los desarrolladores habr铆an dicho al un铆sono聽esto es territorio plugin. Se nota que la fiebre del dise帽o y del UI/UX聽ha calado hondo, y en algunas cosas somos ahora m谩s flexibles ;).

Aunque se pierda esta barra, como comentaba antes, pasar谩 a ser un plugin tal y como comenta Mark Jaquith en este art铆culo. Lo que se saca del sistema es la UI (Interfaz de Usuario) que veis arriba, quedando en el sistema parte de la codificaci贸n. 驴Por qu茅 se hace esto? Porque los formatos de entrada, como la imagen destacada por ejemplo, ya son utilizados por casi todos los temas disponibles. Por tanto, se ha decidido mantenerlos tal y como estaban antes de 3.6, y los temas podr谩n mostrar los distintos formatos de otra forma.

post-formats-2聽Decimos adi贸s a la interfaz 芦bonita禄 de los formatos de entrada, pero no decimos adi贸s a los formatos, que seguir谩n dependiendo de los temas tal y como lo han hecho hasta ahora.

Qu茅 es un formato de entrada

Es una forma de mostrar una entrada. Teniendo el mismo contenido, podemos mostrar la informaci贸n de distintas formas. No es lo mismo que un Custom Post Type (CPT, tipo de datos), donde definimos un nuevo tipo de datos adaptado a nuestras necesidades, con nuevos campos, relaciones taxon贸micas…

Por qu茅 creo que esta decisi贸n es buena

No ya tanto porque sea聽territorio plugin, sino porque se va viendo un esp铆ritu colectivo de hacer que WordPress.org sea y siga siendo algo independiente de WordPress.com, donde este modelo de publicaci贸n posiblemente ser谩 un est谩ndar.

Por otro lado, si se convierte en est谩ndar en WP.com, me gustar铆a ver esta interfaz de publicaci贸n como m贸dulo en la pr贸xima versi贸n de Jetpack.