Herramientas Digitales |

Beta de la cuarta version de la web

Tue, 26 Jan 2016 00:00:00 +0000

Quienes conozcan mi web desde hace tiempo y la hayan visitado recientemente habrán notado un cambio profundo en su aspecto, y es que desde el 1 de enero de 2016 hice la cuarta re-estructuración radical de mi sitio web. Aunque visualmente los cambios en apariencia son más que evidentes, los cambios son mucho más profundos: Han pasado ya casi cinco años desde que en febrero de 2011 decidiese abandonar mis sitios en wordpress y utilizar la recién estrenada versión 7.0 de drupal. Durante este tiempo ha cambiado mucho el panorama: hoy es necesario tener una web con Responsive Web Design, Drupal es un proyecto mucho más maduro, y mis circunstancias profesionales y personales han cambiado y debían reflejarse también en el sitio. Por otro lado, hacía ya tiempo que estaba pagando la factura de haber construido un sitio web sin apenas una reflexión o buena planificación detrás (en realidad fue mi primer sitio realizado con drupal 7) y hacía que no estuviera bien optimizada o que en los últimos meses fuese imposible añadir nuevo contenido o editar el existente. Todo ello, sumado al hecho de querer poner en práctica algunas buenas prácticas aprendidas en los últimos años (en especial durante mi etapa en Ymbra, a la que le debo mucho como drupalero) exigía un cambio profundo que fuese más allá de las actualizaciones de seguridad y pequeños cambios que hacía periódicamente a la web.

Por todo ello, y a pesar de que me resistía a hacerlo por falta de tiempo (que no por falta de ganas), me decidí a hacer una refactorización completa del sitio (esto es, hacerlo de nuevo) y migrar el contenido existente. Pero sin duda, el objetivo principal era que pudiese tener la web operativa y suficientemente atractiva como para volver a escribir en la mayor brevedad posible, así que empiezo predicando con el ejemplo y a continuación detallo algunos de los aspectos que considero más relevantes del cambio.

Replicabilidad y entornos de trabajo

Una de las cosas buenas que tiene drupal es que además de la separación clásica entre visualización y funcionalidad, también es posible utilizar features[fn]Eso en caso de usar Drupal 7, para quienes ya utilicen la recién estrenada Drupal 8, esta funcionalidad se encuentra ya en core y mejorada[/fn] para convertir las configuraciones a código. La utilización de features y perfiles de instalación permite la creación de una distribución de drupal para fines específicos, algo que hacía tiempo quería poner en práctica. De esta forma, si se combina con un sistema de control de versiones como GIT, puede replicarse inmediatamente un sitio web en distintos entornos, sin tener que recurrir a tediosas configuraciones manuales. Si además todo ello se combina con alias de drush se pueden tener copias idénticas de sitios webs a través de comandos en pocos segundos, lo cual es perfecto para desarollar utilizando distintos entornos de desarrollo. En mi caso desarrollo y pruebo en local, y luego lo paso a mi servidor de producción, aunque no descarto utilizar un entorno de pruebas más adelante.

Me hubiese gustado utilizar un workflow con integración contínua y probar travis o gitlab ci, pero he tenido que posponerlo debido a la complejidad técnica y a que he querido priorizar el poder empezar a escribir de nuevo con la mayor brevedad posible.

Migración

Sin duda esta ha sido la parte más crítica del proyecto. Dado que el sitio web es un sitio nuevo a todos los efectos, no solo era necesario migrar todo el contenido y archivos (mayormente fotos) existentes manteniendo también sus URLS (no querría tener enlaces rotos o perder el SEO que aún me quedase), sino que además, dado que había optimizado los tipos de contenidos unificando tipos[fn]Anteriormente utilizaba tipos de contenidos para fines tan específicos que apenas tenía cuatro entradas en alguno de ellos[/fn] y racionalizando los campos utilizados era necesario mapear cada uno de ellos. Aunque nunca antes había hecho una migración como esta, me sorprendió lo relativamente sencillo (aunque tedioso) que ha sido utilizar los módulos migrate y migrate_d2d. Curiosamente donde he sufrido más ha sido en la migración de comentarios, pues aunque pensaba que utilizar un servicio externo como disqus me facilitaría enormemente la tarea (siempre que mantuviese los paths, algo que hice), la realidad ha sido la contraria y la solución que he utilizado finalmente es algo chapucera.

