domingo, 21 de abril de 2013

Automatizando Builds con GXserver y CruiseControl.NET

Imagen de 'Automatizando Builds con GXserver y CruiseControl.NET'Una de las ventajas de utilizar un repositorio de control de cambios, como es GeneXus Server para el desarrollo con GeneXus, es la posibilidad de automatizar el proceso de armado de un proyecto a partir de los cambios que van haciendo los desarrolladores.

Esta es una guía de cómo poner esto en práctica.


Para qué automatizar el armado del proyecto

Tener un proceso automático es uno de los componentes básicos de Integración Continua, una práctica en el desarrollo de software que consiste en integrar frecuentemente (varias veces por día), el trabajo de los diferentes desarrolladores con el objetivo de detectar lo más pronto posible los problemas de integración. Los ambientes de trabajo de los diferentes desarrolladores se integran por medio de los commits que estos hacen a un repositorio central, y la integración es verificada por un proceso automático de armado del proyecto, que también puede incluir otros tests.

Pero sea en el contexto de Integración Continua, o de integraciones menos frecuentes, el solo hecho automatizar el armado a partir de lo que está en el repositorio tiene ventajas en sí mismo.

El armado de un sistema suele ser un proceso complejo que involucra múltiples etapas, desde obtener los últimos cambios del repositorio, generar y compilar todo lo necesario, ejecutar reorganizaciones, hasta mover los programas al ambiente de ejecución, por nombrar sólo los más visibles.

Si a esto le agregamos los detalles del armado de múltiples versiones del proyecto (que toman cosas de diferentes lugares, necesitan componentes de diferentes versiones, que dejan los resultados en otro lugar, etc.), y diferentes variantes de armado (con o sin tests, armando o no ciertos módulos, produciendo o no un setup, etc.), la complejidad puede crecer significativamente.

Automatizar este proceso implica, entre otras cosas:
  • No tener que dedicar a una persona para ejecutar cada etapa, verificar los resultados, decidir el siguiente paso a ejecutar, etc.,
  • No depender del conocimiento de una persona para ejecutar estos pasos correctamente y en el orden adecuado. ¿Qué pasa cuando esta persona se enferma o se toma vacaciones?
  • No correr el riesgo de que esa persona se equivoque, cosa que frecuentemente ocurre en los momentos de mayor estrés, es decir, cuando puede producir más daño.
Pero además, el tener la posibilidad de ejecutar todo el proceso de armado en forma totalmente desatendida y con un solo comando, nos habilita la posibilidad de dar el siguiente gran paso, que es automatizar también el propio disparo del proceso. Por ejemplo, uno podría querer que cada cierto tiempo se verificara si hubo nuevos commits en el repositorio, y que en caso afirmativo se ejecutara automáticamente el armado del proyecto. Para algunos podría querer hacer esto varias veces por día, para otros sólo durante las noches e incluso algunos solo durante los fines de semana. Aquí es donde entran en escena los llamados servidores de integración continua, de los cuales CruiseControl.NET es un ejemplo.

Combinando GeneXus Server y CruiseControl.NET

Un servidor de integración continua es un servicio que se encarga de monitorear cierto repositorio de software para ver si se produjeron cambios, en cuyo caso puede disparar un proceso de armado del proyecto.

En nuestro caso, lo que vamos a utilizar como servidor de integración continua es CruiseControl.NET. Este software va a monitorear con la frecuencia que indiquemos bases de conocimiento administradas por un GeneXus Server, y en caso de que se hayan producido nuevos commits, se encargará de actualizar una copia de la KB, y ejecutar el proceso de armado. Tanto la actualización como el armado se ejecutarán a través de tareas MSBuild, de forma que no sea necesario levantar GeneXus para ello.

Guía de Configuración

Proceso general

En primer lugar se necesita una máquina en la que estén instalados GeneXus, y CruiseControl.NET. También será necesario poder acceder desde allí a un GXserver, que podrá estar instalado en la misma máquina o no.

Luego de instalar el software conviene obtener desde GXserver una copia de la KB y ejecutar el build de forma manual, para asegurarse de que todo funciona correctamente. Luego de eso se puede proceder a la automatización del build a través de Cruise Control.

Paso 1 - Seleccionar la máquina

El primer paso es elegir la máquina en la que se va a instalar el servidor de Builds. Esta máquina tiene que tener la capacidad de tener instalado tanto GeneXus como CruiseControl.NET.

Requerimientos de instalación de GeneXus
Requerimientos de instalación de CruiseControl.NET

Para poder utilizar la consola web de CruiseControl.NET (WebDashboard) es necesario también tener instalado IIS con ASP.NET habilitado.

En caso de que el GXserver a utilizar no esté en la misma máquina, será necesario tener conectividad HTTPS con la máquina en la que esté instalado GXserver, ya sea a través de intranet o internet.

Paso 2 - Descargar e instalar GeneXus

Es necesario instalar GeneXus versión X Evolution 1 U7 en adelante.

Descargar GeneXus X Evolution 2
Manual de instalación de GeneXus

