QuarkBlog_2.0

El GULA (Grupo de Usuarios de Linux de Alicante) y la Escuela Politécnica Superior de Alicante organizan por segundo año un curso de introducción al sistema operativo y herramientas GNU.

Tal y como ocurrió el año pasado por estas fechas, GULA organiza un curso gratuito de iniciación al sistema operativo GNU/Linux, con el objetivo de enseñar los conocimientos básicos para manejarlo a quien haya tenido poco o ningún contacto con él.

El curso está abierto a todo el mundo, teniendo preferencia en caso de falta de plazas los alumnos de la EPSA, por ser organizadores y patrocinadores, respectivamente.

El curso tiene una duración de cuatro semanas, a razón de una clase de dos horas y media a la semana, completando un tal de diez horas de docencia. Las clases comenzarán la semana del 12-16 de febrero y terminarán la del 5-9 de marzo.

Si hay alguien interesado que se apunte ya, las plazas son limitadas. Esperemos que vuelva a ser un éxito como la otra vez

El trabajo de miles de ingenieros durante 6 años ve la luz: Microsoft Windows Vista.

Esto es lo que trae nuevo (artículo completo aquí y aquí):

• En primer lugar, Vista disminuye la funcionalidad del hardware en muchos niveles. Si estás disfrutando de contenido “protegido” (un HD-DVD o Blueray, por ejemplo), Vista te desactiva ciertas salidas de audio, como la S/PDIF, la más utilizada (dicen) por profesionales de audio. ¿Por qué? Pues porque S/PDIF es una conexión que no protege los contenidos, alguien podría grabar sonido de alta calidad por ahí. ¿Que te has gastado una pasta en un ordenador profesional completamente legal? Pues te jodes, como Herodes. Así de sencillo. Y donde digo S/PDIF, digo todo aquellas salidas de datos que no “protejan”, que a día de hoy son todas (más sobre eso más adelante). Ciertos modos de video están tambien desactivados, porque permitirían copiar el video (los usuarios más avispados de Mac OS X - que no se libra del todo, y mucho menos con su reciente alianza con Intel - se habrán dado cuenta de que por ejemplo, no pueden hacer capturas de pantalla si se está reproduciendo un DVD: Requisito que Apple ha implementado para agradar a las industrias del cine). ¿Y crees que esto se acaba aquí? No, no, no, nada de eso. Si quieres ver un HD-DVD necesitarás un tipo de conector que cifra los datos por el cable. Si tienes un LCD normalito y corriente con tu conexión DVI, como el que tenemos todos, Windows Vista te reducirá la resolución y empeorará la calidad del video.Lo repito despacito, porque sé que algunos no creen lo que acaban de oir: si tienes un LCD, un monitor normal y corriente, que tienen una conexión DVI que no “protege los contenidos”, Vista empeora a propósito la calidad de tu película HD-DVD/blueray adquirida de forma completamente legal. Te mostrará la imagen “ligeramente borrosa”, dicen los cachondos de Microsoft en la especificación. Y esto no ha hecho más que empezar: Ciertas técnicas utilizadas por VOIP podrían usarse para grabar. Asi que Vista degrada la calidad del sonido automáticamente para evitarlo. Toda aquella salida que sea “insegura” sera controlada para evitar copias ilegales. Se volverá a subir la calidad de sonido dinámicamente. Es decir, tu ordenador podrá disminuir la resolución, la calidad del sonido, del video, de repente, si detecta que existen salidas de datos no “protegidas”, volverá a restaurar la calidad si esa fuente desaparece, y todo esto se traducirá en cambios en la calidad del sonido, de la resolución, salidas que dejan de funcionar, sin que sepas explicarte por qué.
• En segundo lugar: ¿Que utilizaremos si no podemos utilizar hardware normal? Pues necesitaremos hardware específico con capacidades DRM. En vez de DVI, necesitaremos conectores HDMI con capacidades HDCP. HDCP es un invento que codifica los contenidos que viajan por el cable. La idea es que no puedas copiar el video conectandolo a nada raro, ni tan siquiera “esnifando” el contenido del cable. Oh, y es propiedad de Intel asi que el fabricante que lo fabrique - y tendrá que fabricarlo para poder mostrar HD-DVD - tendra que pagar una licencia. Costes añadidos para fabricantes de cables, monitores, tarjetas de video….costes que pagaremos nosotros.El hardware tambien tendrá que rediseñarse para poder permitir la reproducción de contenidos “seguros”. Por ejemplo, los planes de Microsoft - aun no están terminados - para un subsistema de sonido “seguro” implican que las tarjetas de sonido tendrán que codificar el sonido en el viaje a través de los buses internos (PCI, PCI-E, USB, etc) del ordenador. Para impedir….que hackeen el hardware y saquen el sonido. Y las gráficas tambien tendrán que codificar el video. Todo un programa.
• Pero los fabricantes no solo tendrán que hacer eso. Los dispositivos estarán forzados a detectar pequeñas variaciones de corriente anormales. Deberan cambiar ciertos bits cuando las detecten, y cuando Vista vea que esos bits han cambiado, desactivará las salidas o empeorará la calidad de la reproducción del contenido “protegido”. Todo esto implicará mayores costes en diseño, materiales, testeo, chips de cifrado, haciendo que el hardware sea más caro. A una persona normal podría no importarle comprar una tarjeta de sonido de baja calidad que tenga variaciones de corriente que generen imperfecciones en el sonido. Podría darse el caso de una tarjeta defectuosa que tiene fallos periódicos. Con Vista, no serán posibles esos dispositivos de bajo coste: Si los utilizan, los usuarios probablemente se pregunten por qué su ordenador nuevo hace cosas tan raras cuando meten un hd-dvd.
• En tercer lugar, debido a lo anterior, tu hardware podrá dejar de funcionar sin previo aviso. Todo lo dicho anteriormente requerirá que los fabricantes de hardware pasen ciertas pruebas para que Microsoft compruebe si sus dispositivos protegen los contenidos como dios manda. Necesitarán pasar estas pruebas para que Microsoft les firme los drivers y poder asi instalar los drivers en Vista. ¿Entendeis ahora la obsesión de Microsoft con que todos los drivers y cosas que funcionan en modo kernel estén firmadas? Si Microsoft detecta que un dispositivo tiene un fallo despues de haber pasado las pruebas, podrá revocar las firmas, probablemente a través de WU, o sabe dios.
• Por si todo esto no fuera suficiente, hay que tener en cuenta los costes del cifrado, en terminos de pérdida de rendimiento y sus consecuencias económicas. Por ejemplo, todos los contenidos que se envien a los dispositivos de video tendrán que estar cifrados con AES-128. A día de hoy las CPUs normales y corrientes no son capaces de cifrar con AES-128 y en tiempo real el ancho de banda utilizado en videos de calidad tipo HD-DVD, asi que habrá que añadir chips de cifrado adicionales - más costes. Y más espacio, que reducirá el espacio de silicona que se dedica a partes del chip que aumentan el rendimiento gráfico.Para asegurarse de que todo está bien, Windows Vista mirará cada 30 milisegundos los bits de los dispositivos citados anteriormente, para ver si han detectado variaciones de corriente o algo anómalo, y poder restringir el uso de los contenidos protegidos en consecuencia. Polling puro, duro y absurdo, por cierto. Por no mencionar los costes que tendrá en dispositivos portátiles debidos al continuo escaneo, que hace imposible desactivar ciertas partes de los chips para reducir el consumo.En la parte de software la cosa no pinta mejor. Muchos - sino son todos - de los subsistemas software de Windows relacionados con el DRM utilizan cifrado para proteger los contenidos. Tanto en espacio kernel como en espacio de usuario. Las comunicaciones kernel <-> espacio de usuario de componentes DRM tendrán que estar cifradas, y los componentes en espacio de usuario tambien cifrarán datos al compartirlos. Buena parte de ese cifrado se cargará a la CPU: Los fabricantes deberán montar CPUs más rápidas y caras para sustentar la pérdida de rendimiento. Se añaden un nuevo tipo de procesos: Procesos protegidos. Los procesos relacionados con mantener la seguridad de los contenidos serán de este tipo. Estos procesos no podrán ser depurados con depuradores, no se podrá volcar su memoria, no se podrán duplicar sus descriptores de archivos, no les podrá iniciar cualquiera, ni tan siquiera el administrador. Ni los antivirus podrán escanearlos, al menos desde espacio de usuario. Por cierto, para los aficionados a sistemas operativos: Si los crackers consiguen romper las protecciones y ejecutar virus con procesos de ese tipo, que no pueden ser escaneados por los antivirus, nos vamos a reir todos a carcajadas. Es un agujero esperando a ser roto y explotado, ahora o dentro de diez años.
• Resumiendo: Vista incluye un montón de cosas que los usuarios no han pedido. En un sistema de libre comercio y libertades individuales las empresas hacen lo que los usuarios piden. Ni tan siquiera tienes que estar en contra del DRM y Palladium para estar en contra de que una compañia decida apagarte tu salida S/PDIF. Imponer a los usuarios qué hacer, tal y como están haciendo Intel y Microsoft (y AMD, y…) tiene un nombre: Comunismo, imposición a la gente de lo que debe comprar (nota: entendiendo “comunismo” como esa cosa tan horrible que los Stalin de turno crearon en Rusia, no otras cosas). Para mas colmo se nos incrementa el coste del hardware por algo que no hemos pedido, y se pone el riesgo la plataforma PC. El PC tuvo éxito por la libertad que daba para escoger lo que uno quisiera. Con Vista, el hardware tendrá que cumplir unas normas de diseño, limitando el hardware que puedes comprar.

