Feeds:
Entradas
Comentarios

Archive for the ‘Análisis’ Category

A día de hoy comienza el ciclo #6 del desarrollo. En este ciclo se ha tratado de atender a las peticiones de los usuarios recogidas en la encuesta y se va a implementar la posibilidad de tener múltiples pestañas. La finalidad es poder tener diferentes terminales abiertos en la misma ventana y que el panel lateral sirva de vista previa para los archivos del terminal que se encuentre activo.

Se tratará de utilizar un modelo parecido al que se encuentra en Gnome-terminal o Firefox, permitiendo la creación de pestañas tanto mediante el teclado como utilizando el ratón. Como parte complementaria a esta funcionalidad, se va a implementar el menú de la aplicación. En un principio, se va a añadir únicamente la posibilidad de cerrar la aplicación y crear y cerrar pestañas.

Read Full Post »

Tras unos días con la encuesta de funcionalidades futuras activa, se ha decidido analizarla para hacernos una idea de lo más demandado. En total se han contabilizado 102 votos. A continuación se muestra las 4 funcionalidades que más interés han generado:

  1. Integración con ssh para permitir previsualizar directorios remotos 17.65%
  2. Multipestaña para permitir múltiples terminales 15.69%
  3. Interacción con el panel lateral utilizando el ratón (copiar, pegar, crear carpetas) 12.75%
  4. Fichero de configuración para la carga permanente de opciones 12.75%

Como vemos, la integración de la previsualización con ssh ha sido la más votada, seguida de cerca por la opción de multipestaña. Cuando se finalice el ciclo #5 de desarrollo, se dará prioridad a las características que han tenido mejor acogida. Los resultados completos de la encuesta siguen estando accesibles desde su entrada correspondiente.

Read Full Post »

Tras abordar los dos primeros ciclos del proyecto, se ha llegado a la conclusión de que el análisis inicial realizado no respondía a la que al final ha ocurrido en la implementación. La inexperiencia en la gestión de proyectos y planificación de proyectos puede ser la causa.

A pesar de ello, si se examina la lista de funcionalidades inicial ideada, los ciclos 1, 2, 3 y 5 han sido completados. Es lógico por tanto continuar con la implementación del ciclo 4: subshell con reconocimiento de cambios de directorio.

Tal y como se comentó en un post anterior, la subshell será implementada utilizando como base el código fuente de bash e integrando en él el código del proyecto. La intención es que cada cambio de directorio sea notificado a TP::Previewer para que actualice y muestre en un panel lateral las vistas previas de los archivos de la ruta actual.

En lo respectivo a mostrar un panel, se prevé  implementación de un terminal virtual con libvte y mostrar los archivos previsualizados haciendo uso de un panel convencional de GTK+.

Read Full Post »

Tras bastante tiempo sin escribir, vuelvo para comentar algunas decisiones tomadas en el desarrollo y que influyen profundamente en el diseño del proyecto.

En el ciclo 2 de la iteración estoy dedicando el tiempo a implementar la creación de las vistas previas de los archivos  y el mostrado de dicha vista previa para un único archivo introducido por línea de comandos. Tal y como se pensó al principio, la vista previa desaparecería pasado un tiempo determinado. Se ha optado por desechar esta idea y cerrar la vista previa cuando se pulse cualquier tecla. De esta manera se agiliza y se posibilita la previsualización de archivos individuales de forma veloz.

Ahora bien, la ejecución alternativa del programa consiste en lanzar una subshell que lea los comandos introducidos y los ejecute de forma normal. Lo que se añade es la visualización de un panel de escritorio externo a la consola y que muestra las vistas previas de los archivos de la carpeta actual de trabajo. De cara a la implementación, esto implica crear una subshell capaz de reconocer comandos de cambio de directorio, ejecutar cualquier tipo de comando y muchas más complicaciones. Teniendo en cuenta que se pretende obtener un resultado decente, se han estado considerando diferentes alternativas.

La más factible y que daría un resultado muy bueno es la utilización del código fuente de Bash, el intérprete de comandos por defecto en la mayoría de los sistemas Unix. Tras probar a descargar y compilar el código, se ha comprobado que no tiene dependencias (o al menos no ha dado ningún problema en el sistema de trabajo actual). Esto resulta de gran interés a la hora de reutilizar su código para añadirle mejoras. En nuestro caso, la mejora a añadir será la comunicación con la aplicación C++ que muestre las vistas previas del directorio actual de trabajo.

La alternativa que se acaba de explica presenta ciertos retos que no se prevén complicados de solucionar. El primero es la llamada a código C++ desde el código fuente de Bash, escrito al completo en C. El segundo es la definición de las interfaces de comunicación entre ambas aplicaciones para evitar la introducción del código C++ de la aplicación en el código C de bash y complicar la compilación. Tras realizar una pequeña prueba, se ha conseguido invocar una función C++ (que no formaba parte de ninguna clase) desde el código de bash, y al ejecutar la terminal el funcionamiento ha sido el esperado.

En definitiva, se pretenda realizar una incorporación de Terminal Previewer al código fuente de Bash y eliminar así los problemas para la creación de una subshell de una cierta calidad. Aunque en este ciclo no se va a realizar ningún esfuerzo en este tema, considero de gran importancia para el proyecto la decisión tomada.