Workflow

Sin duda uno de los mayores cambios a nivel técnico no se ha producido en la web en si sino en mi forma de trabajar, y es que he querido adaptar un sistema de trabajo similar al utilizado en Ymbra con el que me he sentido tan a gusto (teniendo en cuenta que trabajo solo y que por tanto habrá cosas que no tienen sentido hacer). Básicamente el gran cambio es que en lugar de empezar a desarrollar lo que me apetezca en cada momento, antes de tocar drupal creo una issue en gitlab [fn]Cambiar de plataforma ha sido otro de los cambios: anteriormente utilizaba bitbucket, pero gitlab me enamoró desde el principio, pues además de permitir tener repositorios privados de forma gratuita, o tener una interfaz de usuario muy agradable, ofrece funcionalidades muy interesantes que van más allá de los que ofrece bitbucket. Por suerte, dado que git es distribuido, cambiar de plataforma fue tan sencillo como añadir un nuevo remoto a git.[/fn] que trato de redactar como historia de usuario o bien como historia técnica[fn]Ver la sesión de Scrum que presenté en la DrupalcampSpain de Valencia[/fn] y posteriormente agrupo y priorizo cada issue en varias milestones con objetivos concretos. Puede que parezca un proceso tedioso o que no tenga mucho sentido utilizar si se trabaja solo, pero mi experiencia ha sido tremendamente positiva ya que tiene las siguientes ventajas:

Siempre tengo claro lo que tengo que hacer, incluso cuando pasan largos periodos de tiempo entre desarrollo y desarrollo.
Es una excelente forma de consulta. Aunque pueda sonar un poco enfermizo, las "conversaciones" que tengo con mi mismo en las issues, aportando documentación o comentarios, son una ayuda excelente para que no olvide nada y no pierda tiempo buscando información cada vez que intento solucionar algo.
Cada commit de git está asociado a una issue de gitlab, con lo cual se puede relacionar el log de git con cada issue y viceversa, facilitando el seguimiento del estado de una tarea y haciendo facil la opción de revertir cualquier cambio en caso necesario.
Utilizar estos métodos, hablarme en inglés... aunque no sean muy naturales son una forma de no perder "estado de forma", para el día en el que vuelva a trabajar en equipo.
Permite un sistema de desarrollo iterativo (ver a continuación).

Proyecto mínimo viable y desarrollo iterativo

Como comentaba anteriormente, la reestructuración del site se debía a dos objetivos principales: por un lado poder volver a escribir (apenas escribí nada durante 2015 y eso se debió en gran parte -aunque no exclusivamente- a problemas técnicos), y por otro tener un sitio que mejorase considerablemente a nivel técnico. El problema es que hay tanto por mejorar que, de querer tener resueltos todos los aspectos que quiero desarrollar, me demoraría tanto (especialmente si tenemos en cuenta mi tiempo limitado) que no haría posible cumplir con el primer objetivo. Por todo ello, y gracias al sistema de trabajo utilizado que he descrito anteriormente, decidí salir con un producto mínimo viable que que diese respuesta a las necesidades más básicas al que iría añadiendo mejoras de forma incremental. Una vez asumido que el sitio estará en un estado de casi-beta-permanente, lo demás todo son buenas noticias: con el tiempo se irán viendo las novedades y yo no me agobiaré por tenerlo todo listo a pesar de mi poco tiempo para desarrollarlo.

Theme responsive

He optado por utilizar un subtema de Zen que sea responsive y en el que haya pocos elementos gráficos y prime la facilidad de lectura. De momento, aunque es operativo, es todavía muy mejorable. Todo se andará. Eso sí, el color naranja se mantiene ;)

------------------------