¿Estas dispuesto a pasar por el aro? Llegó el día, di adios a Microsoft.

IBM llega al final de la serie de artículos dedicados al framework CakePHP con esta entrega:

Generally, caching happens anytime a request is made, and the responding application says, “I don’t have to go get that. I’ve already got one.” Most of the time, when a computer user hears the word “cache,” he thinks of a browser’s cache. Typically, in order to speed up the user experience, your browser will keep copies of what it believes are static files — generally images, stylesheets, static HTML, and script files. While this type of caching can sometimes cause problems for developers of Web applications, this type of caching is not our focus here.

El link al artículo online, sin necesidad de registro.

Pues esto …

Wiiiiiiiiiii

En la base de datos MySQL existe una consulta que devuelve filas atendiendo a su relevancia. ¿Pero qué es relevancia? Es un número de coma flotante resultado de la aplicación de una serie de formulas. Conociendo la manera en la que estas formulas funcionan se pueden construir poderosas consultas que devuelvan resultados relevantes para los usuarios de nuestras aplicaciones.

En este artículo voy a comentar como se gestionan los índices FULLTEXT en la base de datos MySQL, versiones 4.1 o superior.

Primero crearemos una tabla de ejemplo:

Frases extraídas de The Field of Boliauns, un cuento clásico de la cultura Celta.

