miércoles, 17 de abril de 2013

Xerox Phaser 6000 en Ubuntu 10.04 64bits


Acabo de comprarme una impresora laser a color, de las baratitas, porque estaba HASTA los mismisimos de una Epson DX 520 Color de inyección de tinta. 
( Mirar el logotipo de Linux en la impresora!! ) ;-)

Para mí, un timo de cuidado el tema de la tinta de estas impresoras.

Ahora bien, para que funcione , en mi caso uso Ubuntu 10.04 a 64 bits,  el fabricante, en este caso Xerox, nos dá un triste driver a 32 bits en formato DEB;
http://www.support.xerox.com/support/phaser-6000/downloads/engb.html?operatingSystem=linux&fileLanguage=en_GB

Hay un rpm para 32&64, en este caso para RedHat y Suse, pero no he querido jugar con él, y no sé si puede meterlo en mi sistema.

Bueno, la solución a sido forzar a instalarlo , como cualquier otro programa de 32bits a partir del deb que nos hemos bajado posteriormente


Si quieres arriesgarte e instalar aplicaciones de 32 bits en tu ordenador con arquitectura de 64 bits, siempre que ese programa o aplicación a instalar no tenga su versión para la otra arquitectura, podemos forzar la instalación de ésta en un sistema Linux de 64 bits, de la siguiente forma:

Paso1.- Instalar las librerias de 32 bits en nuestro sistema de 64 bits con el siguiente comando:sudo apt-get install ia32-libs
Paso2.- Instalamos la aplicación deseada (en formato .deb, .rpm, etc.). En este caso hemos llamado a la aplicación de 32bits como ejemplo32bits.deb.
sudo dpkg –force-architecture -i ejemplo32bits.deb
Con esto conseguiremos instalar en nuestro equipo, el cual tiene una arquitectura de 64 bits, un programa o aplicación creado para a arquitectura de 32 bits.

Simulando en git , $Revision:$ de Subversion

Simulando en git , $Revision:$ de Subversion


Estamos en una charla con Yeradis, si sería posible simular algo como el id de $Revision:$ de SVN.
Particularmente, el numero de revisión automático me da igual, pero Yeradis es un 'plasta' con el tema,
nos hemos puesto los 2 y esto es lo que ha salido.

La idea , es usar los tags de git para hacer esa tarea
Lo  primero es generar un tag numérico que usaremos como inicio. Para ello nada más simple que hacer:
git tag -a 1

Después creamos un fichero, llámalo deploy.sh. Lo colocamos en /git/bin para que esté disponible.



#revision tags must be an INTEGER value
export tag=`git tag | sort -n | tail -1`

text=`echo $tag | sed "s/\([^0-9]*\)\([0-9]*\)/\1/"` ;
num=`echo $tag | sed "s/\([^0-9]*\)\([0-9]*\)/\2/"` ;
rev=`echo $text$(($num + 1))`

find ./ -name "*.c" -type f | while read file
do
    awk '{gsub(/\$Revision:(.*)\$/, "$Revision: '$rev' $"); print}' $file >$file.$$
mv -v $file.$$ $file
done

git commit -am "$1" && git tag -a $rev -m "$1" && echo "Revision:" $rev



Después en nuestro .gitconfig añadimos esta linea;




[alias]
deploy = !sh deploy.sh





Ahora , solamente tendremos que hacer;
git deploy "Nueva revision"

¿ Que hace esto ?

  1. Obtenemos el valor del ultimo tag, en este caso 1, y lo aumenta a 2
  2. Busca según el patrón "*.c", en este caso me interesa que busque solo los de código fuente de C, y      reemplaza la cadena $Revision: $ por la nueva revisión  , en este caso la 2., quedando como $Revision: 2$
  3. Realiza el commit
  4. Crea el tag con la nueva revisión.
 Este script se puede mejorar en muchos aspectos, pero abre una vía para una posible mejora, como controlar los errores devueltos, etc..








miércoles, 10 de abril de 2013

Ya está listo Gnome 3.8.

Hace días  he estado viendo las releases previas al lanzamiento de Gnome 3.8, y he de decir , que para mí, esta vez si que lo han conseguido.

Enhorabuena a los muchachos de Gnome, porque tiene una pinta estupenda.
Además, Gnome-Shell, particularmente me gusta, y mucho.

Más info:
https://help.gnome.org/misc/release-notes/3.8/

Buenas prácticas con GIT







Una manera de trabajar con GIT, es establecer un patrón de trabajo a nivel de empresa, a seguir por todos, aunque es aplicable a cualquier otro control de versiones.


Estableceremos 2 ramas principales que estarán en remoto:

  • master para producción
  • develop para desarrollo

La rama master es la rama principal que es la que se pone en producción.
Esta rama es la que tiene LA ÚLTIMA VERSIÓN ESTABLE.

Cuando la rama develop es lo suficiente estable, se puede mezclar con la rama master.

Es política de la empresa determinar quien / como / porque, es el responsable último de determinar cuando la rama develop pasa a master, ocasionando con ello un cambio de versión en la master.

La rama master tiene que tener los tags de versionado.
Establecer un sistema a seguir de número, como por ejemplo ubuntu, año/mes, 10.04, 10.10, etc., o por fecha , etc..

Se desarrolla en la rama develop , y cuando se llega a un versión estable, fusionamos con la master y producimos una nueva versión.

Establecer ramas de apoyo , pero limitadas en el tiempo, como por ejemplo;

  • Ramas de características (features)
  • Ramas de revisiones (hotfixes)

Cada una de estas ramas tiene un propósito específico están sujetas a estrictas normas. Podemos crear más ramas de apoyo, pero en mi caso, no me ha sido necesario.




