Todos sabemos qué son los calendarios: un lugar donde apuntar lo que estaremos haciendo en un día determinado para poder planificarnos. También conocemos sus limitaciones: si se trata de un objeto físico que llevamos siempre encima para que nos sea útil, nadie más podrá apuntar o consultar nada en él (especialmente problemático para gente a quien le asignan citas o reuniones). Por el contrario, si lo dejamos en la oficina para que otras personas puedan apuntar o consultar, seremos nosotros mismos quienes no sepamos qué tenemos que hacer en el transcurso del día o en los días venideros. Lo mismo se aplica si se trata de un archivo almacenado en un ordenador. Estos dos problemas hacen que un calendario no sea todo lo útil que debería ser, hasta el punto que pierde sentido utilizarlos.

Cuando se trabaja con varias personas se hace muy necesario estar coordinados, y en este sentido, compartir un calendario con las fechas clave, es vital. ¿Cómo conseguir compartir con todos los miembros del equipo un mismo calendario y ahorrarnos los dos problemas comentados anteriormente? Pues aprovechando algo que la mayoría de lectores habituales de blogs conocen: la sindicación de contenidos. Esta tecnología de distribuir y recibir información mediante los lenguajes xml, ical o similares permite a una o varias personas con los permisos oportunos añadir citas, reuniones, eventos… en un mismo calendario y que éstos aparezcan automáticamente en nuestro ordenador, portátil, teléfono o dispositivo móvil con la garantía de estar siempre todos sincronizados.

Los programas y servicios que ofrecen la opción de compartir calendarios son muchos, basta fijarse en que ofrezcan opción a exportar e incorporar los formatos de sindicación para calendario más habituales: ical, xml o html, como por ejemplo sunbird, lightning para thunderbird, iCalendar, Outlook… o calendarios online como google calendar, yahoo calendar…

Todo esto ofrece una ventaja derivada: podemos suscribirnos a calendarios públicos que tengan alguna relevancia para nosotros, como por ejemplo la agenda de eventos de +arquitectura, que permite estar al corriente de eventos, concursos y efemérides arquitectónicas en tu propio calendario sin tener que hacer nada más que añadir el enlace y esperar a que se actualicen automáticamente y nos envíe (si así lo hemos indicado) recordatorios cuando la fecha esté próxima.

Plantillas

Se trata de un archivo que se crea una sola vez y servirá para generar el resto de archivos. El concepto es que una vez se esté trabajando en un archivo basado en esa plantilla no se tenga que invertir el tiempo en crear nada más, tan solo en proyectar y dibujar. Será un archivo aparentemente vacío, pues no contendrá elementos de dibujo pero tendrá la información siguiente:

• Capas: estarán todas creadas y definidas (en algunos programas deberemos asignar colores, espesor y tipo de línea… a cada una de las capas).
• Combinación de capas: la mayoría de programas permiten actualmente guardar combinaciones de capas; se trata de que pensemos las situaciones más habituales de trabajo y guardemos el estado de capas (activas, ocultas y/o bloqueadas) para cada caso. Tener esto bien definido nos ahorrará mucho tiempo en activar y apagar capas una a una.
• Textos: se definirán todos los estilos de texto, con propiedades de altura, tipografía, estilo, escala en la que se mostrarán…
• Tipos de línea: se cargarán únicamente los tipos de líneas a utilizar y, tras comprobarla, se definirá su escala
• Estilos de cotas: se aplica lo mismo que en los textos.
• Carátula: (merece un artículo a parte, hablaré de ello próximamente)
• Otros: Algunos programas hacen una revisión de estándares, al hacer la plantilla podemos crear un archivo patrón con la misma información que nos servirá para verificar esos estándares (leer este post en el foro de +arquitectura)

Una de las ventajas de basarse en una plantilla es también un inconveniente: su único cometido es ahorrar tiempo para no tener que repetir una y otra vez procesos reiterativos, lo cual no supone ninguna rigidez (en realidad siempre que creamos un archivo nuevo se está basando en una plantilla, que está siempre vacía). Esta flexibilidad implica entonces que siempre se podrán crear nuevas capas, estilos de línea… y por lo tanto introduciendo la desorganización en el archivo. De todas maneras ya hemos reducido enormemente gran parte del problema, pues supone más trabajo crear capas que se salgan de la estructura que elegir una que ya está creada. Para remediar la posible desorganización pasaremos a la siguiente fase: el uso de estándares de CAD (hablaré de ellos próximamente, pero si alguien tiene interés puede leer este post en el foro de +arquitectura)

Autor: Carlos Cámara Menoyo
Fecha: Julio 2007
Permalink: ver enlace original
Contexto: Fragmento adaptado para este blog de un informe de asesoramiento de gestión de procesos realizado por encargo de MAP Arquitectes.

Mantener un orden de archivos y seguir un patrón al darles nombre que nos permita saber en todo momento y de manera rápida qué es lo que contienen cobran una importancia vial.

Este artículo se centrará en dar unos criterios para crear un código propio para nombrar los archivos de manera eficiente que nos permita saber el tipo de información que contiene, su versión, el proyecto al que pertenecen…