Algunas de las palabras se repiten varias veces. Otras palabras no formarán parte del indice FULLTEXT debido a que son muy cortas o demasiado frecuentes. Esta base de datos es lo suficientemente compleja para mostrar todos los trucos de las formulas de cálculo de relevancia.

myisam_ftdump

Para ver que es lo que se ha guardado en el indice FULLTEXT utilizaremos el programa myisam_ftdump. Viene con la distribución estándar de la base de datos.

Lo primerro es saber dónde se están guardando físicamente los datos de la tabla con una sentencia SHOW:

+---------------+-----------------------+
| Variable_name | Value                 |
+---------------+-----------------------+
| datadir       | /var/lib/mysql/        |
+---------------+-----------------------+

1 row in set (0.00 sec)

Otra sentencia SELECT para saber el nombre de la base de datos en la que me encuentro:

+------------+
| DATABASE() |
+------------+
| db1        |
+------------+

1 row in set (0.01 sec)

Todos estos datos son los que necesito para poder ejecutar myisam_ftdump. Veamos primero las opciones que tiene:

$> myisam_ftdump --help

Use: myisam_ftdump <table_name> <index_num>

  -d, --dump          Dump index (incl. data offsets and word weights).
  -s, --stats         Report global stats.
  -v, --verbose       Be verbose.
  -c, --count         Calculate per-word stats (counts and global weights).
  -l, --length        Report length distribution.
  -h, --help          Display help and exit.
  -?, --help          Synonym for -h.