El programa instalación de GeneXus guarda la ruta del directorio de instalación en la variable de entorno GX_PROGRAM_DIR. Verificar el contenido de esta variable, y ajustarlo en caso de que fuera necesario.

Copiar los siguientes archivos en el directorio de instalación de GeneXus:

Artech.Samples.GXserverExtraTasks.dll
Artech.Samples.GXserverExtraTasks.targets

Paso 3 - Descargar e instalar el cliente de GXserver por línea de comando

Instalar los siguientes archivos en algún directorio local, por ejemplo C:\GXserverClient. En adelante nos referiremos a este directorio como [GXserverClient].

TeamDev.exe
TeamDev.exe.config
TeamDev.msbuild

Paso 4 - Descargar e instalar CruiseControl.NET.

Descargar CruiseControl.NET
Documentación de CruiseControl.NET

El setup presenta tres componentes para instalar. Es necesario como mínimo el CruiseControl.NET Server y se recomienda también instalar el Web Dashboard.



También se recomienda dejar marcadas las opciones de "Install CC.Net server as Windows service" y "Create virtual directory in IIS for Web Dashboard".



Como es usual, se puede elegir también el directorio de instalación, que por defecto es algo similar a C:\Program Files\CruiseControl.Net. En adelante, nos referiremos a este directorio de instalación como [CruiseControl]

Paso 5 - Agregar add-in de GXserver a Cruise Control

CruiseControl reconoce en su configuración por defecto varios sistemas de repositorio (SVN, CVS, etc.). Con este add-in, CruiseControl puede reconocer también a GXserver como un repositorio válido e interactuar con él.

Copiar CCNet.GXserver.Plugin.dll al directorio [CruiseControl]\server.

Paso 6 - Agregar conversor de logs de MSBuild de Rodemeyer

Esta dll mejora la forma en que la salida de los procesos de MSBuild son mostrados en el log de armado. Para esto, es necesario ejecutar los dos primeros pasos mencionados en la sección "How to use" del artículo Improved MSBuild Integration. Estos dos pasos son:

1. Copiar Rodemeyer.MsBuildToCCnet.dll a la carpeta [CruiseControl]\server.
2. Copiar msbuild2ccnet.xsl a la carpeta [CruiseControl]\webdashboard\xsl.

Paso 7 - Iniciar servidor de CruiseControl.NET

CruiseControl.NET puede ser ejecutado de dos maneras: como un servicio de Windows o como una aplicación de consola. Para el funcionamiento normal, lo recomendado es utilizar el servicio, pero en las primeras etapas de configuración, puede ser útil la aplicación de consola, ya que brinda información inmediata con mensajes en la consola y puede ser más fácil de detener y volver a ejecutar. Una vez que se ha estabilizado la configuración se puede pasar a utilizar el servicio.

Ambas aplicaciones se encuentran en el directorio [CruiseControl]\server, y se llaman ccservice.exe (el servicio) y ccnet.exe (la aplicación de consola), y cuentan con sus respectivos archivos de configuración ccservice.exe.config y ccnet.exe.config. En estos archivos se pueden configurar aspectos específicos a una u otra forma de ejecutar, y cada uno de ellos utiliza un tercer archivo de configuración (ccnet.config), usualmente compartido, donde en particular se establecen cuáles son los diferentes proyectos de armado (build projects).

Cada proyecto de armado indica un cierto repositorio de fuentes, qué cosas obtener de él, cada cuánto hay que consultarlo para saber si hubo cambios, dónde mantener una copia local de los fuentes, y qué ejecutar para realizar el build.

La ubicación por defecto del archivo ccnet.config es también en el directorio [CruiseControl]\server, aunque se puede especificar otra ubicación agregando una entrada como la siguiente en la sección <appSettings> de ccservice.exe.config y ccnet.exe.config:


<appSettings>
   <!-- Without this appSetting ccservice will look for ccnet.config
        in its own directory.
-->
   <add key="ccnet.config" value="c:\some\path\to\ccnet.config"/>
   ...
</appSettings>


A su vez, el contenido inicial del archivo ccnet.config es el siguiente:


<cruisecontrol xmlns:cb="urn:ccnet.config.builder">
  <!-- This is your CruiseControl.NET Server Configuration file. Add
       your projects below!
-->

  <project name="MyFirstProject"
           description="demoproject showing a small config">
    <triggers>
      <!-- check the source control every X time for changes,
       and run the tasks if changes are found -->
     <intervalTrigger name="continuous"
                      seconds="30"
                      buildCondition="IfModificationExists"
                      initialSeconds="5"/>
    </triggers>

   <sourcecontrol type="nullSourceControl"
                  alwaysModified="true" />

    <tasks>
      <exec>
        <!-- if you want the task to fail,
             ping an unknown server
-->
       <executable>ping.exe</executable>
       <buildArgs>localhost</buildArgs>
       <buildTimeoutSeconds>15</buildTimeoutSeconds>
       <description>Pinging a server</description>
      </exec>
    </tasks>

    <publishers>
     <xmllogger />
     <artifactcleanup cleanUpMethod="KeepLastXBuilds"
                      cleanUpValue="50" />
    </publishers>

  </project>