Por último, mencionar que se está trabajando en la persistencia de las vistas previas en el disco duro para su reutilización en un momento cercano en el tiempo. Además, se han realizado avances en la generación de vistas previas de archivos de imagen, vídeo y audio.

Read Full Post »

Conforme a lo planificado, en el ciclo #2 del desarrollo se trabajará la previsualización de archivos introducidos por línea de comandos. Al pasarle un único archivo como argumento al programa, éste mostrará durante un tiempo determinado una ventana con la previsualización del archivo.

Sin embargo, este ciclo puede llevar más tiempo del deseado. Esto es debido a la necesidad de implementar 2 funcionalidades que en un principio se pueden ver como una sola, tal como refleja la lista, pero que entrañan una dificultad considerable:

  • Detección del tipo de archivo y creación de la vista previa acorde al tipo
  • Visualización de la vista previa generada

La primera de ellas conlleva un esfuerzo extra, ya que implica la utilización de diferentes utilidades y librerías para la obtención de vistas en miniatura para cada tipo de archivo. Dependiendo del tipo de archivo, se mostrará lo siguiente:

  • Imágenes: miniatura
  • Audio: reproducción desde un punto determinado (inicio o medio)
  • Vídeo: gif animado con capturas
  • Texto: resumen del fichero (número de líneas, palabras, etc…)
  • Pdf: gif animado con páginas
  • Código fuente: lenguaje de programación y líneas
  • Archivos comprimidos: número de archivos y algoritmo de compresión

Como es evidente, en la lista de tipos de archivos no se mencionan gran parte. Se pretenderá dar cabida al mayor número posible de ellos, potenciando en un principio los anteriores.

En cuanto a la segunda tarea, se necesita incorporar a la aplicación una pequeña ventana gráfica que muestre la vista en miniatura obtenida. Se utilizará la librería gtkmm (GTK para C++). Debido al desconocimiento de los bindings utilizados por ella, se necesitará un tiempo extra de aprendizaje.

Como se puede ver, el tiempo previsto para un único ciclo de desarrollo es demasiado grande. Sin embargo, existe una gran dependencia de las dos subtareas descritas. Por tanto, se realizarán de forma conjunta aunque ello conlleve un tiempo mayor.

Se procederá en breve a la descripción e implementación del test correspondiente al ciclo #2.

Read Full Post »

La lista inicial de funcionalidades, ordenada por importancia, es la siguiente:

1. Reconocimiento de opciones introducidas por línea de comandos.

2. Previsualización de un archivo individual introducido por línea de comandos
junto al nombre del ejecutable.

3. Previsualización de un número de archivos indefinido introducidos por línea de comandos junto al nombre del ejecutable.

4. Subshell con reconocimiento de comandos de cambio de directorio.

5. Creación de vistas preliminares en base al tipo del archivo.

6. Mostrado de vistas preliminares cuando se realice un cambio de directorio.

7. Control del panel de previsualización mediante comandos de teclado.

8. Configuración del entorno de previsualizado mediante línea de comandos y archivos de configuración.

9. Persistencia en las opciones de configuración.

10. Selección de archivos del panel mediante el ratón y ejecución de acciones sobre ellos mediante línea de comandos.

11. Panel complementario para la previsualización de directorios en tiempo real mientras se introduce su nombre por línea de comandos.

Read Full Post »

Considerando que el desarrollo del proyecto lo voy a realizar de forma individual, la elección de una metodología de desarrollo “pesada” podría llevar más trabajo del necesario para coordinar a .. un programador. En realidad, la intención es utilizar una metodología que permita la adaptación a cambios rápidos en los requisitos e incorporar nuevas funcionalidades de forma fácil y sin necesidad de llevar a cabo una reestructuración completa del proyecto.

Con esta premisa, he estado investigando sobre diferentes metodologías de las llamadas “ágiles”. El adjetivo que las califica ya dice bastante de ellas. Sin embargo, englobadas en esa categoría se encuentran muchas y muy variadas, aunque todas ellas mantengan una base común.  Por su frecuencia de utilización y su importancia, he reducido el abánico de posibilidades a únicamente 3: Scrum, eXtreme Programming y Test-Driven Development.

De las 3 candidatas, me decidido por utilizar la tercera, Test-Driven Development o Desarrollo guiado por pruebas. Cada ciclo de desarrollo se compone de los siguientes pasos:

  • Se elige una funcionalidad que esté pendiente de implementar
  • Se escribe un test que ponga a prueba el funcionamiento de dicha funcionalidad
  • Se comprueba que el test falla para el código existente actualmente
  • Se implementa el código estrictamente necesario para pasar la prueba, sin necesidad de tener en cuenta futuras ampliaciones o modificaciones
  • Se ejecutan todos los tests: el escrito al comienzo del ciclo y los de ciclos anteriores, comprobando que todo funciona correctamente
  • Se refina el código escrito, teniendo en cuenta que el código siga pasando los tests
  • Se actualiza la lista de funcionalidades pendientes, borrando la ya implementada u otras que hayan sido abarcadas por esta e introduciendo nuevas posibles funcionalidades detectadas durante el último ciclo

Del ciclo de desarrollo se desprende la necesidad de crear una lista inicial de funcionalidades pendientes de ser desarrolladas, la cual será la primera “piedra” de este proyecto. Dedicaré la próxima entrada del blog al diseño de la lista y la elección de la primera funcionalidad a implementar en el ciclo #1 del desarrollo.

Read Full Post »

Older Posts »