Veamos que aspecto tiene el volcado del indice:

$> myisam_ftdump /var/lib/mysql/db1/quotes 0 -d
       ca            0.9775171 boliauns
       65            0.9666505 ceiling
      12f            0.9775171 gold
       65            0.9666505 knock
      12f            0.9775171 leprechaun's
        0            0.8148246 require
        0            0.8148246 socks
        0            1.3796179 special
        0            0.8148246 times
       65            0.9666505 times
       ca            0.9775171 weeds

Veamos ahora los pesos por palabra:

$> myisam_ftdump /var/lib/mysql/db1/quotes 0 -c
        1            1.0986123 boliauns
        1            1.0986123 ceiling
        1            1.0986123 gold
        1            1.0986123 knock
        1            1.0986123 leprechaun's
        1            1.0986123 require
        1            1.0986123 socks
        1            1.0986123 special
        2            0.0000000 times
        1            1.0986123 weeds

Claramente se observa que MySQL asocia números a términos, lo que nos queda por ver es qué significan esos números.

Las formulas

Hay tres formulas, y no son para nada complicadas

• peso_local = (log(dtf)+1)/sumdtf * U/(1+0.0115*U)
• peso_global = log((N-nf)/nf)
• peso_consulta = peso_local * peso_global * qf

Parámetros

• dtf el número de veces que el término aparece en la fila.
• sumdtf el sumatorio de (log(dtf)+1) para todos los términos de la misma fila.
• U el número de términos únicos que hay en la fila.
• N el número de filas que hay en la tabla.
• nf el número de filas que contienen el término.
• qf el número de veces que el término aparece en la consulta.

Por último log(n) hace referencia al logaritmo neperiano de n.

Tomemos por ejemplo la búsqueda de la palabra special sobre la primera fila de la tabla, que myisam_ftdump identifica como fila 0 (cero).

Para la primera formula: (log(dtf)+1)/sumdtf * U/(1+0.0115*U);

dft	special aparece dos veces en la fila 0, así que log(dtf()+1) = 0.6931472 + 1 = 1.6931472
sumdft	special aparece 2 veces en la fila 0, añadimos log(2)+1 times aparece 1 vez en la fila 0, añadimos log(1)+1 require aparece 1 vez en la fila 0, añadimos log(1)+1 socks aparece 1 vez en la fila 0, añadimos log(1)+1 el cálculo queda sumdtf = log(2)+1 + (log(1)+1)*3 = 4.6931472
U	Hay 4 términos únicos en la fila 0, por lo que U/(1+0.115*U) = 4/(1+0.0115*4) = 3.824092

peso_local = 1.6931472 / 4.6931472 * 3.824092 = 1.3796179. El mismo número que sale en el volcado del indice proporcionado por myisam_ftdump.

Para la segunda formula: log((N-nf)/nf);

N	Hay 4 filas en la tabla quotes
nf	El término special tiene ocurrencias en 1 fila.

peso_global = log((N-nf)/nf) = log(3) = 1.0986123. El mismo número que devuelve myisam_ftdump en el volcado de pesos por palabra.

Para la tercera fórmula: peso_consulta = peso_local * peso_global * qf;

peso_local	1.3796179
peso_global	1.0986123
qf	special aparece 1 vez en la consulta.

peso_consulta = 1.3796179 * 1.0986123 * 1 = 1.5156652. Finalmente esta es la relevancia de la consulta sobre la tabla de ejemplo.