</cruisecontrol>


Como se ejemplifica allí, en cada </project> declarado en el archivo ccnet.config, se pueden establecer una serie de elementos:
  • <triggers> - disparadores de la consulta por cambios en los fuentes. En el ejemplo, el disparo es simplemente por tiempo, y se consultará al repositorio si hay nuevos cambios cada 30 segundos, y se ejecutará el build si hay modificaciones.
  • <sourcecontrol> - el repositorio desde el cual se obtienen los fuentes. El tipo de repositorio puede ser alguno de los repositorios estándar ("svn", "cvs", etc.) o bien, como veremos más adelante, gracias al plugin que instalamos en el paso 4, también "gxserver". En el ejemplo se utiliza un tipo especial "nullSourceControl", que tiene una respuesta fija como que siempre hay nuevos cambios.
  • <tasks> - las tareas a ejecutar cuando se encuentran cambios en los fuentes. Usualmente aquí se utiliza una tarea que ejecute el proceso de build, y en el ejemplo esto es simulado con un comando ping, simplemente para que ejecute algo.
  • <publishers> - son tareas a ejecutar luego de finalizado el build y generalmente se utiliza para recolectar y publicar los resultados.
Esta configuración inicial no realiza el armado de ningún fuente, pero es útil para ejecutar el CruiseControl.NET y verificar si funciona hasta este punto. Una vez en funcionamiento, cualquier cambio en el archivo de configuración será detectado automáticamente.