Lo que sigue a continuación es información para friquis/entusiastas (puedes saltar directamente a los comentarios:

+++CHANGELOG+++

2016/01/01: v.4.0-beta1
-------------------------

Re-factorización completa de un sitio web en drupal 7 aplicando features y perfiles de instalación.
Migración de contenido
Theme responsive creado desde cero (subtheme de Zen)

2011/03/08: v3.0
-------------------------

Migración de los dos wordpress (blog y web curricular) a una sola instalación de drupal.
Cambio de arquitectura, diseño y funcionalidades de la web.

Gestor: Drupal 7 (una sola instalación para blog, web curricular y lo que se preste )
Diseño: plantilla provisional modificada a partir de la plantilla Bartik

2008/12/??: v2.1
-------------------------

cambio ligero en el diseño y creación de otro blog instalado en la raiz del dominio para gestionar únicamente aspectos curriculares, utilizando exactamente la misma apariencia gráfica que el blog existente.
Este sistema surgía de la dificultad de mantener actualizado mi CV con la página HTML ya que permitía tener uno fácilmente actualizable, tal y como ya hacía con el blog.

Gestor: dos instalaciones independientes de Wordpress 2.7, una para el blog y otra para la web curricular
Diseño: Plantilla modificada ligeramente para
- aprovechar nuevos widgets
- ampliación del ancho de sidebar derecho
- se añade botones de compartir en la red

2007/12/??: v2.0
-------------------------

migración de carloscamara.es al gestor de contenidos Wordpess en una subcarpeta "/blog".
Utilización de wordpress para gestionar el blog, enlaces a otras webs, categorizar entradas... se mantiene el sitio HTML en la raiz del sitio para la web curricular.

Gestor: Wordpress 2.0 "Duke" (blog)
HTML para web curricular (sigue sin alteraciones)
Misma plantilla CSS (sigue sin alteraciones)

2006/12/03: v1.0
-------------------------

Creación de un sitio web en HTML que combina la integración de un blog realizado en Blogger con la misma plantilla gráfica.
Este método permitía tener un sitio dinámico que permitiese comentarios y actualizaciones constantes conuna misma apariencia gráfica y sin tener conocimientos de programación.

Gestor: Blogger (blog)
HTML para web curricular
Misma plantilla CSS

2006/05/??: v0.1
-------------------------

Tras la experiencia de haber desarrollado +arquitectura y gracias al empujón de una iniciativa del Ministerio de Industria para que los españoles podamos tener un dominio .es a 1€, nace carloscamara.es como excusa para profundizar en el aprendizaje de HMTL y CSS y para tener un blog propio.

Hacia una cultura de software responsable: reflexiones sobre el aprendizaje de herramientas digitales en arquitectura

Mon, 01 Dec 2014 00:00:00 +0000

A pesar de lo evocadora y prototípica que resulta la imagen del arquitecto trabajando en su mesa de dibujo, con su paralex, sus rotrings y su carboncillo, lo cierto es que hoy en día es imposible concebir nuestra profesión sin medios informáticos. Tanto es así que, actualmente, sería imposible realizar en tiempo y forma toda la documentación gráfica y escrita que requiere un proyecto arquitectónico y todos los trámites burocráticos asociados a él. Sin embargo, las herramientas informáticas no son imprescindibles únicamente por el hecho de reducir tiempos o minimizar errores entre toda la documentación generada, sino también porque proporcionan nuevas formas de expresión sin precedentes.

Así pues, queda fuera de toda duda la necesidad que tenemos los arquitectos de desenvolvernos adecuadamente con las herramientas informáticas, pero ¿cómo aprenden los futuros arquitectos a usarlas? Si bien ya hace más de 15 años desde que se empezaran a ver los primeros proyectos fines de carrera dibujados en CAD, lo cierto es que la inclusión de asignaturas obligatorias en los planes de estudios de arquitectura es relativamente reciente. Este hecho es algo que podemos constatar quienes terminamos la carrera durante la primera década del año 2000 y nos vimos obligados a aprender, por nuestra cuenta y basándonos en el método de ensayo-error, a dibujar en CAD, a modelar en 3D, a hacer renders, a realizar fotomontajes, a imprimir planos… incluso a pesar de la oposición al uso del ordenador de algunos profesores.

Quizá, como reacción a esta posición tan poco pedagógica, la totalidad planes de estudios recientes presentan al menos una asignatura en los primeros cursos en la que se enseñan herramientas digitales. Algunas, incluso, empiezan a tener sus propios laboratorios de fabricación digital. Sin embargo, un análisis más pormenorizado revela que la gran mayoría de estas asignaturas son meramente instrumentales y que, en realidad, solo se enseña, como si de recetas de cocina se tratase, a utilizar programas de dos casas comerciales muy concretas. Quienes defienden esta postura se escudan en que son los programas “más utilizados”, sin siquiera plantearse que los programas más comunes actualmente en nuestro entorno, pueden no serlo en cinco años (cuando los alumnos terminen la carrera) o en otro país (un escenario muy probable para muchos estudiantes).

En mi opinión, se trata de un grave error por varios motivos. El primero es que la universidad no debería enseñar recetas o soluciones a problemas concretos, sino enseñar a pensar y a resolver problemas reales por uno mismo. Por tanto, no aporta ningún valor una asignatura cuya única bibliografía es un manual y que podría ser impartida por un comercial. A la postre, este método deja fuera de forma sistemática tecnologías, alternativas y debates muy necesarios. El segundo motivo es que el verdadero objetivo de cualquier escuela debe ser formar a arquitectos independientes y críticos y, en ningún caso, crear futuros consumidores totalmente dependientes de productos que solo responden a una lógica de mercado. El tercer motivo, y el más importante, tiene que ver con cómo condicionan las herramientas utilizadas a la capacidad creativa y proyectual. En este sentido, soy un convencido de que los programas informáticos y las tecnologías son herramientas y, por tanto, deben servir a quienes las utilizan, en lugar de condicionarles. Y, para que eso sea cierto, es imprescindible que el alumno entienda no tanto los cómos de las herramientas (algo que adquirirá indefectiblemente a través de la experiencia y el tiempo), sino los porqués que le permitan desarrollar su capacidad crítica, que tan útil resulta en tantas áreas de la profesión como de la vida; pero, sobre todo, su propio criterio. Un criterio que sirva tanto en la elección de las mejores herramientas para su casuística concreta (que tiene que ver con cosas tan dispares como los problemas a los que se enfrente, el presupuesto disponible, el tiempo o sus propias capacidades y habilidades), como en la manera de utilizarlas de forma óptima.

¿Cómo se traduce todo esto en una asignatura? Me gustaría poder decir que tengo soluciones sobre cómo debería ser la docencia de este tipo de asignaturas, pero no es así. Ni siquiera tras llevar impartiendo la asignatura Herramientas Digitales en la ETSA USJ desde 2009 he encontrado la fórmula perfecta; así que, año tras año, tengo que ir haciendo ajustes. Y es que la realidad es mucho más compleja que lo expuesto anteriormente, a fin de cuentas intervienen factores como la relación entre mercado y universidad, el papel que juegan o deben jugar los programas de código abierto (y, en general, la cultura abierta; uno de los pilares del FABLAB), los prejuicios que hay en unos y otros… Pero, sea como fuere, las reflexiones anteriormente planteadas no se deben pasar por alto si queremos orientar nuestros pasos hacia la creación de una cultura digital responsable y alejarnos de la enseñanza que crea meros consumidores acríticos.

Nota

Artículo publicado originalmente en el Blog de la Fundación Caja de Arquitectos

Proyecto Tango o qué ocurre cuando un smartphone es capaz de captar el movimiento y el espacio

Sun, 16 Mar 2014 00:00:00 +0000

Hace unos días, un amigo me hizo llegar este vídeo en el que se ve como una persona escanea en tres dimensiones la habitación en la que se encuentra. Esto es algo que ya existe desde hace un tiempo, ya sea en forma de escáneres 3D profesionales como el que tenemos en la ETSA USJ (esperamos poder tener algún resultado publicable en un futuro no muy lejano) o basados en el dispositivo kinect que se utiliza en consolas como Xbox, pero lo que me llamó la atención es que ¡el dispositivo utilizado para escanear es un smartphone!

Como no podía salir de mi asombro y no entendía cómo podía escanearse un volúmen en tres dimensiones con una símple cámara (por mucho que tenga GPS y osciloscopio), busqué un poco más de información y descubrí que se trata de un prototipo de smartphone modificado que incorpora dos sensores que no llevan los smartphones normales (en este artículo de techcrunch explican cómo funcionan) y que forma parte de un proyecto de Google con nombre en código Project Tango, un proyecto que va mucho más allá que el de escanear volúmenes y objetos, pues está orientado en captar el movimiento y el espacio para obtener aplicaciones que no se centren únicamente en el sector de la arquitectura sino también en el de videojuegos, fabricación digital e incluso discapacitados sensoriales, tal y como muestra el vídeo a continuación:

Y a vosotros, ¿se os ocurren casos prácticos en los que vendría bien algo como esto?

“Pensamiento global, actuación local”: Una forma de afrontar los retos de futuro en la educación universitaria de la arquitectura: el caso de Herramientas Digitales

Wed, 11 Sep 2013 00:00:00 +0000

Mientras ordenaba el disco duro de mi ordenador he encontrado el "paper" que envié para las Jornadas Científicas “ARQUITECTURA, EDUCACIÓN Y SOCIEDAD” 2012, en el que se desarrolla un poco más el contenido de la presentación que encabeza este artículo. Me ha parecido relevante compartirlo ahora porque, más allá de explicar el funcionamiento de la asignatura de Herramientas Digitales que imparto en la ETSA USJ desde 2009, la situación que describe al principio del mismo acerca del contexto cambiante y del estado de la enseñanza de la arquitectura sigue siendo vigente y puede (me gustaría) dar todavía mucho debate.

Dado que se trata de un texto relativamente largo he creido conveniente publicar en esta entrada el resúmen y en páginas siguientes iré colgando los distintos capítulos que lo conforman. El texto íntegro puede descargarse en el PDF Original que se encuentra al final de la lectura.

Espero que sea de vuestro interés.

“Pensamiento global, actuación local”,

Una forma de afrontar los retos de futuro en la educación universitaria de la arquitectura: el caso de Herramientas Digitales

Resumen: En un contexto cambiante y convulso como el que está viviendo la arquitectura en estos momentos, son muchas las voces que postulan que la enseñanza universitaria de la arquitectura debería cambiar para adaptarse. Por un lado, está la eterna discusión respecto a cómo adaptar la situación específica española al contexto del Espacio Europeo de Educación Superior (EEES) que hace que en estos momentos coexistan hasta cuatro planes de estudios diferentes en las distintas escuelas de arquitectura españolas. Por otro, están aquellos quienes denuncian un alejamiento entre la educación universitaria y la realidad profesional y que el sector debe replantearse ya desde las propias escuelas.

Lejos de querer entrar en un debate sobre si el modelo de enseñanza universitario debe ser aplicado al mercado laboral o de si este, así como la profesión, deben ser reconsiderados globalmente, la presente comunicación hace gala de la máxima “Pensar globalmente, actuar localmente” poniendo énfasis en los pequeños cambios en el enfoque y metodología que pueden hacer los profesores desde sus respectivas asignaturas teniendo muy claro el contexto global de la profesión.

Para ello se centrará en los aciertos y errores del caso concreto del planteamiento de la asignatura Herramientas Digitales que imparto en la Universidad de San Jorge, una asignatura obligatoria de primer curso que lejos de ser una asignatura instrumental al uso, parte de la premisa de asumir que el uso de las herramientas informáticas son una necesidad y una realidad en el trabajo en un estudio de arquitectura.

Del CAD al BIM (III): comparativa

Wed, 16 Mar 2011 00:00:00 +0000

Continuando con la serie de artículos del CAD al BIM, cuelgo la siguiente presentación que realicé para la clase de Herramientas Digitales como introducción a lo que es el BIM.

Quienes hayan leído los artículos anteriores verán conceptos repetidos, sin embargo esta presentación hace énfasis en la comparativa de ambos conceptos y, sobretodo, en el flujo de trabajo.

Del CAD al BIM (II): problemática I

Mon, 02 Feb 2009 00:00:00 +0000

Y con unas ventajas tan evidentes... ¿por qué no se implanta masivamente?

En el post "Del CAD al BIM" hablaba de las ventajas que supone el uso del BIM frente al CAD, que son numerosas e indiscutibles, sin embargo hay un hecho claro que no se puede obviar y es que, en España, existe un uso masivo y casi monopolista de un único programa de CAD que hace que el uso de los programas BIM sea poco menos que ciencia ficción para la gran mayoría de arquitectos hoy por hoy. ¿A qué se debe todo esto? ¿Por qué no se implanta si tiene unas ventajas tan evidentes? Aunque la pregunta es clara y concisa puede que no haya una única respuesta, sino varias. Una respuesta rápida sería decir que ocurre por desconocimiento: aunque parezca mentira, a pesar de que el concepto del BIM no es para nada nuevo, es todavía algo muy difuso y no existen muchas personas que entiendan sus particularidades y, por tanto, sus ventajas. Si no se conoce la existencia de algo, difícilmente se podrá optar a ello.

Otra respuesta puede ser que las personas que se encargan de comprar las herramientas informáticas no suelen ser las mismas que se pasan la mayor parte del tiempo usándolas y por tanto desconocen la problemática del método de trabajo utilizado y tampoco conocen las soluciones reales que ofrece el mercado. Sus preocupaciones y necesidades son otras muy alejadas.

El precio podría llegar a ser otro impedimento pues podría parecer más elevado que el de los programas de CAD, a pesar de que se trata de conceptos distintos y por tanto difícilmente comparables. En el precio de un programa BIM no solo se está pagando por un programa de dibujo, sino que podríamos llegar a incluir licencias de otros programas como los de mediciones, modelado 3D, renderizado... y sobretodo hay que tener en cuenta la mejora de nuestra productividad y el ahorro en tiempo (y dinero) que eso supone. Si consideramos las horas que nos ahorramos en generar planos, en recuperar versiones antiguas, en coordinar trabajos en grupo, revisión de planos buscando errores, en impresiones... seguro que no parecen tan caros (comparativamente hablando).

Dado que no son pocas las empresas que no entienden la necesidad de adquirir licencias de las herramientas informáticas que utilizan en su día a día existe otro factor ligado con el precio, y es la facilidad (o no) de encontrar versiones "pirata". Si lo que únicamente se tiene en cuenta es no pagar ni un euro por los programas aún a pesar de incurrir en prácticas ilegales está claro cual será la elección: el programa cuya copia pirata sea más fácil de encontrar. Los programas de BIM tienen en la piratería un fuerte competidor ya que se da el caso de que sus copias ilegales no son fáciles de encontrar, por paradójico que parezca.

Otro asunto que no puede obviarse es que los programas BIM están enfocados a hacer edificios. Como muchos sabemos, en el proceso desde que se diseña un edificio hasta que se construye y se vende son muchos los profesionales implicados; los arquitectos somos un pequeño grupo dentro de un sector que compartimos con ingenieros, arquitectos técnicos, delineantes, promotores, constructores... Dado que cada uno de estos agentes tiene unas necesidades muy distintas, el programa que puede convenirle a uno no tiene por qué ser el mejor para otro, y sin embargo se tiene que poder compartir y transmitir la información de unos a otros de forma sencilla para que todos puedan aprovecharla. Hasta ahora se ha optado por usar un programa que no le va mejor a nadie pero que todos entienden, pero existen alternativas a eso que pasan por los formatos de intercambio de datos.

Sin embargo, a pesar de que estas posibles respuestas no son para nada desdeñables esconden una respuesta de nivel superior que no es otra cosa que algo que ya he denunciado en alguna ocasión: la falta de crítica/criterio en general y con el software en particular. Son pocas las personas que realmente se plantean si las herramientas informáticas que utilizan son las más adecuadas para ellos y simplemente se dejan arrastrar por la tónica general. Si realmente nos planteásemos cuales son nuestras necesidades reales, qué necesitamos, cuanto nos cuesta darles solución y pensásemos si podríamos hacerlo mejor, en menos tiempo o con menos recursos la respuesta sería otra. Seguro.

Curiosamente, de todo esto no he oído hablar a ningún arquitecto detractor del BIM. De lo que sí hablan los arquitectos que no están a favor del uso del BIM es de su falta de flexibilidad, de que cohartan la capacidad creativa, condicionan los resultados... y de eso hablaré en el próximo artículo.

Del CAD al BIM

Thu, 08 Jan 2009 00:00:00 +0000

…si los arquitectos nos dejan…

A veces tengo la sensación de que, a pesar de lo que podría esperarse de una profesión creativa, los arquitectos somos reacios al cambio. Hace 15-20 años el sector de la construcción (y con él el de la arquitectura) vivió toda una transformación: el uso de programas de CAD como punta de lanza en la introducción de la informática como herramienta de trabajo principal. Cualquier cambio genera una oposición que será tanto más grande cuanto más de revolucionario tenga éste, y el caso que nos ocupa es un claro ejemplo de ello. Yo no viví lo que supuso abandonar el lápiz y papel en su primera fase, era todavía bastante joven, pero sí que he podido vivir, años más tarde, los resquicios de la oposición que suscitó

Cuando accedí a la universidad, en 1998, el uso del CAD ya era algo cotidiano pero algunos de mis profesores se oponían a su utilización, ya que, decían, “coartan la capacidad creativa y proyectual”, algo que no ocurría con el uso de Rotring o lápiz y papel. No quisiera parar esta vez en un tema que me apasiona: la relación entre herramientas de trabajo, procesos mentales y obra construida. En su lugar recalcar solamente una cosa: me consta que hoy, 10 años más tarde, todavía hay arquitectos que defienden esta tesis, a pesar de que ya nadie se plantea realmente un entorno productivo basado totalmente en lápiz y papel. Actualmente el arquitecto que tenemos en nuestro imaginario no es esa persona sentada delante de una mesa inclinada con papeles vegetales y escuadra y cartabón, ese lugar lo ocupa una persona que trabaja con ordenador y que hasta lo consulta a través de un dispositivo móvil en la obra. Síntoma de que hay un cambio de paradigma que se ha asumido como hecho.

Y es que, ya lo decía Heráclito, nada permanece, todo cambia, algo que es especialmente cierto en el mundo de la tecnología. Lo que antes decíamos que se asumía como símbolo de modernidad ha quedado obsoleto. El CAD tiene que dejar paso al BIM. Nadie discute las ventajas que introdujo el uso del CAD: mejoraba considerablemente la velocidad de trabajo frente al papel, añadía la posibilidad de guardar y recuperar en cualquier momento la información para consultarla o incluso ¡imprimirla!, se podían corregir errores, hacía fácil la representación de elementos complejos en 3D… Tampoco se niega la revolución que supuso, pero si lo miramos fríamente (algo que solo permite hacer la distancia temporal) nos daremos cuenta de que la revolución fue relativa, pues no era más que la evolución lógica del lápiz y el papel: el primero se convertía en un ratón para introducir series de puntos con coordenadas en el espacio y el segundo en una pantalla. En ningún momento se cambió realmente la manera de trabajar, pensar y entender la arquitectura. No ocurre lo mismo en el caso del BIM.

¿Pero qué es el BIM?

Las diferencias entre BIM y CAD son más que notables, aunque a priori no parezca que hay ninguna porque ambos usan la misma máquina y un software muy similar en apariencia. Sin embargo el BIM no es una herramienta de dibujo, aunque sirva (también) para dibujar. Su mayor baza no es que permita trabajar más rápido, sino el almacenamiento de información y la relación que existe entre ella, que al fin y al cabo es de lo que hablan sus siglas: Building Information Modelling (o Modelización de la información del edificio). Esto que parece baladí, no lo es en absoluto pues tiene grandes ventajas, a saber:

Consistencia de los proyectos: cuando se hace un cambio, éste aparece reflejado en planta, alzado, sección... por tanto siempre habrá una consistencia entre todos los documentos que forman el proyecto, algo difícil de conseguir en el CAD. A decir verdad esto ocurre porque solo existe un único objeto: el modelo virtual, y las plantas, secciones, detalles... son representaciones de éste, algo que no ocurría literalmente con el CAD, pues cada uno de ellos eran entidades independientes.
Elementos con propiedades físicas: dado que en lugar de usar líneas, círculos... se representan elementos físicos tales como muros, techos, puertas, ventanas... éstos tienen la particularidad de que pueden dotarse de propiedades físicas tales como materiales, acabados, precios... y luego establer operaciones e informes con ellos.
Bases de datos relacionadas: las propiedades de los objetos se almacenan en una base de dato relacional, de tal manera que conociendo esos datos y el número de elementos que existen con cada una de estas propiedades, se pueden generar informes automatizados de recuentos de elementos constructivos (por ejemplo carpinterías) que además de ser casi instantáneos no darán opción a error y pueden actualizarse dinámicamente (no solo podemos cambiar algo en el plano y se cambiará en el informe sino que si lo cambiamos en el informe también cambiará en el plano)
Gestión de la información: un problema clásico del trabajo en CAD es la enorme cantidad de archivos distintos que se generan, llegando a dificultar enormemente la tarea de encontrar el archivo y la versión que necesitamos (1) para trabajar o imprimir. El problema crece exponencialmente cuanto más complejo es el proyecto o mayor es el número de personas que trabajan en él. Con los programas BIM esto se facilita sobremanera y se facilita también el trabajo en grupo, la localización de información, impresión por lotes...

Retos de futuro

De lo comentado anteriormente se desprende un corolario interesantísimo: Una de las mayores ventajas que ofrece el BIM es que al ampliar el tipo de información que admite y relacionarla entre ella, abre un gran número de posibilidades de crecimiento que hoy por hoy no existen pero podrían ser una realidad en un futuro muy próximo. tales como:

Dotar a los elementos constructivos de propiedades físicas que permitan calcular el comportamiento térmico del edificio en lugar de tener que usar programas de terceros como LIDER o CALENER que te obligan, además, a redibujar el edificio.
Llevando la idea anterior más allá también podría funcionar para calcular las transmisiones de carga y el comportamiento estructural. El concepto es el mismo.
Integrar la documentación escrita del proyecto con los datos del mismo. Actualmente las memorias descriptivas y constructivas requieren de la introducción de muchos datos técnicos del proyecto (cuadros de superficies, datos de agentes, datos del proyecto, presupuesto...). Estos datos podrían ser parte de la base de datos del modelo virtual e integrarse con las memorias, ganando, una vez más, tiempo y consistencia entre toda la documentación presentada.
...

En resumen: como comentaba al principio del escrito, el BIM introduce un nuevo modo de entender el trabajo en el que planos, datos, detalles... están relacionados entre sí formando un conjunto sólido, un modelo virtual del edificio del que se pueden extraer todo tipo de datos y representaciones, con el objetivo de incrementar la productividad y mejorar la seguridad de que lo que se representa es coherente y correcto. Ese cambio de modelo conceptual es a su vez su mayor enemigo, pues supone, en efecto, un cambio en la manera de trabajar, y eso es algo a lo que muchos no están dispuestos a renunciar o simplemente no pueden. Es evidente que el cambio está a la vuelta de la esquina y será para bien. ¿Le abriremos las puertas los arquitectos?

Enlaces de interés y referencias:

1: Nombrar archivos (o como mantener el orden en los proyectos)

2: En este artículo de la Agenda de la Construcció Sostenible se desarrolla más extensamente la idea de relacionar programas de BIM con el cálculo energético de los edificios.

Programas BIM:

Nombrar archivos (o como mantener el orden en los proyectos)

Tue, 16 Jan 2007 00:00:00 +0000

Los proyectos de arquitectura suelen desarrollarse en periodos largos de tiempo y generan un gran número de archivos y directorios. Si no hemos sido rigurosos y ordenados, la tarea aparentemente trivial de recuperar un plano concreto desarrollado hace unos meses o unos años (una situación bastante cotidiana en la profesión) puede convertirse en una auténtica odisea que puede desembocar en graves errores.

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…

Índice

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.