Comprobemos el resultado con una consulta del tipo MATCH … AGAINST:

+-------------------------------------------+
| score |
+-------------------------------------------+
|                                 1.5156652 |
|                                 0.0000000 |
|                                 0.0000000 |
|                                 0.0000000 |
+-------------------------------------------+

4 rows in set (0.00 sec)

NOTA: MySQL devuelve un número con mayor resolución que mi calculadora casio, así que me ha tocado redondear a 7 decimales para que salgan los cálculos

La consulta devuelve una puntuación de 1.5156652 para la primera columna de la tabla, el mismo peso que sale de nuestros cálculos.

Explicación de la fórmula

Observad que el peso local depende de una constante que lo multiplica. Esta constante es un factor de corrección para tratar una alta frecuencia de términos dentro de la fila. Para aclararnos: si un término aparece muchas veces en una fila, el peso crece.

¿Por qué el peso local depende de las veces que el termino aparece en la fila? Piensa en este mismo artículo, los términos MySQL y FULLTEXT aparecen muchas veces. Esto es típico: si una serie de palabras aparecen muchas veces a la fuerza deben ser relevantes.

Observad que el peso global depende de la multiplicación de una inversa, el número de filas menos el número de filas en la que aparece el término. Para aclararnos: si un término aparece en muchas filas, el peso baja.

El peso global baja con la frecuencia de un término en todas las filas de la tabla, esto es así porque se considera un término común. Si una palabra aparece constantemente en todas las filas se convierte en un patrón de búsqueda inútil. Pensad en buscar cosas como artículos, pronombres, etc. son tan frecuentes que los resultados son inservibles.

Observad que el peso local, el peso global y el peso de la consulta es lo único que importa. MySQL no incrementará el peso si dos términos aparecen cerca uno de otro. MySQL tampoco entiende las raíces semánticas, los tiempos verbales ni los plurales, esto es, si buscas weed no te va a hacer los cálculos de relevancia para weeds.

La búsqueda utilizando grafos de proximidad y raíces semánticas (stemming) son algunas de las novedades que están preparando de cara a la versión 5.2 de MySQL. Quizá no tardemos mucho en disfrutar de ellas.

MySQL tiene muchas opciones, incluyendo IN BOOLEAN MODE donde las formulas de arriba se vuelven irrelevantes. El modo booleano básicamente realiza una búsqueda en el histograma de frecuencias de la tabla.

La lista stopword

Algunos términos — los artículos, conjunciones y pronombres son un buen ejemplo — tendrán un peso global igual a cero. MySQL no los indexará ni los tendrá en cuenta en las consultas. Es lo que se conoce como stopwords. MySQL maneja una lista de stopwords por defecto para el idioma inglés, que puede ocasionar más problemas de los que resuelve.

Por ejemplo, supongamos el texto:

Every word she writes is a lie, including “and” and “the”.
It depends on what the meaning of the word “is” is.

Es imposible buscar los términos and and the o is is porque son stopwords. Para devolver resultados deberíamos utilizar el operador LIKE, por ejemplo:

O bien, utilizar una frase de busqueda que no incluya un stopword, por ejemplo:

SELECT * FROM quotes WHERE MATCH(quote) AGAINST('including and and the');

Otro inconveniente es que los stopwords por defecto pueden ser palabras válidas en otros idiomas distintos del inglés. Por ejemplo Is es el nombre de un río ruso y the es la palabra francesa para referirse al té. Definitivamente parece que tenemos que cambiar la dichosa lista …

Hay listas de stopwords en la Universidad de Neuchatel provenientes del estudio de gramáticas y lenguajes del departamento de computación. Hay listas para los idiomas Finlandés, Francés, Alemán, Italiano, Ruso, Español y Sueco.

Para decirle a MySQL que utilice nuestra lista hay que levantar la base de datos con el siguiente parámetro:

#> mysqld --ft_stopword_file=stopword.txt

