Pintar "muñecajos" no ha vuelto a ser lo mismo después de ver esta tira.
PD: Muchas gracias a nuestras madres/novias/mujeres -táchese lo que no proceda- por aguantarnos. A todas ellas un beso.
lunes, 14 de julio de 2008
Miniaturas
Estoy pensando en escribir una entrada sobre unas miniaturas pintadas por un amigo y el "concurso" -o competición, o pique- en el que se enmarcan, y he recordado esta maravillosa tira de Dork Tower -que dejó de estar traducida hace bastante-.
Pintar "muñecajos" no ha vuelto a ser lo mismo después de ver esta tira.
PD: Muchas gracias a nuestras madres/novias/mujeres -táchese lo que no proceda- por aguantarnos. A todas ellas un beso.
Pintar "muñecajos" no ha vuelto a ser lo mismo después de ver esta tira.
PD: Muchas gracias a nuestras madres/novias/mujeres -táchese lo que no proceda- por aguantarnos. A todas ellas un beso.
jueves, 10 de julio de 2008
Reseñas varias
Hace bastante que no pongo las reseñas de los últimos libros que me he leído. Y no ha sido por falta de lectura, sino por falta de un rato -y ganas- para escribir la entrada. Para ponerme al día, he decidido recopilarlos en esta a modo de resumen y para que no se me olviden.
"Las corrientes del espacio" y "En la arena estelar" -Isaac Asimov-. Siguiendo con el viaje hacia La Fundación. Realmente estos dos junto con un tercero fueron editados en el mismo libro con el nombre de Tríptico del Imperio. Bajo mi punto de vista flojillos, como se puede deducir por el hecho de que dejé el tercero para más adelante.
"Tormenta de espadas" - George R.R. Martin-. Se trata del tercer libro de la colección "Canción de hielo y fuego" y bajo mi punto de vista es de lo mejor que se ha escrito en mucho tiempo. La historia transcurre en la época Medieval de un mundo inventado y donde no falta de nada: Política, combates, amoríos, emoción, más política y algo de magia pero poca. Dicen que la historia está basada en la "Guerra de las Dos Rosas" en Inglaterra.
En cuanto al argumento... es mejor que no diga nada, ya que cualquier cosa que diga puede estropear la sorpresa de lo que pasa. Especialmente por las propias palabras del autor, quién ya advirtió a sus lectores que no se encariñasen con ningún personaje, puesto que cualquiera puede morir si el guión lo exige. Quién haya leído el primer libro -y este es ya el tercero- sabe que lo dice en serio.
"Festín de Cuervos" -George R.R. Martin-. La cuarta entrega de "Juego de tronos" como también se le conoce. No puede más que ir a comprarlo -y leerlo- según terminé el tercero. Por los mismos motivos del anterior no diré nada ya que es muy fácil meter la pata, salvo que está escrito de una forma muy peculiar... y que deja con unas ganas inmensas de leer el siguiente, que desgraciadamente todavía no está a la venta.
"Historia de una Escalera" y "Las Meninas" -Buero Vallejo-. Se trata de dos breves obras de teatro de este escritor alcarreño. En Guadalajara -España- hay varios lugares que llevan su nombre, y como quiera que llevo unos años viviendo aquí tenía en pendientes leer algo suyo. La verdad: me han gustado, así que buscaré algo más.
"Las corrientes del espacio" y "En la arena estelar" -Isaac Asimov-. Siguiendo con el viaje hacia La Fundación. Realmente estos dos junto con un tercero fueron editados en el mismo libro con el nombre de Tríptico del Imperio. Bajo mi punto de vista flojillos, como se puede deducir por el hecho de que dejé el tercero para más adelante.
"Tormenta de espadas" - George R.R. Martin-. Se trata del tercer libro de la colección "Canción de hielo y fuego" y bajo mi punto de vista es de lo mejor que se ha escrito en mucho tiempo. La historia transcurre en la época Medieval de un mundo inventado y donde no falta de nada: Política, combates, amoríos, emoción, más política y algo de magia pero poca. Dicen que la historia está basada en la "Guerra de las Dos Rosas" en Inglaterra.
En cuanto al argumento... es mejor que no diga nada, ya que cualquier cosa que diga puede estropear la sorpresa de lo que pasa. Especialmente por las propias palabras del autor, quién ya advirtió a sus lectores que no se encariñasen con ningún personaje, puesto que cualquiera puede morir si el guión lo exige. Quién haya leído el primer libro -y este es ya el tercero- sabe que lo dice en serio.
"Festín de Cuervos" -George R.R. Martin-. La cuarta entrega de "Juego de tronos" como también se le conoce. No puede más que ir a comprarlo -y leerlo- según terminé el tercero. Por los mismos motivos del anterior no diré nada ya que es muy fácil meter la pata, salvo que está escrito de una forma muy peculiar... y que deja con unas ganas inmensas de leer el siguiente, que desgraciadamente todavía no está a la venta.
"Historia de una Escalera" y "Las Meninas" -Buero Vallejo-. Se trata de dos breves obras de teatro de este escritor alcarreño. En Guadalajara -España- hay varios lugares que llevan su nombre, y como quiera que llevo unos años viviendo aquí tenía en pendientes leer algo suyo. La verdad: me han gustado, así que buscaré algo más.
martes, 17 de junio de 2008
Educación (y 2)
Lo siguiente no es mío. Me lo pasó este buen amigo que es Rafa, y no puedo mas que publicarlo aquí, a modo de continuación del artículo previo. Dice así:
Un famoso médico ingles comenzó una conferencia sobre conflictos generacionales citando cuatro frases:
1). 'Nuestra juventud gusta del lujo y es mal educada, no hace caso a las autoridades y no tiene el menor respeto por los de mayor edad. Nuestros hijos hoy son unos verdaderos tiranos. Ellos no se ponen de pie cuando una persona anciana entra. Responden a sus padres y son simplemente malos'.
2). 'Ya no tengo ninguna esperanza en el futuro de nuestro país si la juventud de hoy toma mañana el poder, porque esa juventud es insoportable, desenfrenada, simplemente horrible.'
3). 'Nuestro mundo llegó a su punto crítico. Los hijos ya no escuchan a sus padres. El fin del mundo no puede estar muy lejos.
4). 'Esta juventud esta malograda hasta el fondo del corazón. Los jóvenes son malhechores y ociosos. Ellos jamás serán como la juventud de antes. La juventud de hoy no será capaz de mantener nuestra cultura'
Después de estas cuatro citas, quedó muy satisfecho con la aprobación que los asistentes a la conferencia daban a cada una de las frases dichas.
Entonces, reveló el origen de las frases mencionadas:
La primera es de Sócrates (470-399 A.C )
La segunda es de Hesíodo (720 a.C.)
La tercera es de un sacerdote egipcio del año 2.000 a.C.
La cuarta estaba escrita en un vaso de arcilla descubierto en las ruinas de Babilonia y con más de 4.000 años de existencia.
Padres y Madres de familia: RELAJAOS PUES SIEMPRE FUE ASÍ...
miércoles, 11 de junio de 2008
Buenas prácticas de programación
Por lo visto, este consejo figura en la primera posición de manual de "buenas prácticas" de PERL -para quién no lo sepa, se trata de un lenguaje de programación-:
"Siempre programa como si la persona que acabe manteniendo tu código sea un violento psicópata que sabe dónde vives"
La verdad, me ha parecido buenísimo, y no sólo por lo gracioso que me resulta. Y es que a veces nuestro trabajo sería un poco más fácil si todos tuviésemos esto en la cabeza cuando estamos tirando líneas de código.
Por cierto, lo he visto en este enlace de barrapunto, puesto por alguien que firma como "explorer".
"Siempre programa como si la persona que acabe manteniendo tu código sea un violento psicópata que sabe dónde vives"
La verdad, me ha parecido buenísimo, y no sólo por lo gracioso que me resulta. Y es que a veces nuestro trabajo sería un poco más fácil si todos tuviésemos esto en la cabeza cuando estamos tirando líneas de código.
Por cierto, lo he visto en este enlace de barrapunto, puesto por alguien que firma como "explorer".
miércoles, 4 de junio de 2008
Educación
Es bien sabido por todos los que me conocen de mi afición a Arturo Pérez-Reverte y todo lo que escribe. A veces estoy muy de acuerdo con él y a veces menos de acuerdo. A primeros de año llegó a mis manos un enlace a un artículo en el que se despachaba bien a gusto. El envío a los amigos, especialmente a uno que es maestro -un abrazo Rafa, uno de mis tres lectores- fue obligado, y desde entonces le debo esta entrada.
Porque mi reacción primitiva -en los dos sentidos de la palabra- fue la de aplaudir ese artículo, porque no hay más que ver la juventud que tenemos -falta absoluta de respeto, botellón, fines de semana que empiezan los jueves-, que vamos como vamos -aprobados sin esfuerzo ni septiembre, analfabetismo funcional galopante- y todas esas frases facilonas que sabemos y utilizamos todos.
Pero tuvimos unas cuantas conversaciones -nosotros no discutimos- más que interesantes, en las que me hizo ver otro punto de vista. Un punto de vista que se resume en un cambio de la concepción de la enseñanza, de un sistema autoritario a otro participativo -lo siento, a mi lo de "democrático" no me encaja-.
Y la verdad es que puede que tenga razón. Puede que tengamos que abrir la mente, y aceptar que las cosas cambian. Y también tiene razón cuando dice que hay que conocer el sistema antes de criticarlo. O mejor dicho: para poder criticarlo.
Así que ni vamos tan mal -el informe Pisa 2006 lo deja muy claro, aunque cada uno interpreta lo que le interesa-, ni la juventud está tan perdida, ni el fin de los tiempos educativos está cerca. Sigo teniendo mis puntos de vista, y sigo sin estar de acuerdo con algunas de las cosas que él defiende, pero estoy con él en que el sistema no es peor que el antiguo con el que nos criamos.
Además, he añadido una frase que dijo a mi propio repertorio: "Cualquier tiempo, pasado, fue mejor". Las comas están puestas con toda la intención, y es que muchas veces algo nos parece bueno sólo porque ya no lo tenemos que sufrir –la memoria es caprichosa-.
Porque mi reacción primitiva -en los dos sentidos de la palabra- fue la de aplaudir ese artículo, porque no hay más que ver la juventud que tenemos -falta absoluta de respeto, botellón, fines de semana que empiezan los jueves-, que vamos como vamos -aprobados sin esfuerzo ni septiembre, analfabetismo funcional galopante- y todas esas frases facilonas que sabemos y utilizamos todos.
Pero tuvimos unas cuantas conversaciones -nosotros no discutimos- más que interesantes, en las que me hizo ver otro punto de vista. Un punto de vista que se resume en un cambio de la concepción de la enseñanza, de un sistema autoritario a otro participativo -lo siento, a mi lo de "democrático" no me encaja-.
Y la verdad es que puede que tenga razón. Puede que tengamos que abrir la mente, y aceptar que las cosas cambian. Y también tiene razón cuando dice que hay que conocer el sistema antes de criticarlo. O mejor dicho: para poder criticarlo.
Así que ni vamos tan mal -el informe Pisa 2006 lo deja muy claro, aunque cada uno interpreta lo que le interesa-, ni la juventud está tan perdida, ni el fin de los tiempos educativos está cerca. Sigo teniendo mis puntos de vista, y sigo sin estar de acuerdo con algunas de las cosas que él defiende, pero estoy con él en que el sistema no es peor que el antiguo con el que nos criamos.
Además, he añadido una frase que dijo a mi propio repertorio: "Cualquier tiempo, pasado, fue mejor". Las comas están puestas con toda la intención, y es que muchas veces algo nos parece bueno sólo porque ya no lo tenemos que sufrir –la memoria es caprichosa-.
jueves, 15 de mayo de 2008
SourceSafe: Control de versiones
1. Introducción
En el desarrollo de aplicaciones es importante (casi diría imprescindible) llevar un control de los cambios en el código fuente, especialmente cuando en dicho desarrollo intervienen varias personas. Para esta función tenemos varios programas (TeamSource de Borland, Git para Linux o SourceSafe de Microsoft).
Además, con bastante frecuencia necesitaremos tener los fuentes según estaban en un momento concreto del tiempo, con el objetivo que modificar algún error en la misma. Por ejemplo, el código fuente que corresponde a la versión de la aplicación que está desplegada en producción, ya que, como es evidente, no nos sirve la última versión del código fuente, puesto que ésta puede tener cambios que todavía no están preparados para pasar a producción.
En este documento vamos a definir los principales pasos para llevar un control del código fuente utilizando Microsoft SourceSafe 6.0, así como la gestión de las distintas versiones de un proyecto. No obstante, este documento no pretende suplantar la ayuda en línea en MSDN (muy completa en este caso):
2. Proceso de gestión de versiones
A lo largo del presente documento vamos a suponer un caso real, que va a ir evolucionando y en el que vamos a ir aplicando las secciones que mostramos.
Además, para los ejemplos concretos utilizaremos un proyecto en Microsoft Visual Studio 2005, aunque todas las acciones a llevar a cabo las realizaremos directamente en SourceSafe, con lo que no es en absoluto necesaria dicha herramienta.
2.1. Etiquetas (Flags)
Una vez el desarrollo de la aplicación alcanza un objetivo, llega el momento de poner una marca al código fuente indicando esta situación, especialmente con la idea de tener la posibilidad de volver a este punto del desarrollo en el futuro. Para ello se utilizan las “Etiquetas” o “Flags”, tal y como se puede observar en la imagen:
Aquí nos saldrá una ventana en la que nos pide un nombre para esta Etiqueta (hasta 31 caracteres), así como una descripción de la misma. Es mejor no ser demasiado críptico con el nombre ni demasiado rácano con la descripción, ya que cuando lo tengamos que utilizar en el futuro es mejor no tener que especular sobre qué queríamos decir semanas (o meses) antes.
De esta forma SourceSafe pone la etiqueta en la versión actual a todos los archivos que forman parte de la solución.
En nuestro ejemplo, vamos a suponer que los fuentes han alcanzado un grado de madurez suficiente como para liberar la versión 1.0 de nuestra aplicación, con lo que en el nombre de la etiqueta vamos a poner “v1.0”, y en la descripción algo como “Primera versión estable en producción”. Nótese que la etiqueta se la ponemos a todo el proyecto.
2.2. Mostrar Historial (Show History)
Desde SourceSafe siempre tenemos la opción de ver el historial de un elemento (proyecto, carpeta o simple archivo). Al hacerlo, ya sea desde el botón derecho o desde el menú Archivo, tendremos una imagen que se parecerá a esta (imagen tomada marcando la opción de “Recursivo” para que muestre el histórico de todas las carpetas que contiene el proyecto):
Desde este momento empezamos a modificar el proyecto con nuevas funcionalidades y correcciones con el objetivo de ir preparando una nueva versión del mismo. Así, el histórico pasa a mostrar este estado de los archivos del proyecto:
.PNG)
Es en este momento cuando detectamos (realmente nos lo detectan) un error en el programa que tenemos en producción, y que tiene que ser corregida inmediatamente. La versión que hay en producción es la v1.0, pero nuestros archivos con el código fuente ya han sufrido algunas modificaciones, lo que hace que no las podamos utilizar para corregir este error porque incluiríamos cambios que todavía no están aprobados.
2.3. Compartir (Share)
Con la acción de Compartir creamos una copia de los archivos del proyecto a partir de un momento dado. En nuestro caso, lo que necesitamos es modificar el código fuente según estaba en el momento de la versión 1.0, con lo que buscamos en el histórico esta Etiqueta (podemos seleccionar “Mostrar sólo etiquetas” en la ventana de búsqueda para simplificar la selección):
En la siguiente pantalla nos da la opción de indicar desde dónde compartimos (“Compartir desde …” en español o “Share from …” en inglés), pero lo de opción no es muy correcto. En la práctica hay que pegarle al raíz (root) del proyecto. Es importante que no esté marcada la casilla de “Bifurcar después de compartir” (“Branch alter share”).
.PNG)
A continuación nos pide un nombre, y en honor a la originalidad de ponemos “PruebaVersiones v1.1”. Nuevamente, es importante que esté marcada la casilla de “Recursivo” para no dejarnos los subproyectos que pueda tener.
Este proyecto compartido no tiene definido ningún directorio de trabajo, así que podemos pasar a indicárselo. Es recomendable nombrar el directorio de una forma suficientemente clara para evitar confusiones. En este caso vamos a crear un nuevo directorio de trabajo (Working Folder) llamado igual al nombre compartido: “PruebaVersiones v1.1”, aunque podríamos ponerle cualquier otro. Una vez hecho esto nos traemos la última versión de la forma habitual (marcando “Recursivo” y “Construir árbol de directorios”).
De esta forma ya tenemos los archivos tal y como estaban en el momento en el que le pusimos la etiqueta de v1.0, sin los cambios posteriores. Sin embargo esto no es una copia, sino que SourceSafe sigue controlando internamente las diferentes acciones en los archivos. Para empezar, el hecho de “Compartir” hace que todos los archivos creados como v1.1 estén “Fijados”, es decir, están marcados de tal forma que no nos permite ninguna modificación en los mismos.
2.4. Bifurcar (Branch)
El siguiente paso es quitar la fijación (desfijar suena demasiado mal) de los archivos que necesitan ser modificados para corregir los errores encontrados en producción. Para ello utilizamos la opción de bifurcarlos en lugar de simplemente quitarles esa fijación (me estoy dando cuenta que esto tampoco suena muy bien).
La diferencia entre “Desfijar” (“Unpin”) y “Bifurcar” (“Branch”) es que el segundo permite volver a combinar los cambios con la versión inicial de una forma automática, mientras que el primero no. Por lo tanto, aplicamos la bifurcación al archivo que tenemos que modificar, esta vez desde el menú “Versiones -> Bifurcar” teniendo seleccionado el archivo deseado (yo tampoco entiendo porqué no está la opción en el menú contextual o “de botón derecho”).
Una vez hecho ya podemos hacer las modificaciones necesarias en dicho archivo. Generar nuevamente el proyecto, probarlo, instalarlo en producción y cualquier cosa que queramos o necesitemos según nuestra metodología de trabajo (si tenemos).
Después de realizadas las modificaciones para la versión 1.0, es posible que queramos incluirlas también en la versión actual del proyecto. Recordemos: esa que está en plena fase de desarrollo con el objetivo de lanzar la versión 2.0. Esto lo podemos hacer de forma manual en el código fuente actual, pero también puede que queramos, sin encomendarnos a nadie, que sea el propio SourceSafe de forma automática.
2.5. Combinar versiones bifurcadas (Merge Branches)
Esta es la forma en la que SourceSafe incluye los cambios de una versión de un archivo en otra. Para ello se selecciona el archivo en el que queremos incluir las modificaciones hechas, a través del menú “Versiones -> Combinar versiones” (ésta opción tampoco está en el menú contextual; las preguntas a Microsoft):
Insisto: “en el archivo en el que queremos incluir las modificaciones”. Es decir, si nuestra intención es incluir en el archivo de desarrollo actual (próximo a la versión 2.0) los cambios hechos en la versión antigua (etiquetada como v1.1) es el archivo actual el que debemos tener seleccionado al pulsar esta opción.
A continuación nos aparece una ventana en la que tenemos que elegir con qué archivo lo queremos combinar. Lo normal es que elijamos el mismo archivo de la versión v1.1. Por suerte, SourceSafe está atento y sólo nos habilita el botón de Combinar (Merge) cuando hemos seleccionado un archivo válido.
.PNG)
El ojo hábil habrá notado que he cambiado el fichero de la prueba (antes Class1.cs, ahora Form1.cs). El motivo es que el previo ha sufrido demasiadas pruebas y la pantalla de ejemplo no iba a ser nada clara.
Cabe la posibilidad de que tengamos conflictos en este proceso, principalmente cuando la misma línea ha sido modificada en ambas versiones. En estos casos nos saldrá una ventana en la que tendremos que indicar qué líneas tienen que ser incluidas en la versión. Esta elección se realiza de una forma visual y totalmente intuitiva, “pinchando” el cambio que queremos incluir (se pueden incluir ambos). Francamente, me ha sorprendido (para bien):
.PNG)
Con esto ya tenemos los cambios tanto en el parche para salir del paso en producción (versión 1.1) como en la versión del código fuente en desarrollo. Sólo nos queda volver a “Fijar” los archivos modificados.
2.6. Fijar (Pin)
Una vez que hemos terminado de hacer los cambios, lo ideal es volver a “Fijar” los archivos de la versión v1.1. ¿Para qué? Para evitar que en un descuido volvamos a modificar esta versión y olvidemos propagar el cambio a la última versión del código fuente.
Desde mi punto de vista (que es personal e intransferible) es preferible que para volver a hacer una modificación sobre esta versión “del parche”, tengamos que repetir los pasos de “Bifurcación” y “Combinación”.
Para fijar manualmente una versión de un archivo (la vez anterior se fijó de forma automática al compartirla) abrimos su histórico y pulsamos en el botón Fijar (Pin):
3. Conclusión
Los sistemas de control de versiones (SCV) como Microsoft SourceSafe son muy útiles, abarcando una amplia gama de funciones desde el simple sistema de copia de seguridad del código fuente, hasta tareas mucho más complejas como gestión de Ramas (Bifurcaciones o Branches) como la que se ha apuntado ligeramente en este documento.
La utilización de estos SCV se vuelve imprescindible cuando la complejidad de los programas crece, tanto por su tamaño como por las personas involucradas en su desarrollo.
Independientemente de (o además de) estos motivos, es una buena idea mantener los saludables hábitos de su (correcta) utilización para evitar sustos y disgustos cuando la vida real se cruza con la bonita teoría del diseño y desarrollo de aplicaciones.
4. Enlaces
Como dijimos al principio, todo lo nombrado en este documento está mucho mejor explicado en la página de la ayuda de MSDN de Microsoft SourceSafe:
http://msdn2.microsoft.com/es-es/library/ms181038(VS.80).aspx
Sin embargo, no es ni mucho menos el primero ni el único programa con este fin. Un buen punto por donde empezar a conocer algún otro es Git: el programa utilizado actualmente para controlar las distintas versiones de kernel de Linux:
http://git.or.cz/
Mucha más información en la Wikipedia:
http://es.wikipedia.org/wiki/Control_de_versiones (español)
http://en.wikipedia.org/wiki/Version_control_system (inglés)
5. Agradecimientos
Este documento ha sido redactado para uso interno de mi departamento en mi trabajo y está publicado aquí con el conocimiento y la aprobación de mis jefes. Pues eso.
En el desarrollo de aplicaciones es importante (casi diría imprescindible) llevar un control de los cambios en el código fuente, especialmente cuando en dicho desarrollo intervienen varias personas. Para esta función tenemos varios programas (TeamSource de Borland, Git para Linux o SourceSafe de Microsoft).
Además, con bastante frecuencia necesitaremos tener los fuentes según estaban en un momento concreto del tiempo, con el objetivo que modificar algún error en la misma. Por ejemplo, el código fuente que corresponde a la versión de la aplicación que está desplegada en producción, ya que, como es evidente, no nos sirve la última versión del código fuente, puesto que ésta puede tener cambios que todavía no están preparados para pasar a producción.
En este documento vamos a definir los principales pasos para llevar un control del código fuente utilizando Microsoft SourceSafe 6.0, así como la gestión de las distintas versiones de un proyecto. No obstante, este documento no pretende suplantar la ayuda en línea en MSDN (muy completa en este caso):
2. Proceso de gestión de versiones
A lo largo del presente documento vamos a suponer un caso real, que va a ir evolucionando y en el que vamos a ir aplicando las secciones que mostramos.
Además, para los ejemplos concretos utilizaremos un proyecto en Microsoft Visual Studio 2005, aunque todas las acciones a llevar a cabo las realizaremos directamente en SourceSafe, con lo que no es en absoluto necesaria dicha herramienta.
2.1. Etiquetas (Flags)
Una vez el desarrollo de la aplicación alcanza un objetivo, llega el momento de poner una marca al código fuente indicando esta situación, especialmente con la idea de tener la posibilidad de volver a este punto del desarrollo en el futuro. Para ello se utilizan las “Etiquetas” o “Flags”, tal y como se puede observar en la imagen:
Aquí nos saldrá una ventana en la que nos pide un nombre para esta Etiqueta (hasta 31 caracteres), así como una descripción de la misma. Es mejor no ser demasiado críptico con el nombre ni demasiado rácano con la descripción, ya que cuando lo tengamos que utilizar en el futuro es mejor no tener que especular sobre qué queríamos decir semanas (o meses) antes.
De esta forma SourceSafe pone la etiqueta en la versión actual a todos los archivos que forman parte de la solución.
En nuestro ejemplo, vamos a suponer que los fuentes han alcanzado un grado de madurez suficiente como para liberar la versión 1.0 de nuestra aplicación, con lo que en el nombre de la etiqueta vamos a poner “v1.0”, y en la descripción algo como “Primera versión estable en producción”. Nótese que la etiqueta se la ponemos a todo el proyecto.
2.2. Mostrar Historial (Show History)
Desde SourceSafe siempre tenemos la opción de ver el historial de un elemento (proyecto, carpeta o simple archivo). Al hacerlo, ya sea desde el botón derecho o desde el menú Archivo, tendremos una imagen que se parecerá a esta (imagen tomada marcando la opción de “Recursivo” para que muestre el histórico de todas las carpetas que contiene el proyecto):
Desde este momento empezamos a modificar el proyecto con nuevas funcionalidades y correcciones con el objetivo de ir preparando una nueva versión del mismo. Así, el histórico pasa a mostrar este estado de los archivos del proyecto:
.PNG)
Es en este momento cuando detectamos (realmente nos lo detectan) un error en el programa que tenemos en producción, y que tiene que ser corregida inmediatamente. La versión que hay en producción es la v1.0, pero nuestros archivos con el código fuente ya han sufrido algunas modificaciones, lo que hace que no las podamos utilizar para corregir este error porque incluiríamos cambios que todavía no están aprobados.
2.3. Compartir (Share)
Con la acción de Compartir creamos una copia de los archivos del proyecto a partir de un momento dado. En nuestro caso, lo que necesitamos es modificar el código fuente según estaba en el momento de la versión 1.0, con lo que buscamos en el histórico esta Etiqueta (podemos seleccionar “Mostrar sólo etiquetas” en la ventana de búsqueda para simplificar la selección):
En la siguiente pantalla nos da la opción de indicar desde dónde compartimos (“Compartir desde …” en español o “Share from …” en inglés), pero lo de opción no es muy correcto. En la práctica hay que pegarle al raíz (root) del proyecto. Es importante que no esté marcada la casilla de “Bifurcar después de compartir” (“Branch alter share”).
.PNG)
A continuación nos pide un nombre, y en honor a la originalidad de ponemos “PruebaVersiones v1.1”. Nuevamente, es importante que esté marcada la casilla de “Recursivo” para no dejarnos los subproyectos que pueda tener.
Este proyecto compartido no tiene definido ningún directorio de trabajo, así que podemos pasar a indicárselo. Es recomendable nombrar el directorio de una forma suficientemente clara para evitar confusiones. En este caso vamos a crear un nuevo directorio de trabajo (Working Folder) llamado igual al nombre compartido: “PruebaVersiones v1.1”, aunque podríamos ponerle cualquier otro. Una vez hecho esto nos traemos la última versión de la forma habitual (marcando “Recursivo” y “Construir árbol de directorios”).
De esta forma ya tenemos los archivos tal y como estaban en el momento en el que le pusimos la etiqueta de v1.0, sin los cambios posteriores. Sin embargo esto no es una copia, sino que SourceSafe sigue controlando internamente las diferentes acciones en los archivos. Para empezar, el hecho de “Compartir” hace que todos los archivos creados como v1.1 estén “Fijados”, es decir, están marcados de tal forma que no nos permite ninguna modificación en los mismos.
2.4. Bifurcar (Branch)
El siguiente paso es quitar la fijación (desfijar suena demasiado mal) de los archivos que necesitan ser modificados para corregir los errores encontrados en producción. Para ello utilizamos la opción de bifurcarlos en lugar de simplemente quitarles esa fijación (me estoy dando cuenta que esto tampoco suena muy bien).
La diferencia entre “Desfijar” (“Unpin”) y “Bifurcar” (“Branch”) es que el segundo permite volver a combinar los cambios con la versión inicial de una forma automática, mientras que el primero no. Por lo tanto, aplicamos la bifurcación al archivo que tenemos que modificar, esta vez desde el menú “Versiones -> Bifurcar” teniendo seleccionado el archivo deseado (yo tampoco entiendo porqué no está la opción en el menú contextual o “de botón derecho”).
Una vez hecho ya podemos hacer las modificaciones necesarias en dicho archivo. Generar nuevamente el proyecto, probarlo, instalarlo en producción y cualquier cosa que queramos o necesitemos según nuestra metodología de trabajo (si tenemos).
Después de realizadas las modificaciones para la versión 1.0, es posible que queramos incluirlas también en la versión actual del proyecto. Recordemos: esa que está en plena fase de desarrollo con el objetivo de lanzar la versión 2.0. Esto lo podemos hacer de forma manual en el código fuente actual, pero también puede que queramos, sin encomendarnos a nadie, que sea el propio SourceSafe de forma automática.
2.5. Combinar versiones bifurcadas (Merge Branches)
Esta es la forma en la que SourceSafe incluye los cambios de una versión de un archivo en otra. Para ello se selecciona el archivo en el que queremos incluir las modificaciones hechas, a través del menú “Versiones -> Combinar versiones” (ésta opción tampoco está en el menú contextual; las preguntas a Microsoft):
Insisto: “en el archivo en el que queremos incluir las modificaciones”. Es decir, si nuestra intención es incluir en el archivo de desarrollo actual (próximo a la versión 2.0) los cambios hechos en la versión antigua (etiquetada como v1.1) es el archivo actual el que debemos tener seleccionado al pulsar esta opción.
A continuación nos aparece una ventana en la que tenemos que elegir con qué archivo lo queremos combinar. Lo normal es que elijamos el mismo archivo de la versión v1.1. Por suerte, SourceSafe está atento y sólo nos habilita el botón de Combinar (Merge) cuando hemos seleccionado un archivo válido.
.PNG)
El ojo hábil habrá notado que he cambiado el fichero de la prueba (antes Class1.cs, ahora Form1.cs). El motivo es que el previo ha sufrido demasiadas pruebas y la pantalla de ejemplo no iba a ser nada clara.
Cabe la posibilidad de que tengamos conflictos en este proceso, principalmente cuando la misma línea ha sido modificada en ambas versiones. En estos casos nos saldrá una ventana en la que tendremos que indicar qué líneas tienen que ser incluidas en la versión. Esta elección se realiza de una forma visual y totalmente intuitiva, “pinchando” el cambio que queremos incluir (se pueden incluir ambos). Francamente, me ha sorprendido (para bien):
.PNG)
Con esto ya tenemos los cambios tanto en el parche para salir del paso en producción (versión 1.1) como en la versión del código fuente en desarrollo. Sólo nos queda volver a “Fijar” los archivos modificados.
2.6. Fijar (Pin)
Una vez que hemos terminado de hacer los cambios, lo ideal es volver a “Fijar” los archivos de la versión v1.1. ¿Para qué? Para evitar que en un descuido volvamos a modificar esta versión y olvidemos propagar el cambio a la última versión del código fuente.
Desde mi punto de vista (que es personal e intransferible) es preferible que para volver a hacer una modificación sobre esta versión “del parche”, tengamos que repetir los pasos de “Bifurcación” y “Combinación”.
Para fijar manualmente una versión de un archivo (la vez anterior se fijó de forma automática al compartirla) abrimos su histórico y pulsamos en el botón Fijar (Pin):
3. Conclusión
Los sistemas de control de versiones (SCV) como Microsoft SourceSafe son muy útiles, abarcando una amplia gama de funciones desde el simple sistema de copia de seguridad del código fuente, hasta tareas mucho más complejas como gestión de Ramas (Bifurcaciones o Branches) como la que se ha apuntado ligeramente en este documento.
La utilización de estos SCV se vuelve imprescindible cuando la complejidad de los programas crece, tanto por su tamaño como por las personas involucradas en su desarrollo.
Independientemente de (o además de) estos motivos, es una buena idea mantener los saludables hábitos de su (correcta) utilización para evitar sustos y disgustos cuando la vida real se cruza con la bonita teoría del diseño y desarrollo de aplicaciones.
4. Enlaces
Como dijimos al principio, todo lo nombrado en este documento está mucho mejor explicado en la página de la ayuda de MSDN de Microsoft SourceSafe:
http://msdn2.microsoft.com/es-es/library/ms181038(VS.80).aspx
Sin embargo, no es ni mucho menos el primero ni el único programa con este fin. Un buen punto por donde empezar a conocer algún otro es Git: el programa utilizado actualmente para controlar las distintas versiones de kernel de Linux:
http://git.or.cz/
Mucha más información en la Wikipedia:
http://es.wikipedia.org/wiki/Control_de_versiones (español)
http://en.wikipedia.org/wiki/Version_control_system (inglés)
5. Agradecimientos
Este documento ha sido redactado para uso interno de mi departamento en mi trabajo y está publicado aquí con el conocimiento y la aprobación de mis jefes. Pues eso.
martes, 6 de mayo de 2008
Un usuario menos
Como dice el refranero, no es lo mismo predicar que dar trigo. O lo que es lo mismo, hablar es muy fácil, pero no está de más que de vez en cuando los hechos acompañen a las palabras.
Hace unas semanas, el ordenador -Windows XP- de un familiar se había convertido en una granja de virus y diverso malware, así que había llegado el momento de limpiarlo o reinstalar el sistema operativo. Como da la casualidad que estamos en los días siguientes de la recentísima publicación de la versión definitiva de Ubuntu 8.04, decidí que era éste el que le iba a instalar, con la ventaja añadida de olvidar futuros problemas de virus y todo lo que conlleva un sistema Linux.
Llegué ufano y feliz con el CD todavía calentito e intenté arrancar sin modificar el sistema, ya sabéis, para ver si íbamos a tener problemas serios.. y el único problema es que cualquier cosa ridícula, como mover el ratón, suponía algunos minutos de rascar el CD. Y es que soy un animal -lo reconozco- porque pretendía exigir demasiado a un Athlon 2'4GHz con sólo 256MB de memoria. Alguien picajoso podría decir que eso tendría que avisarlo al arrancar, pero no era mi caso: yo estaba de lo más positivo.
Lo siguiente fue lanzarme a instalar el sistema a las bravas, sin encomendarme a nadie. El ordenador no tenía ningún archivo que tuviese que ser guardado -gracias sean dadas a GMail-, así que no me preocupó en lo más mínimo cosas como redimensionar particiones NTFS para no perder datos. Sencillamente me llevé por delante el sistema de archivos y utilicé todo el espacio para la nueva instalación. La velocidad no era la deseable, y cada uno de esos 7 pasos tardaba bastante en salir, pero insisto que en son 256MB -el mínimo que pide la instalación-.
Y por fin la instalación, y si has seguido mis peripecias con este acojosistema operativo seguro que ya te vas imaginando cómo termina la película. Porque la película termina con el ordenador frito cuando llega al 15% de la preparación de los discos duros, concretamente mientras calcula el sistema de archivos. No se muy bien qué estaba calculando, porque en el segundo intento configuré manualmente las particiones para que no se lo tuviese que pensar, pero volvió a quedarse muerto en el mismo punto.
Así que me gustaría que la historia hubiese terminado de otra forma, pero a estas alturas Ubuntu, y por extensión el mundo Linux, tiene un usuario menos de los que podría tener.
PD: Acabo de leer que hay una nueva versión de OpenSolaris. Quizá lo vuelva a intentar con el sistema operativo de una empresa seria.
Hace unas semanas, el ordenador -Windows XP- de un familiar se había convertido en una granja de virus y diverso malware, así que había llegado el momento de limpiarlo o reinstalar el sistema operativo. Como da la casualidad que estamos en los días siguientes de la recentísima publicación de la versión definitiva de Ubuntu 8.04, decidí que era éste el que le iba a instalar, con la ventaja añadida de olvidar futuros problemas de virus y todo lo que conlleva un sistema Linux.
Llegué ufano y feliz con el CD todavía calentito e intenté arrancar sin modificar el sistema, ya sabéis, para ver si íbamos a tener problemas serios.. y el único problema es que cualquier cosa ridícula, como mover el ratón, suponía algunos minutos de rascar el CD. Y es que soy un animal -lo reconozco- porque pretendía exigir demasiado a un Athlon 2'4GHz con sólo 256MB de memoria. Alguien picajoso podría decir que eso tendría que avisarlo al arrancar, pero no era mi caso: yo estaba de lo más positivo.
Lo siguiente fue lanzarme a instalar el sistema a las bravas, sin encomendarme a nadie. El ordenador no tenía ningún archivo que tuviese que ser guardado -gracias sean dadas a GMail-, así que no me preocupó en lo más mínimo cosas como redimensionar particiones NTFS para no perder datos. Sencillamente me llevé por delante el sistema de archivos y utilicé todo el espacio para la nueva instalación. La velocidad no era la deseable, y cada uno de esos 7 pasos tardaba bastante en salir, pero insisto que en son 256MB -el mínimo que pide la instalación-.
Y por fin la instalación, y si has seguido mis peripecias con este acojosistema operativo seguro que ya te vas imaginando cómo termina la película. Porque la película termina con el ordenador frito cuando llega al 15% de la preparación de los discos duros, concretamente mientras calcula el sistema de archivos. No se muy bien qué estaba calculando, porque en el segundo intento configuré manualmente las particiones para que no se lo tuviese que pensar, pero volvió a quedarse muerto en el mismo punto.
Así que me gustaría que la historia hubiese terminado de otra forma, pero a estas alturas Ubuntu, y por extensión el mundo Linux, tiene un usuario menos de los que podría tener.
PD: Acabo de leer que hay una nueva versión de OpenSolaris. Quizá lo vuelva a intentar con el sistema operativo de una empresa seria.
Suscribirse a:
Entradas (Atom)