Ramas features.  Rama padre: DEVELOP  Merge con: DEVELOP


   Estas ramas se utilizan para desarrollar nuevas características para una nueva versión.  
   La esencia de una rama de la característica es que existe, siempre y cuando la función está en desarrollo,   pero finalmente se fusiona de nuevo en develop.
   Se ramifican a partir de develop  y se combinan de nuevo en develop.  Las ramas de características no existen en origin.

Como tenemos que proceder:


Creamos una rama feature;
>git checkout -b feature_notes develop

Esto nos crea una rama feature_notes y nos coloca directo para trabajar en ella.
*Es lo mismo que hacer desde la rama develop :
>git branch feature_notes
>git checkout feature_notes

Implementaremos las mejoras correspondientes en nuestro código.
En este apartado , podemos considerar necesario hacer un git rebase -i, donde podemos definir que historia de cambios vamos a mostrar en la rama develop.
Es decir, si hemos realizado 12 commits en la rama feature_notes, no quiero que se muestre ese a la hora de fusionar, podemos agrupar todos esos commits en uno solo, mostrando la historia como un solo commit.

Incorporación de una nueva característica en develop
>git checkout develop
Switched to branch 'develop'
  
>git merge --no-ff feature_notes   
Updating ea1b82a..05e9557 (Summary of changes)
Con esto conseguimos que se cree un  nuevo objeto, guarde en el log  donde empieza y termina la feature, para que seguir la historia sea más rápido.
  
Ahora la rama feature_notes, no nos sirve para nada, la borramos.
>git branch -d feature_notes
    Deleted branch myfeature (was 05e9557).

Subimos nuestros cambios ya fusionados al origin.
>git push origin develop

Ramas hotfixes PADRE:Master Merge con: Master y Develop


   Se ramifican a partir de master y se deben combinar de nuevo en develop y master. La nomenclatura debe ser hotfix.

Si un bug es crítico debe ser resuelto inmediatamente.
La esencia de este método de trabajo es que los miembros del equipo (rama develop)   pueden seguir trabajando mientras que otra persona soluciona el bug.

Como tenemos que proceder:

Creación de una rama hotfix
Las ramas de revisión se crean a partir de la rama master.
Veámoslo con un ejemplo, digamos que estamos en la versión  de producción 1.2 y  esta hay un bug bastante grave. Supongamos que los cambios en develop son todavía bastante inestable.
A continuación vamos a bifurcar la rama master  para arreglar el problema.

>git checkout -b hotfix-1.2.1 master
Switched to a new branch "hotfix-1.2.1"
    
Corregimos el error en el código.

> git commit -a -m "Bumped version number to 1.2.1"
[hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1
1 files changed, 1 insertions(+), 1 deletions(-)

No hay que olvidarse de modificar el número de versión después de la ramificación.

Después, arreglar el fallo y confirmar la corrección con uno o mas commits separados.

> git commit -m "Fixed severe production problem"
[hotfix-1.2.1 abbe5d6] Fixed severe production problem
5 files changed, 32 insertions(+), 17 deletions(-)
   
Terminar una rama de hotfix.
MERGE CON: master y develop

En primer lugar actualizamos master para marcar la liberación.
Nos posicionamos en la rama master;
>git checkout master
        Switched to branch 'master'

Después, fusionamos la rama que hemos creado de hotfix-1.2.1 con la master, pero recordad, con la opción --no-ff
        >git merge --no-ff hotfix-1.2.1
        Merge made by recursive.
        (Summary of changes)

A continuación, y muy importante, es tagear esa versión corregida.
        > git tag -a 1.2.1
        
Después incluimos este “parche” también en develop

        > git checkout develop
        Switched to branch 'develop'
        > git merge --no-ff hotfix-1.2.1
        Merge made by recursive.
        (Summary of changes)

Por último matamos la rama temporal, pues no servirá para nada.

        > git branch -d hotfix-1.2.1
        Deleted branch hotfix-1.2.1 (was abbe5d6).

Estas ideas han sido sacadas básicamente de:

Tenéis vía google docs el documento; Guia de buenas prácticas con GIT

domingo, 7 de abril de 2013

Restaurar InnoDB con TDolphin.



Estoy usando TDolphin de Daniel , http://tdolphin.blogspot.com.es/ y estoy realizando el soporte de copia de seguridad.

He encontrado un problema a la hora de hacer la restauración de la copia, y es debido a al uso del motor InnoDB, y las claves foráneas.

El problema es que no puedes crear, por ejemplo, la tabla albaran cuando depende esta de la tabla cliente.

La solución es bastante simple;


function Restore_backup( )
  Local oErr
  Local cFile := ChooseFile( "Selecciona fichero backup" )

  try 
     oServer:Execute( "SET FOREIGN_KEY_CHECKS = 0;" )
     oServer:Restore( cFile )
     oServer:Execute( "SET FOREIGN_KEY_CHECKS = 1;" )
     Msginfo( "Restauracion completada" )
  catch oErr
       MsgStop( oErr:Description )
  end
return nil
  

Lo que hacemos es desconectar el chequeo de la clave foránea, restaurar la BD y después, volvemos a activarlo.

Otra problema con el que tuve que liar fue con los permisos necesarios para el usuario en cuestión pudiese hacer la copia de seguridad y posterior restauración en MySql.

Tan simple como ejecutar estas lineas en el cliente de Mysql, solo cambia el usuario backup y el de la BD , basededatos, por el tuyo;




mysql> grant select on basededatos.* to ‘backup’@'localhost’ with grant option;
mysql> grant lock tables on basededatos.* to backup@localhost;
mysql> grant reload on *.* to backup@localhost;  







Android y Git. Disponer del hash automáticamente.

Una de las cosas a las que estoy acostumbrado, es tener siempre en mi código, el hash/tag/versión del control de versiones que estoy usan...