Para iniciar el servidor, vamos a ejecutar el ccnet.exe desde una ventana de comandos (alternativamente podemos ejecutar la opción CruiseControl.NET en el menú de inicio de Windows.

Luego de iniciar el servidor, para verificar que todo está funcionando bien, se puede acceder a la URL del servidor: [http://localhost/ccnet], en donde aparecerá la consola (Web Dashboard) de CruiseControl.NET:

Paso 8 - Crear la copia de trabajo de la KB

En cada item de armado en CruiseControl.NET, a los cuales se les llama proyectos (projects) se va a especificar cuál es la KB en GXserver de que se trata, qué versión (si hay más de una), qué environment, etc.. Para cada uno de esos proyectos, se va a especificar también la ubicación de una KB local, que se utilizará como copia de trabajo para actualizar con lo que haya en GXserver y realizar el proceso de build.

Se recomienda centralizar todas las copias de trabajo que vayan a ser utilizadas con CruiseControl.NET en una misma estructura de directorios, de forma tal que para cada proyecto exista un directorio, dentro del cual esté como hijo el directorio de la KB de trabajo propiamente dicha.

Por ejemplo, si se va a automatizar el proceso de Build de dos KBs, una KB llamada Bobsville (en su versión principal y en otra llamada "Version 1.0"), y otra KB llamada Sunflower Valley (en su versión principal y en otra llamada "Versión 2.2"), el árbol de directorios podría ser el siguiente:


CruiseControlData
  |
   --- Bobsville
  |      |
  |       --- Principal
  |      |      |
  |      |       --- WorkingCopy
  |      |
  |       --- Version1.0
  |             |
  |              --- WorkingCopy
  |
   --- Sunflower Valley
  |      |
  |       --- Principal
  |      |      |
  |      |       --- WorkingCopy
  |      |
  |       --- Version2.2
  |             |
  |              --- WorkingCopy
  |
  .
  .
  .


Los proyectos que corresponden a una misma KB del server (Bobsville y Sunflower Valley en este caso) aparecen allí agrupados bajo un mismo directorio, aunque esto no es estrictamente necesario. Lo que sí es importante, por razones que se verán más adelante, es que para cada proyecto de armado, exista un directorio específico al proyecto, dentro del cual esté a su vez el directorio de la KB de trabajo.

A los efectos de continuar con el proceso de configuracíón de la integración continua, vamos a considerar que automatizaremos en primer lugar el armado de la versión principal de la KB Bobsville, para lo cual crearemos la copia de trabajo en el directorio C:\CruiseControlData\Bobsville\Principal\WorkingCopy. La KB Bobsville se puede obtener del GXserver de Sandbox de la Evolution 2, es decir en la URL http://sandbox.genexusserver.com/xev2. A continuación se puede ver el contenido de la ventana de Create Knowledge Base from GeneXus Server al momento de crear esta copia de trabajo.

Paso 9 - Primer update y build manual

Luego de crear la copia de trabajo es necesario hacer un Update y un Build, lo cual a su vez requiere definir (o crear) la base de datos operativa, especificar y generar todo por primera vez. Este proceso podría evitarse si se parte de una KB de trabajo existente que ya esté armada, y se copia para aquí con todos sus archivos ya generados.

En cualquier caso, lo importante es verificar que es posible hacer un Update y un Build en forma manual, resolviendo cualquier problema que pudiera surgir, para estar seguros de que está todo bien configurado con respecto a GeneXus y GXserver, y que a partir de este punto solo es necesario proceder a la automatización.

Paso 10 - Configurar el proyecto de armado

Para configurar un proyecto de armado es necesario editar el archivo ccnet.config, para agregar en el XML un nuevo elemento de tipo <project>.

En primer lugar, vamos a declarar algunas variables, cuyo valor depende de cada instalación, y que se van a referenciar después desde la declaración de los datos del proyecto. De esta forma, esas variables pueden ser compartidas para varios proyectos y es más sencillo actualizarlas. Copiar lo siguiente inmediatamente después del elemento raíz del XML (<cruisecontrol xmlns:cb="urn:ccnet.config.builder">):


<!-- GeneXus installations -->
<cb:define GxXEv1U8Dir="C:\Program Files\Artech\GeneXus\GeneXusXEv1U8" />
<cb:define GxXEv2U2="C:\Program Files\Artech\GeneXus\GeneXusXEv2U2" />
<cb:define GxDefault="$(GxXEv2U2)" />

<!-- GXserver credentials -->
<cb:define GXserverUser="GXtechnical\user" />
<cb:define GXserverPassword="**********" />

<!-- MSBuild executable -->
<cb:define MSBuildExe="C:\Windows\Microsoft.NET\Framework\v3.5\msbuild.exe" />

<!-- CruiseControl configuration -->
<cb:define CruiseControlServerDir="C:\Program Files\CruiseControl.NET\server" />
<
cb:define CruiseControlDataDir="C:\CruiseControlData" />
<cb:define GXserverClientDir="C:\GXserverClient" />
<cb:define TeamDevExePath="$(GXserverClientDir)\TeamDev.exe" />


Naturalmente que es necesario modificar algunos de los valores de estas variables (aquellos resaltados con fondo amarillo) con lo que corresponda en cada caso. Luego, a continuación de estas declaraciones de variables, hay que agregar lo siguiente que es la declaración del proyecto de armado:


<project name="Bobsville Principal">
  <sourcecontrol type="gxserver">
    <serverUrl>http://sandbox.genexusserver.com/xev2</serverUrl>
    <serverUsername>$(GXserverUser)</serverUsername>
    <serverPassword>$(GXserverPassword)</serverPassword>
    <serverKbAlias>Bobsville</serverKbAlias>
    <serverKbVersion>Bobsville</serverKbVersion>
    <getAllKbVersions>false</getAllKbVersions>
    <workingDirectory>
      $(CruiseControlDataDir)\Bobsville\Principal\WorkingCopy
    </workingDirectory>
    <workingVersion></workingVersion>
    <workingEnvironment></workingEnvironment>
    <localSettings>
      $(CruiseControlDataDir)\Bobsville\Principal\settings.local
    </localSettings >
    <dbaseServerInstance></dbaseServerInstance>
    <createDbInKbFolder>true</createDbInKbFolder>
    <dbaseUseIntegratedSecurity>true</dbaseUseIntegratedSecurity>
    <dbaseServerUsername></dbaseServerUsername>
    <dbaseServerPassword></dbaseServerPassword>
    <dbaseName></dbaseName>
    <executable>$(TeamDevExePath)</executable>
    <teamDevTasks>"$(GXserverClientDir)\TeamDev.msbuild"</teamDevTasks>
    <msbuildExecutable>$(MSBuildExe)</msbuildExecutable>
    <autoGetSource>true</autoGetSource>
    <cleanCopy>false</cleanCopy>
    <tagOnSuccess>false</tagOnSuccess>
  </sourcecontrol>
  <triggers>
    <intervalTrigger seconds="600"/>
  </triggers>
  <tasks>
    <msbuild>
      <executable>$(MSBuildExe)</executable>
      <projectFile>$(GXserverClientDir)\TeamDev.msbuild</projectFile>
      <buildArgs>
        /v:Normal
        /t:Build
        /p:WorkingDirectory=
           "$(CruiseControlDataDir)\Bobsville\Principal\WorkingCopy"
        /p:ServerUsername=$(GXserverUser)
        /p:ServerPassword=$(GXserverPassword)
        /p:GX_PROGRAM_DIR="$(GxDefault)"
        /p:MSBuildExtensionsPath="c:\Program Files\MSBuild"
      </buildArgs>
      <logger>
        $(CruiseControlServerDir)\Rodemeyer.MsBuildToCCNet.dll
      </logger>
      <timeout>18000</timeout>
    </msbuild>
  </tasks>
  <publishers>
    <xmllogger />
    <artifactcleanup cleanUpMethod="KeepLastXBuilds" cleanUpValue="50" />
    <modificationHistory />
  </publishers>
</project>


Al salvar el contenido del archivo ccnet.config, el cambio será detectado por CruiseControl.NET y si volvemos a la consola (Web Dashboard), veremos ahora nuestro nuevo proyecto. A partir de ahora, cada vez que CruiseControl.NET detecte que hay un nuevo commit (va a estar consultando a GXserver cada 10 minutos, según lo que pusimos en <intervalTrigger>) ejecutará el build de la KB, y podremos ver los resultados desde la propia consola.

¿Todavía por aquí?

Si llegaron hasta este punto, habiendo seguido todos los pasos de arriba, me interesa saber cómo les fue. ¿Problemas, errores, sugerencias?

¿Funcionó todo bien? Si es así, los invito a firmar en el Libro de Visitas. Busquen en la KB Bobsville un objeto con ese nombre, anótense allí y hagan commit para que todos nos enteremos.

Por supuesto, siéntanse libres también de colaborar en el desarrollo de la KB Bobsville. ♦

Imagen: Assembly line robots, publicada por Annette Davis, bajo licencia CC BY-NC-ND 3.0.
Leer más......

jueves, 3 de noviembre de 2011

7 razones para usar GXserver con un solo desarrollador

GeneXus Server es la herramienta de control de versiones para GeneXus. Debido a que representa la mejor solución para la coordinación de desarrollo en equipo, muchas veces suponemos que sólo es adecuado si los que desarrollan en un proyecto son dos o más personas. Sin embargo, hay muchas razones por las cuales no sólo es razonable utilizar un repositorio de control de versiones aunque haya un solo desarrollador, sino que de hecho es la mejor opción para un trabajo profesional.

1 – Viajar al pasado

El registro histórico de cambios nos da toda la información sobre qué cambió, cuándo, y por qué. Por ejemplo, nos permite responder preguntas como “¿qué cambié en la última semana que puede haber producido este nuevo error?”.

Es verdad que si trabajamos sin GXserver, GeneXus también provee una historia de cambios por objeto, creando una revisión cada vez que el usuario lo salva. Pero la historia de los cambios en GXserver va mucho más allá de esto, porque cuando hacemos un commit, estamos definiendo un grupo lógico de objetos que cambian al mismo tiempo y con una intención específica y declarada (ie: comentarios del commit). Los comentarios incluso pueden tener una referencia a un número de ticket de un sistema de seguimiento de errores o de manejo de proyectos.

Cuando algo falla, tenemos todo lo necesario para revertir los errores. Muchas veces los cambios en un objeto están relacionados con cambios a otros objetos. Por ejemplo, si cambiamos los parámetros de un procedimiento, tendremos que cambiar también los objetos que lo llamaban. Tener el conocimiento de cuáles fueron todos los objetos modificados en cada commit, nos permite estar seguros de que estamos corrigiendo todos los objetos que lo necesitan.

De la misma forma, para entender por qué a un objeto le hicimos cierto cambio, es fundamental la información de contexto; es decir qué otros objetos cambiaron en ese mismo momento, e incluso cuál era el estado de los que no cambiaron.

2 – Mejor manejo de versiones

Por supuesto que también podemos tener versiones congeladas y nuevas ramas de desarrollo en una KB incluso sin GXserver, pero usando GXserver obtenemos además la facilidad de publicar cualquiera de estas ramas a procesos externos o servidores de armado o integración continua, en forma desacoplada y sin las penalidades de performance asociadas a un acceso compartido por la red a una KB.

La KB en la que desarrollamos solo necesita tener la rama en la que estamos haciendo cambios, mientras que en el server podemos tener todas las versiones congeladas y todas las ramas de desarrollo. Un servidor de integración continua puede estar monitoreando los commits que hagamos en cualquiera de las versiones, para disparar un proceso de armado de la versión, ejecución de tests, deploy, etc.

3 – Libre experimentación

En nuestra KB local, podemos experimentar y probar libremente, contando con la seguridad de que nada de esto afecta la versión “oficial” a menos que explícitamente hagamos commit de los cambios. Una vez que estamos listos para hacer un commit, podemos revisar el reporte de cambios pendientes de commit, comparar cada objeto con su estado original, y decidir cuáles incluir en el commit, cuáles fácilmente revertir a su estado inicial, y cuáles mantener como cambios locales.

GXserver controlará además que el conjunto de objetos incluido en el commit sea coherente (por ejemplo, que no incluyamos una llamada a un objeto nuevo que olvidamos incluir), y en caso de cualquier error rechazará todos los cambios sin modificar nada, de forma de asegurar que todo commit forme una unidad lógica de cambios completa y que nunca perdemos la integridad de la KB del server.

4 – Respaldos más fáciles

Nunca es necesario hacer respaldo de múltiples copias de una misma KB, y siempre tenemos claro qué es exactamente lo que necesitamos respaldar: las KBs administradas por el server. En tanto hagamos commit y tengamos una adecuada política de respaldo de las KBs del server, estamos asegurados de posibles pérdidas de las KBs locales, sean debidas a fallas de discos, notebooks robados, o cualquier causa similar.

Si utilizamos el GXserver Online (suscripción a GXserver en la nube), incluso contamos con respaldos automáticos de todas las KBs.

5 – Inspección online de la KB

GXserver provee una consola web por la cual podemos inspeccionar las KBs, el contenido de sus objetos, y la actividad de cambios. No es necesario contar con GX para esto, alcanza con un browser. Si tenemos nuestra instalación de GX y las KBs en la oficina, igual podemos usar esta consola desde casa o cuando estamos de viaje.

6 – Integración de otros actores

Podemos dar acceso a la consola de GXserver para integrar a otras personas que aunque no desarrollan están involucradas en el proyecto y necesitan monitorear su desarrollo, como por ejemplo, un gerente, o un cliente para el cual estamos desarrollando el sistema.

Por otra parte, el desarrollo de un proyecto muchas veces requiere de la participación de varios otros actores que pueden utilizar la consola del server para tener acceso a la información de la KB, sin necesidad de que tengan efectivamente la KB ni tampoco una licencia de GX. Ejemplos de esto pueden ser los que trabajan en la documentación, traducciones, o el diseño gráfico.

7 – Cualquier momento, cualquier lugar

Incluso si somos el único desarrollador, podemos obtener una copia actualizada del server desde cualquier lugar. Por ejemplo, podemos tener una KB local en la oficina y otra en casa, y sincronizarlas a través de GXserver sin esfuerzo.

En caso de que agreguemos un nuevo desarrollador, ya sea en forma permanente o temporaria, es sumamente fácil obtener su KB de trabajo, en el momento que sea, y esté donde esté.

En resumen

Usar una herramienta de manejo de versiones y la metodología asociada a esto, es una de esas cosas que a veces nos parece que no vamos a necesitar, hasta que comenzamos a usarlas. Luego nos damos cuenta de que las ventajas son muchísimas, y entonces nos parece mentira que antes pudiéramos trabajar sin ella.

Una de las ventajas más notorias es la facilidad con que podemos incorporar el trabajo de diferentes personas en un mismo proyecto, logrando que todas ellas trabajen en forma autónoma, sin interferencias, pero al mismo tiempo facilitando y organizando la integración del trabajo de todos.

Sin embargo, las ventajas de utilizar metodología y herramientas de control de versiones son tantas, aun para un solo desarrollador, que resulta indispensable para un desarrollo de software profesional. Las de arriba son solo algunas de las ventajas más salientes, pero sin duda que puede haber muchas más.

De hecho, esto no es específico de GeneXus o GXserver; aplica igualmente para cualquier desarrollo de software con lenguajes tradicionales, y siempre que surge la pregunta, la recomendación es la misma: conviene utilizar control de versiones aunque haya un solo desarrollador.♦

Imagen: One Man Band, Marc Dobson performing at Milliken's Reef, Cape Canaveral, Florida
Leer más......

sábado, 4 de setiembre de 2010

Experimento mental: legislador por un día

Imagen de 'Experimento mental: legislador por un día'Supongamos que por obra de birlibirloque, en tu país han quedado sin efecto la Constitución, todas las leyes, decretos, ordenanzas municipales, y demás normas jurídicas. Luego, una a una te las van presentando y te dan el poder de decidir si quieres restablecerlas o no. No hay pasado, ni costumbres, ni necesidad de adaptaciones, ni nada parecido; simplemente arrancaremos de cero con aquellas normas que te parezcan buenas y necesarias, y para las demás será como si nunca hubiesen existido. En determinado momento te proponen la siguiente ley ficticia, que esquemáticamente dispone:
  • Todos los ciudadanos serán obligados a prestar un juramento solemne de defender al pais, sacrificando su propia vida si fuera necesario.
  • A cada ciudadano se le citará a hacer este juramento solemne a la edad de 12 años.
  • Para hacer el juramento, todos los años en la fecha del nacimiento del prócer nacional, todos los niños de 12 años serán convocados en su centro de estudio a la ceremonia de juramento, en presencia de sus padres, sus profesores y las autoridades de la institución.
  • La ceremonia incluirá cantos colectivos que ensalzan la figura del prócer y el sentimiento nacional (himno nacional y canto a "mi bandera") así como discursos de autoridades sobre los mismos temas.
  • Durante la ceremonia, se le presentará el juramento a los niños, con las siguiente fórmula textual:
  • ¿Juráis honrar vuestra Patria, con la práctica constante de una vida digna, consagrada al ejercicio del bien para vosotros y vuestros semejantes; defender con sacrificio de vuestra vida, si fuere preciso, la Constitución y las Leyes de la República, el honor y la integridad de la Nación y sus instituciones democráticas, todo lo cual simboliza esta Bandera?
  • Los niños serán instruidos a contestar todos juntos "¡Sí, juro!"
  • Quienes no hagan este juramento no podrán tener cargos en la Administración Pública ni obtener un título profesional o técnico.
¿Qué haces con esta ley? ¿La agregas o no? ¿Es buena, es útil, es necesaria? Estás solo para decidir libremente. La respuesta no está predeterminada, y nadie te presiona. ¿La aprobarías o no? ¿Por qué?

Material extra:
Ley N° 9.943 del 20 de julio de 1940
Ley N° 9.935 del 14 de junio de 1940
Circular N° 9 de ANEP del 11 de mayo de 2007
Imagen: Fachada del Palacio Legistativo, Montevideo, Uruguay. Autor: Federico Corral aka Shant.
Leer más......

jueves, 9 de octubre de 2008

La Tienda de la Nostalgia

Ejercicio de recordación asistida por computadora

tocadiscosHace un par de semanas estaba en La Tienda esperando para que me envolvieran un regalo, y escuché que una señora le preguntaba a la muchacha que estaba atendiendo "¿Eso es un nombre o un apellido?", mientras apuntaba a la plaquita con el nombre que la chica tenía en su chaqueta. "Es un nombre" fue la respuesta algo tímida. "¿Y cómo se pronuncia eso?" contraatacó la clienta haciendo alarde de innegable diplomacia. La muchacha no se dejó impresionar y con total cortesía le dijo "Gwendolyne" (léase "Güendolín"), que fue recibido por parte de la preguntona con cara de "pobrecita, qué padres tan malignos te tocaron". En ese momento, yo que había sido testigo de todo el diálogo, que hacía rato que había leído el nombre, y que ya sabía perfectamente que Gwendolyne se decía Güendolín, no pude resistir mis más bajos instintos de metomentodo y lancé como quien no quiere la cosa "Ese es el nombre de una canción de Julio Iglesias, de cuando recién comenzaba a hacerse famoso..."

La cara de la muchacha, bueno... de Gwendolyne, se iluminó mientras me decía "¡Es por eso, es por eso, por esa canción me pusieron el nombre!", y por poco se pone a aplaudir mientras agregaba "¡En todos estos años es la primera vez que alguien sabe de dónde viene mi nombre!". Sonreí, y no sé si ya por vergüenza o por temor a que se desmayara, no me animé a confesarle que hasta me sabía casi toda la letra de la canción. Sobre todo, recordaba los últimos versos:

Le he pedido al silencio que me hable de tí,
He vagado en la noche queriéndote oir,
Y al murmullo del viento le he oido decir,
Tu nombre, Gwendolyne.


(Recuerden que es Güendolín y no Güendolain, porque sino no rima)

Los PanchosEsto mismo se lo contaba ayer en el trabajo a la hora del almuerzo a Mayda, Armin, y algunas otras personas de esas que todavía no tienen blog (y cuyos nombres omitiré precisamente para no dejarlos en evidencia), y fue necesario explicar que conocía la canción porque cuando era chico, mis viejos tenían ese disco (un simple) y lo había escuchado infinidad de veces y hasta me la había aprendido. Sí, ya sé, ya sé... pero hay que tener en cuenta que en esa época yo era apenas un niño influenciable, que en aquel entonces lo único parecido a un diyei (o a emtiví) eran Carlos Silva y el Sr. Bello de Aquí Está su Disco: ¡ni siquiera habían aparecido todavía los Impactos de Berch, el Gordo Mullins, y toda esa onda! Por otra parte, en la casa de dos inmigrantes gallegos como eran mis padres, lo que había para escuchar, eran discos de Zarzuela, de Miguel Fleta, de Nat King Cole, de Antonio Machin, del Trío Los Panchos, de Javier Solís, y entre todo eso, aquél Julio Iglesias que recién comenzaba su carrera, mucho antes de futuros bamboleiros y agua salá, digamos que era de lo más rescatable. Así que sí, lo confieso: mi nombre es José Lamas, y de chico me gustaba Julio Iglesias. Ahí está, ya lo dije; ahora me siento mejor.

Mayda y Armin (y aquellos otros) aún me miraban como preguntándose de qué corno les hablaba, así que seguí contando que, según yo recordaba, Julio Iglesias había representado a España con esa canción en el festival de Eurovisión de 1970, y que fue a partir de ahí que comenzó a hacerse famoso. Mayda incluso me pidió que le tarareara una parte a ver si ubicaba la canción y simulé hacerlo en su oido. Mi vergüenza era tanta que la voz apenas me salía y estoy seguro de que ni se escuchaba ni se entendía nada, pero como ella es muy comprensiva y ante todo es una dama dijo "ah, sí, sí" e hizo como si le hubiera dado el mejor recital.

Luego hice lo que solemos hacer después de conversar o discutir de algo durante el almuerzo, que es buscar más información en internet, y ahí comenzó lo que para mí fue más interesante. Nunca dejo de sorprenderme de las cosas que uno puede llegar a encontrar en internet. En primer lugar, yo recordaba que teníamos el disco, tenía una vaga idea de cómo era la carátula, pero no imáginé que tan rápidamente la iba a encontrar; cuando la vi la reconocí inmediatamente y fue como una bocanada de infancia, como cuando uno de pronto y en el lugar menos pensado respira ese aroma que te lleva a la casa de la abuela a tus cuatro años y ya se fué y por más que aspires para todos lados no lo volvés a encontrar pero te quedó el gustito y qué lindo.

También me enteré de que había sido arquero de las inferiores del Real Madrid hasta que un accidente automovilístico a los 20 años lo dejó semiparalítico por un año y medio, y que como se la pasaba escribiendo poemas tristes y románticos, un enfermero le regaló una guitarra para que se entretuviera, y se puso a componer canciones. Propongo hacer una colecta para regalarle una guitarra a Carini.

Ganó el festival de Benidorm en 1968 con "La vida sigue igual" y luego se presentó con "Gwendolyne" a Eurovisión en 1970, y aunque no lo ganó como yo creía sino que salió cuarto, grabó el disco y ganó mucha fama. Por supuesto, encontré el video de esa presentación, y pude rememorar la canción completa.




Al parecer era un tipo tan nervioso que no sabía que hacer con las manos y se las ponía en los bolsillos del saco. Para una de las manos lo resolvieron poniéndole un micrófono, pero para la otra alguien tuvo la brillante idea de hacerle un saco sin bolsillos. Capaz que así fue como empezó con esa manía de tocarse el ombligo: el tipo arrancaba a poner la mano en el bolsillo y a mitad de camino se acordaba que no había, y seguía de largo hasta el ombligo para disimular. Igual que cuando uno arranca a saludar con la mano y al darse cuenta que no era la persona que creía sigue de largo y hace como que se acomoda el pelo. O como en mi caso, que al llegar ahí recuerdo que el pelo ya no está y entonces hago como que lo que quería era rascarme el cuero cabelludo. ¡Eso es saber disimular!

Supe también que la tal Gwendolyne al parecer era una chica holandesa que vivía en París, de apellido Bollore, que conoció en Cambridge, Inglaterra (¡es todo tan europeo esto, tan Hola!), y que fuera su novia por un tiempo. ¿Qué será de la vida de esa Gwendolyne? La busqué en Facebook pero no la encontré. No puedo creer que nadie sepa a dónde fue a parar la verdadera dueña del tunombre güendolín.

Ese video del festival de Eurovisión nunca lo había visto, y aunque me sirvió para recordar la canción completa, ustedes dirán que soy un inconformista (si quieren, sino no digan nada que da igual), pero había algo que no me convencía del todo. Era la misma letra, la misma melodía, pero como que no era la misma voz: la del video me sonaba como más aniñada de lo que yo recordaba. No sé bien qué, pero algo no cerraba. Al principio pensé que era simplemente una trampa de mi memoria, que a lo largo de los años había perdido fidelidad en el recuerdo, y por eso al encontrarse con el original ya no coincidían. Eso hasta que logré este otro increíble hallazgo, un video que parece que lo hubiera grabado yo mismo de niño para poder encontrarlo ahora, y entonces sí: ¡Alcoyana, Alcoyana! y todo cierra. El disco, la pila de long plays detrás, ¡si hasta el tocadiscos se parece! Ahora sí la voz es la misma, el ruidito de la púa, todo, todo vuelve a su lugar.



Tu nombre, Gwendolyne. ♦
Leer más......

miércoles, 8 de octubre de 2008

GeneXus User Controls Open Source

panel de control inalámbrico para inodoroImagen: Panel de control inalámbrico para inodoro en Japón. Tomada por el usuario Chris 73 de Wikipedia y disponible libremente aquí bajo licencia creative commons cc-by-sa 2.5. (tiene una pantalla de cuarzo y 38 botones, pero lo que más me gustó fueron los dibujitos de la parte superior)

Así como existe un lugar para el desarrollo de GXextensions, desde ayer contamos también con un espacio equivalente para los GeneXus User Controls en modalidad open source.

Por el momento hay allí solamente dos controles, el Captcha y el DolphinStyleMenu, pero seguramente aparecerán muchos más en el corto plazo.

Por supuesto, quienes deseen colaborar mejorando estos proyectos o agregando controles nuevos son bienvenidos. ♦ Leer más......

martes, 7 de octubre de 2008

Extensiones Open Source para GeneXus


Desde hace un tiempo existe un espacio en Assembla.com que contiene proyectos de GXextensions open source. Además de servir como ejemplos de cómo escribir módulos adicionales para GeneXus, permite administrar y desarrollar estos proyectos en forma colaborativa.

Hay en este momento ocho extensiones: Community, DailyDilbert, ExploreFolders, GXCmdPrompt, KBDoctor, OpenTableData, RemoveFilesOnDelete, y ViewRelatedFiles. Todos los fuentes de estos proyectos se pueden inspeccionar o descargar desde aquí. Pero sin duda la opción más interesante es utilizar el repositorio Subversion, para armar cualquiera de estos proyectos en nuestra máquina, experimentar haciendo mejoras o arreglos, y contribuir con esos cambios al proyecto común.

En el equipo de desarrolladores están ya los creadores de esos proyectos (Armando Cardoso, Enrique Almeida, Glauber Weddigen, y Marcos Crispino), pero quienes quieran sumarse para hacer alguna mejora, subir una nueva extension, o simplemente experimentar, también pueden hacerlo. Una vez registrados en Assembla.com (es gratis), alcanza con ir a la página principal del proyecto y usar el link "Join this space" en la esquina superior derecha. ♦ Leer más......

martes, 22 de abril de 2008