Podemos comprobar la lista que esta utilizando con una consulta SHOW:

+------------------+--------------+
| Variable_name    | Value        |
+------------------+--------------+
| ft_stopword_file | stopword.txt |
+------------------+--------------+

1 row in set (0.00 sec)

Algunos trucos

Debido a que la formula final depende del parámetro qf (la frecuencia de un término en la consulta), se puede otorgar un peso extra a un término tan sólo con ponerlo varias veces dentro de la consulta. Si preguntamos a la base de datos por special special en lugar de por special veremos como la relevancia cambia.

Suele ayudar bastante añadir una columna con los términos que uno considere relevantes y asignarle un indice FULLTEXT. Es una idea similar a la folcsonomía (ordenación por etiquetas o tags) que tan de moda está en estos días. Los keywords seleccionados otorgarán un mayor peso a la fila.

En ocasiones las consultas devuelven resultados muy extraños, ejecuta myisam_ftdump. Quizá no te salvará el culo pero los resultados te pueden ayudar a mejorar las estrategias de búsqueda la próxima vez.

Actualmente InnoDB no tiene soporte para los indices FULLEXT: deberás elegir entre tablas con indice FULLEXT o tablas con integridad referencial. Al menos hasta la próxima versión 5.2, dónde está previsto que todos los motores de datos de MySQL respeten la integridad referencial.

Los lenguajes ideográficos como el Chino, el Japonés y el Indú carecen de delimitadores entre palabras, escriben todo seguido sin espacios. Esto representa un impedimento enorme en el estudio de todo lo que se ha comentado en el articulo, por esa razón no hay soporte FULLEXT en estos idiomas.

Existe un motor de datos para MySQL que incorpora muchas más funcionalidades en el campo de las búsquedas FULLEXT, entre ellas el soporte para lenguajes ideográficos, grafos de proximidad y stemming. Actualmente está en intensivo desarrollo y no hay paquetes para instalarlo fácilmente: Sphinx.

Espero que este artículo os ayude a mejorar la precisión de vuestras búsquedas y se traduzca en mejores aplicaciones para los usuarios.

IBM publica otra entrega del curso sobre CakePHP:

There are multiple ways of saving session data using CakePHP’s Session component, and each method has its advantages. In this tutorial, you’ll learn how to use the Session component by incorporating all three ways into your application, so you’ll be able to pick the best one that works for you. You’ll also learn how to use the Request Handler component to aid you in your handling of various HTTP requests, including requests from mobile browsers, or requests containing XML or HTML content.

Versión online o versión PDF, a gusto del consumidor.

Happy baking!!

Mañana saldrá el tipo de los Macintosh™ al escenario y anunciará la disponibilidad de MacOS X “Leopard” para PCs compatibles, compitiendo directamente con Vista. Segundos después una mesa de despacho saldrá volando por la ventana del edificio de Microsoft, a lo lejos se presupone la silueta de Hullk-Ballmer.

Afirmaciones totalmente gratuitas fuertemente fundadas después de leer En el principio… fue la linea de comandos.

Sistemas de control de versiones hay muchos y muy variados: CVS, Subversion, Darcs, StarTeam, etc. Son herramientas muy valiosas, tanto que ningún programador puede omitirlas. En la siguiente nota voy a comentar algunos hábitos que he observado en la gente que las utiliza:

No utilices el control de versiones como si fuera un backup

Este es uno de los mayores errores a la hora de utilizar estas herramientas. Frecuentemente oigo la frase: ¿has puesto a salvo tu código en el repositorio?. ¡Mal! Almacenar el código en un repositorio no es sinónimo de seguridad, la seguridad la proporciona una copia de respaldo de ese código, no el repositorio en sí.

Tomaremos como ejemplo Darcs, un sistema de control de versiones no muy conocido. Este soft funciona en local, como un proceso más, sin necesidad de centralizar el control en un servidor como ocurre con otros sistemas como CVS o Subversion. En este caso, un fallo de disco podría echar a perder tu trabajo; por esta razón debes hacer copias de seguridad, el sistema de control de versiones no tiene nada que hacer ante este tipo de contingentes.

