Futuro de los selectores y líneas de producto

Futuro de los selectores y líneas de producto

12:46 0 Comments

Como posiblemente ya sepas, los selectores son el pilar central del sistema de plastic. Al empezar a trabajar en una rama, selecciona botón derecho en el menú de cambiar a rama, al hacer esto, por detrás se está configurando un selector.

El selector parece muy complicado al principio, y por eso hemos intentado esconderlo un poco tanto con las ramas inteligentes, cambiar a rama y cambiar a etiqueta.

Los usuarios avanzados se familiarizan rápidamente con el selector y es cuando le pueden sacar el máximo partido al sistema de múltiples repositorios, de múltiples servidores, etc.

Pero mi principal preocupación ahora es si hay algún modo de hacer que los selectores sean fáciles de utilizar para los nuevos usuarios.

He estado leyendo sobre Ruby las últimas dos semanas y me gusta lo simple pero potente que es.

¿Qué pasa si escribimos los selectores en Ruby? :-) Me temo que aún no es posible, pero me gustaría hacer que los selectores fueran más fáciles de entender.

Así que mi primer intento fué mejorar el editor de los selectores. He estado hablando con varios usuarios de plastic sobre diversas posibilidades. Una de ellas es crear algún tipo de asistente que ayudaría a los usuarios a designar los selectores. Es posiblemente la mejor opción pero quise explorar alternativas diferentes.

la alternativa más sencilla era la de mantener el código centrado pero consiguiendo mejorar el editor. Y aquí tenéis un par de capturas.



Bueno, lo único nuevo que se puede ver aquí es que el editor resalta la sintáxis. No es un gran paso, eso está claro, pero ayuda.

Lo bueno es que además da la posibilidad de completar el código para los repositorios, ramas y etiquetas.



¿Mejor? Supongo que facilitará las cosas.

Pero el lenguaje mágico que definimos para los selectores es aún muy complicado.

Mirad el selector por defecto:

  repository "codice"
    path "/project/doc"
      branch "/main/doc"
      checkout "/main/doc"
    path "/"
      branch "/main/task001"
      checkout "/main/task001"

¿Qué significa?

Vamos a escribirlo de nuevo con una sintaxis diferente (just adding some syntactic sugar)

   use repository "codice"
     if path starts with "/project/doc"
       download code from branch "/main/doc"
       check out at branch "/main/doc"

     if path starts with "/"
       download code from branch "/main/task001"
       check out at branch "/main/task001"

¿Mejor?

¿Te parece demasiado detallado? Si es así, podrías saltarte parte de la sintaxis o incluso pasar a sintaxis encriptada.

Lo bueno de la opción basada en if es que es más cercana al código, lo cual al final significa que se parece más a lo que estamos acostumbrados, ¿no?. Además, muestra claramente (espero) que hay un orden importante en las reglas del selector. El sistema intentará cargar la primera regla, después la segunda, y así consecutivamente. Esto no está tan claro con el selector actual.

En vez de sintaxis de descarga se da una opción más clara de leer/escribir que nos ha proporcionado Keith (¡un usuario de toda la potencia de plastic!):

  use repository "codice"
   if path startswith "/project/doc"
     read from branch "/main/doc" //"from" is optional
     write to branch "/main/doc" //"to" is optional
   else if path startswith "/"
     readwrite branch "/main/task001"

Puede incluso ser más corto (de nuevo sería más dificil para los nuevos usuarios pero los avanzados no tendrían ningún problema) reemplazando leer(read) por r o rw para leer y escribir (readwrite).

Creo que esta nueva sintaxis facilita mucho las cosas.

Pero aún creo que no es suficiente.

Una sintaxis realmente buena ofrecería incluso más posibilidades. Veamos lo siguiente:

  use repository "codice"
    if path starts with "/code"
      find revisions where
        attribute='status' and
        attrvalue='validated' and
        branch = 'br:/main/task001'
    default
      readwrite branch "/main"

¡Se podría incluso ir más allá!

Podrías definir en el selector consultas muy complejas. Recuerda que, al final, el selector es tan sólo un árbol que quiere decir "esto es lo que puedes descargar en tu espacio de trabajo". Si encontramos la sintaxis adecuada, incluso basa en código, los desarrolladores podrían escribir selectores avanzados para mapear sus repositorios en sus espacios de trabajo, realmente dando forma al contenido como quieran.

¿Hay algún motivo? ¿Por qué necesitarías darle forma a tus repositorios de manera diferente? ¿Para qué habría que crear estas variaciones?

Hey! ¿Dije variaciones? Si, eso dije. Entonces podríamos estar entrando en el mundo de líneas de producto. Leí sobre este tema por primera vez hace mucho tiempo (check Greenfield & Short book on software factories) y desde entonces siempre me ha preocupado cómo ayudar a gestionar familias de productos utilizando gestión de la configuración. Desde luego que las configuraciones de múltiples repositorios ayudan (puedes pasar a desarrollo orientado a componentes) pero no es suficiente.

Hay varios artículos sobre este tema, pero me pregunto si los selectores son el modo de trabajar aquí.

Supongamos que tienes algún tipo de catálogo central en el que almacenar las variaciones aprobadas de diversos componentes. Entonces podrías utilizar el selector para configurar un proyecto nuevo, seleccionando los componentes necesarios junto con sus versiones. Los componentes no tienen por qué limitarse a ficheros y directorios bajo el mismo árbol de directorios sino que podrían estar en diversos árboles y agruparse utilizando, por ejemplo, atributos, etiquetas o cualquier otro mecanismo.

Si, aún queda mucho por hacer, pero... ¡estamos haciendo los deberes!