miércoles, 10 de julio de 2013

Cuando hacer un commit y como hacerlo


Cuando hacer un commit y como hacerlo

Según mi experiencia en estos años usando control de versiones, y colaborando y siguiendo varios proyectos, he ido modificando mi manera de trabajar, según voy usándolo.

Aclaro que cada cual puede trabajar de la manera que mejor le convenga, pero está claro, que en los proyectos donde trabajan varios usuarios, es necesario al menos establecer unas normas, por el bien común de todos los integrantes y de los futuros que puedan incorporarse.

Así, podemos establecer un sistema de obligado cumplimiento por los miembros del proyecto.

Las reglas básicas del commit

  • Una funcionalidad, un commit. Usa ramas locales para ello. Después fusiona con la rama que vas a usar para subir tus cambios al repositorio remoto.
  • Evitar a toda costa hacer commits enormes, que corrigen un sinfín de cosas, con o sin relación alguna entre ellos.
¿ Parece una cosa muy fácil ?  No creas. 

El humano está acostumbrado a los malos hábitos, adquiridos con los años de esfuerzo en hacer las cosas diferentes al resto, y cambiar esto, va a costar.

¿ Que aporta esto ?


  • Mejora el encontrar posibles errores y su posterior corrección se torna muy simple, sobretodo , a la hora de fusionar por ejemplo la rama hotfix con la rama de producción.
Al tener, en principio, muy pocos cambios, será más sencilla su fusión.


  • La historia es mucho más simple , y el seguimiento será mucho más simple, sobretodo , para futura gente que se una al proyecto.

Pero a la hora de hacer el commit , tenemos que documentar que es.


Las reglas básicas del log

  • Si se usa un sistema de ticket , hacer referencia en el mensaje. Esto aporta mucho más información, que nos servirá posteriormente a la hora de tratar con la información.
  • Podemos usar una plantilla en git a través de los hooks, pero a grandes rasgos podemos simplificarlo cumpliendo este patrón:
    [DESCRIPCION CORTA] Obligatorio.
    [DEJAR ESPACIO EN BLANCO] Opcional.
    [DESCRIPCION LARGA] Opcional.
Es importante en el commit, identificar para un futuro que es lo que se realizado o solucionado.

Recordad, no estamos solos nosotros, por lo tanto, si hacemos un commit de 100 cambios, y cada fichero tiene inserciones, borrados, etc.., solo el programador que subió los cambios va a saber de que va todo esto. 

El resto , si se lo mira, lo tiene fácil, este marrón no me lo voy a comer, porque no tengo NI IDEA de lo que hace.

¿ Alguien aplica otros criterios ? 



lunes, 8 de julio de 2013

Similitud entre encaje de bolillos vs Git

Llevo un par de días haciendo encaje de bolillos con Git.



No veo yo mucha diferencia entre un encaje de bolillos y las ramas de git.

Fíjate como va escribiendo la historia, cada bolillo es un rama local, donde se fusiona, trascurre paralela al desarrollo principal, etc..


Aprender a decir NO


Una de las cosas que más rabia me da , es la incapacidad de decir no.
A veces, un NO en el momento adecuado, va a suponer la diferencia entre hacer las cosas bien o mal.

¿ Se puede desplegar un proyecto un viernes por la tarde ? NO
¿ Se puede poner una nueva feature antes de irse de vacaciones ? NO

Es importante decir a veces, NO.

miércoles, 3 de julio de 2013

GIT en el día a día





Cuando me preguntan el porque usar GIT, una imagen vale más que mil palabras.
La flexibilidad y potencia de esta maravillosa herramienta de control de versiones no tiene discusión.

Mi código esta en mi máquina, la historia que yo veo, no tiene porque ser la historia que se vea cuando suba mis cambios al repositorio remoto.

Esto es lo maravilloso de los control de versiones distribuidos.

GTK 3.1 GTK+ Stock Items Deprecation


Tengo pendiente de  pasar t-gtk con soporte a GTK2 al nuevo API GTK3.

Pero , parece que para GTK 3.10 quitarán el soporte a los Stock Items  Stock Deprecation

Sinceramente, no entiendo a los programadores que quiten o cambian el nombre de funciones, clases y métodos, por que suena más cool, o "por que yo lo valgo".

Uno de los motivos es que ahora será más fácil, puede ser, no lo discuto, lo que sí discuto , es que romper algo que lleva años, es tirar montones de lineas de código a la basura, y programas que ya no tienen a nadie detrás, pero puede funcionar simplemente compilando, ahora dejaran de ser inservibles.

Pero por poner un ejemplo


Old:
item = gtk_tool_button_new_from_stock (GTK_STOCK_SAVE);
New:
item = gtk_tool_button_new (NULL, _(“_Save”));
gtk_tool_button_set_icon_name (GTK_TOOL_BUTTON (item), “document-save”);



Vaya, parece que tendremos que picar más código....

Considero que un API debe de proporcionar una estabilidad , y si esta se rompe, es por un diseño deficiente.

Una cosa que tiene el Kernel de Linux, es que si cojes el código C de hace 30 años de Unix, este funciona sin problemas.

¿ Se hace cosas nuevas ? Por supuesto, pero NUNCA se rompe la compatibilidad que hay.
Ojo, que no es una cosa solo de GTK, es como un virus, se propaga a otros proyectos como la peste.

En fin, aquí dejo el enlace donde esta ahora las equivalencias.

Y muchas gracias al equipo de GTK por seguir haciendo crecer esta fantástica librería.

KOTLIN. Property , esa cosa que no es un field.

KOTLIN. Property , esa cosa que no es un field. Haciendo una pausa en la documentación, me pongo a experimental el crear / pasar mi...