Los desarrolladores que utilizan el control de versiones con el rol de sistema de backup frecuentemente hacen un commit de su trabajo al día, por ejemplo cuando termina su jornada laboral, como una forma de respaldo diario. Esta no es una práctica aceptable, especialmente si formas parte de un equipo de desarrollo. Imagina que sólo actualizas tu proyecto por la mañana, cuando empieza tu jornada, y remites los cambios al finalizarla. Cada mañana perderás mucho tiempo únicamente lidiando con todos los cambios que enviaron tus compañeros el día anterior y que entran en conflicto con los que tu hiciste. No es una práctica muy inteligente, ¿no crees?

Remite los cambios tan pronto como conformen una unidad lógica

¿Cada cuanto debo remitir los cambios?. Hay que llegar a un término medio: no remitas cada línea que escribes ni lo hagas después de todo el día trabajando. Debes hacer un commit tan pronto como los cambios conformen una unidad lógica, por ejemplo cada vez que un conjunto de cambios tengan sentido.

Estas unidades lógicas responden en la mayoría de los casos a tu plan de desarrollo: encuentras un bug en la rama de desarrollo actual, planeas una estrategia para solucionarlo, lo arreglas y ahí tienes tu unidad lógica: envía los cambios al repositorio. El commit cobra sentido porque soluciona un bug específico; la versión X tiene un bug y la versión X+1 ya no.

No tengas miedo de remitir pequeños cambios con mucha frecuencia, nadie se enfadará porque seas conciso solucionando cosas pequeñas. Considera la situación extrema en la que, después de meses de desarrollo, necesitas recordar cual fue la revisión en la que se solucionó aquella falta de ortografía en una cadena de depuración. Si utilizaste correctamente el patrón de “una solución, un envío” no tienes más que investigar la lista de envíos para descubrir cual de ellos estas buscando.

Frecuentemente ocurre que estas trabajando en una “unidad lógica” cuando descubres que hay un error en otra parte del código y lo corriges, y envías la corrección junto con tus cambios todo dentro de un mismo commit haciendo que esta corrección pierda visibilidad. Esto debe evitarse en la medida de lo posible.

Se preciso y exhaustivo en los comentarios

Una de las cosas que más me enerva son los commit en blanco. Cada envío al repositorio debe ir asociado obligatoriamente con un comentario que explique lo que se hizo. Si trabajas en un equipo de desarrollo, tus compañeros se verán frustrados y te desearán una muerte dolorosa cada vez que actualicen el proyecto y se encuentren con docenas de cambios “en blanco” ¿Qué demonios hizo este tio? Si trabajas solo, tarde o temprano te encontrarás buceando entre una interminable lista de cambios en blanco y te desearás una dolorosa muerte por no haber documentado apropiadamente tu propio trabajo.

Por favor sé preciso y explica con detalle cada una de las cosas que haces. En el caso óptimo podrás localizar lo que buscas tan solo mirando la lista de cambios.

Nunca rompas trunk

Si remites cambios en blanco desearé tu muerte, pero si rompes la rama principal !pondré medios para asegurarme que mueras!. Romper la rama principal de desarrollo es la manera más simple y directa de joder a todo el equipo de desarrollo desde la comodidad de tu cubículo.

Si alguien envía un parche que rompe la rama y yo actualizo, automáticamente mi copia de proyecto se rompe y me quedo sin poder trabajar hasta que la persona que remitió el parche no lo solucione. La idea es: verifica siempre tus cambios antes de enviarlos al repositorio.

Otra cosa muy habitual es realizar varios cambios, crear nuevos ficheros, comprobar que todo funciona bien antes de enviar, pero olvidar ¡incluir los nuevos archivos bajo el control de versiones!

Y el señor dijo a los hombres:
“Aquel que actualice el repositorio rompiendo la compilación deberá pagar una penitencia en donuts”
Esa es la ley.