Versiones anteriores
Soy partidario de no eliminar archivos antiguos, ya que el proceso proyectual a veces nos obliga a volver a soluciones que anteriormente habíamos desechado pero que por algún motivo vuelven a tener validez, eso origina un gran número de archivos y ponerles un nombre adecuado para identificar cual es la versión válida con la que deberemos trabajar puede ser complicado. Un sistema sencillo para identificarlos es añadir un número al archivo que nos permita identificar su número de versión. Sin embargo antes de aplicar este método tan sencillo en apariencia cabría hacer algunas consideraciones: ¿lo añadimos como prefijo o como sufijo? ¿la última versión será siempre la de número más alto? ¿cuantas versiones podemos tener de un mismo archivo?

Por defecto, los sistemas operativos suelen ordenar sus archivos alfabéticamente, lo que puede hacer desaconsejable añadir un prefijo que determine el número de versión al nombre de archivo: si tenemos tres archivos (A, B y C) y cada uno tiene un par de versiones (1-A, 2-A, 1-B, 2-B, 1-C, 2-C) al ordenarse alfabéticamente el orden sería este: 1-A, 1-B, 1-C, 2-A, 2-B, 2-C… y así sucesivamente. Los archivos se mezclarían y estarían ordenados por el número de versión.

La tendencia habitual es la de ir añadiendo números a la última versión y cuanto más elevados sean será sinónimo de tener una versión más actual. Esto conlleva un problema cuando se trabaja con archivos vinculados o referenciados: al añadir un sufijo, el nombre del archivo cambia, y por lo tanto el vínculo se pierde o no se actualiza. Cambiar el vínculo no suele suponer mucho engorro pero es algo que no se debería hacer más que una sola vez (esa es la filosofía de los archivos vinculados al fin y al cabo). Una buena opción para evitar ese problema es que la última versión sea siempre la única que no tiene sufijo, y las copias serán las que se numeren. Cuanto mayor sea el número, quiere decir que la copia es más actual.

Otro sistema podría ser añadir una fecha al archivo, si bien esta información es redundante por estar en las propiedades de cada archivo, es mucho más fácil y rápida de leer. Pueden aplicarse las mismas reflexiones hechas anteriormente.

Nombre del proyecto
Una opción interesante que puede facilitarnos el nombre de archivo es la de informar acerca del proyecto al que pertenecen. Esta información puede parecer algo redundante, pues los archivos suelen estar emplazados en un directorio que contiene esa misma información, sin embargo la experiencia dice que a veces los archivos no están en el sitio donde deberían estar (máxime si intercambiamos varios emails con nuestros colaboradores). Si a los proyectos les añadimos un código y a cada archivo le dotamos de ese código, será evidente si un archivo está fuera de su localización y será muy fácil moverlo al lugar correcto.

Información del contenido
Este es quizá el aspecto más evidente del nombre de un archivo, pero no por ello menos importante: el archivo debe informarnos de qué tipo de información contiene sin que sea necesario abrirlo para ver si se trata de una memoria, un presupuesto, un plano de instalaciones o un render. Una breve descripción bastará para satisfacer este propósito, sin embargo hay que tener en cuenta que aunque los sistemas operativos actuales permiten escribir nombres de muchos caracteres no hay que abusar de ello. No hay que olvidar que lo que estamos intentando es leer en el menor tiempo posible la mayor cantidad de información posible. Además, se da el caso de que algunos programas no admiten nombres más largos de 21 caracteres + la extensión: si usamos nombres cortos nos ahorraremos problemas de incompatibilidades.
Otro método puede ser establecer un código de letras; puede que al principio sea engorroso y su lectura no sea tan inmediata, pero con el tiempo este sistema puede ser tremendamente eficaz a la vez que rápido.

Otros datos
Algunas personas opinarán que además de todo lo expuesto anteriormente, el nombre de un archivo también debería dar información sobre si se trata de un archivo de arquitectura, ingeniería, urbanización… o de la fase de proyecto en la que se encuentran (estudios previos, proyecto básico, proyecto ejecutivo…), por dar algunos ejemplos.

Consideraciones generales
Llegados a este punto, un error habitual suele ser el de idear un código que trate de dar solución a todos los temas que aquí se han planteado e incluso otros nuevos, lo cual suele ser contraproducente pues resultan en nombres de archivo muy complicados, largos y difíciles de leer. El método utilizado lejos de ser un sistema rígido e inmutable debe de ser lo suficientemente flexible como para permitir mejoras en el tiempo, y para ello será imprescindible hacer un análisis exhaustivo de la realidad de cada uno que permita diseñar un sistema que satisfaga nuestras necesidades tanto presentes como las que preveamos que pueden ocurrir en un futuro no lejano y deseado.

Nombrar los archivos es algo muy personal y no existen fórmulas magistrales: el sistema que nos funciona de maravilla puede no servirle para nada a otro despacho de arquitectura. La experiencia, propia o ajena (este artículo es un ejemplo de ello), será de gran ayuda en estos casos.

Autor: Carlos Cámara Menoyo
Fecha: 14/01/2007
Permalink: ver enlace original
Contexto: A raiz de una consulta en el foro de +arquitectura decidí poner por escrito las reflexiones a las que había llegado respecto este tema durante mi experiencia laboral.