shelidonJune 10, 20205 Comments on Il cobra non è una biscia (e neanche un pitone)

Per chi di voi è attivo su LinkedIn, stiamo assistendo a un’importante crescita del dibattito che riguarda il computational design con Dynamo e tanti sembrano volersi avventurare per la prima volta nei territori inesplorati dello scripting vero e proprio. Questo è bene, non può che farmi piacere. Questo ha anche, però, degli effetti collaterali da tenere sotto controllo e si porta dietro una serie di considerazioni che è necessario fare.

Ho avuto di recente una discussione estremamente interessante, a riguardo, con uno speaker di fama internazionale che vuole rimanere anonimo e che doma pitoni da tempi non sospetti. Dal suo punto di vista, si sta assistendo oggi a qualcosa di simile a ciò che è accaduto con Dynamo nei primi tempi: così come Dynamo viene visto come la soluzione magica a problemi nati semplicemente perché non si è capaci di usare Revit, oggi Python sta diventando la soluzione magica a problemi nati semplicemente perché non si è capaci di usare Dynamo.

Questo non è il Piton che state cercando.

Vorrei quindi mettere in fila un paio di pensieri, anche in vista di un corso che stiamo preparando e ad una lezione che terrò domani per Esem a chiusura di un percorso che ci ha visti insieme da prima della pandemia.

Il cobra non è una biscia…
e il pitone neanche.

Perché si usa Dynamo? Le tre “A”.

1. Accessibilità

Dynamo si usa per avvicinare i profani a ciò che romba sotto al cofano di Revit. Che questi profani siano terzi o che si sia noi stessi ad avere bisogno di questo tramite, non ha importanza: il primo fattore da tenere in considerazione riguarda l’accessibilità. Accompagnato ad una maggiore familiarità della maggior parte dei professionisti con uno strumento di programmazione visuale, è l’unico motivo che ci ha trattenuti dal continuare a scriptare duro in C#, ignorando completamente questo strano animale chiamato Dynamo.

Ne ho già parlato spesso commentando il grafico di Bruno Oliveir relativo all’automazione di task ripetitivi, uno dei principali campi di applicazione del nostro Dynamo. È un ragionamento del 2012, vecchio quindi di otto anni, ma la mentalità che rispecchia è ancora piuttosto diffusa: lo scriptatore solitario vince, il povero pollo non digitale perde.

All’inizio di quest’anno, ho fatto un ragionamento sul futuro delle professioni che riguardano il BIM e questo problema è già emerso: il tempo degli scriptatori solitari, degli specialist puri e dei BIM washer, deve finire.

Sulla stessa lunghezza d’onda, sempre nel 2012, era Jon Udell che pure cito quotidianamente nelle lezioni introduttive a Dynamo: nel suo Another way to think about geeks and repetitive tasks, lancia un attacco diretto alla visione solitaria di Oliveir e propone un modello collaborativo che chiaramente mi appartiene di più.

Software-assisted automation of repetitive work isn’t an event, it’s a process. And if you see it as a contest with winners and losers you are, in my view, doing it wrong.

– Jon Udell

Ora, il livello di accessibilità che si vuole raggiungere con il proprio script è una decisione strategica che, in un contesto strutturato, dovrebbe essere parte del piano di implementazione sviluppato dal Change Agent o dal BIM Manager.

Può trattarsi di un semplice input cieco, secondo i principi promossi dai sostenitori del Dynamo Player, introdotto nel 2017. In questo scenario, l’utente è un utente poco formato, cui si richiede di controllare lo script attraverso una serie di input o cui si richiede eventualmente solo di lanciare lo script tramite un pulsante. Trovate alcuni tutorial ad esempio sul blog revitstructure, oppure questa bella classe del 2017 della straordinaria Masha Pekurovsky.

Come potrete immaginare, è un approccio che mi lascia scettica perché tende ad essere “esclusivo anziché inclusivo”: getta la spugna sulla possibilità che l’utente possa accedere alla sorgente dell’automazione. Ha anche l’effetto collaterale, spesso non previsto, di accentrare il controllo ma anche l’onere del mantenimento, oltre che di alimentare l’aura magica e misteriosa di un processo che alla fine si riduce a essere (nel caso dell’immagine) un gruppo di letteralmente cinque nodi.

Dannazione, speriamo di non venire sopraffatti dal livello di complessità di questo script…

Chiaramente la prima interfaccia è più pulita rispetto al semplice color coding che ho utilizzato nel mio script. Chiaramente è anche impossibile per l’utente capire come funziona lo script e, ad esempio, suggerire/richiedere una piccola variante che consenta di creare livelli con interpiani personalizzati, oppure sia sopra che sotto al livello selezionato. Tutto è stregoneria.

Per tutto ciò che è relativo all’accessibilità della tecnologia – del rapporto tra chi sviluppa, chi mantiene e chi utilizza – consiglio un bagno nel mondo del DevOps, cui ho già fatto menzione in uno dei miei consigli del lunedì.

Buona parte del framework si concentra su come sviluppare una relazione proficua tra le varie parti coinvolte nello sviluppo e nell’effettivo utilizzo di una porzione di software. Se parliamo di coding e scripting non possiamo reinventare la ruota e ignorare i ragionamenti di gestione già affinati da chi si occupa dello sviluppo del software come suo core business. Per approcciare i concetti base del framework, provate a iniziare con questo video.

2. Automazione

I motivi per cui ci si trova ad utilizzare Dynamo (o lo scripting in generale, anche non visuale) sono molteplici e solitamente li riassumo in tre categorie:

1. necessità di automatizzare task ripetitivi;
2. eseguire operazioni che richiederebbero un livello di precisione troppo alto perché sia ragionevole richiederla ad un umano;
3. aggirare alcune limitazioni del software.

Il secondo punto ha a che vedere principalmente con il reame delle geometrie a variazione algoritmica e, come sapete, mi interessa relativamente. Il terzo punto ci porta ad addentrarci nel magico mondo delle API (preparate quindi il cappello con la retina). Ma è il primo punto che dà energia a Dynamo e lo porta ad avere la popolarità di cui gode in questi anni: la possibilità di automatizzare task ripetitivi.

I robot posatori di mattoni, che tanto angosciavano il Times qualche anno fa, sono un parallelo che mi piace fare in relazione a questo argomento: possono essere utilizzati per non posare manualmente una fila regolare di mattoni…

…oppure perché il progetto richiede una precisione che sarebbe irragionevole richiedere ad un posatore umano. Esistono innumerevoli progetti che usano questo espediente come questo, dalla Cina alla campagna svizzera. Si tratta di applicazioni decisamente affascinanti, ma evidentemente meno frequenti rispetto al primo scenario.

La decisione di automatizzare un task è, di nuovo, una decisione strategica da valutare rispetto ad alcune variabili quali il livello di standardizzazione del contesto e il grado di ripetizione/ripetitività del task stesso.

Per fare un ragionamento che sia di nuovo consapevole e strutturato, il Change Agent o la sua squadra dovrebbero fare un bagno nei diversi approcci che altre industrie hanno adottato nei confronti dell’automazione. Sul tema, consiglio questa bella classe del 2018 di Sol Amour e Justin Benjamin, e in generale il lavoro fatto da BVN prima di Paul Wintour e poi con Andrew Mehr: dai loro script Dynamo trasuda la solidità degli standard di studio, a partire dagli standard di nomenclatura. E senza standardizzazione non ci può essere nessuna automazione.

Per chi vuole approcciare l’automazione dei processi in modo consapevole, consiglio almeno tre letture:

• di Daniel Susskind, che ho già citato in relazione al suo The Future of Professions, consiglio A World Without Work: Technology, Automation, and How We Should Respond;
• Charles Hugh Smith, A Radically Beneficial World: Automation, Technology and Creating Jobs for All: The Future Belongs to Work That Is Meaningful;
• tutta la bibliografia del “futurologo” Alvin Toffler: in particolare Future Shock (che si occupa di indagare gli effetti del rapido progresso tecnologico sull’individuo, la famiglia e la società) e il leggendario The Third Wave.

The illiterate of the 21st century will not be those who cannot read and write, but those who cannot learn, unlearn and relearn.

– Alvin Toffler, Future Shock

Diventa difficile parlare di automazione senza avere sul proprio comodino anche Homo Deus, di Yuval Noah Harari. Un libro che non sta invecchiando benissimo, dato che inizia con l’idea che lo’uomo occidentale abbia sconfitto fame e pandemie (bel tentativo: prova ancora) ma comunque uno dei libri più importanti degli ultimi anni.

Se volete ritornare nell’ambito dell’edilizia, invece, un testo fondamentale per l’automazione rimane l’antologico Fabricating Architecture, a cura di Robert Corser.

3. API

Tempo di indossare il cappello con la retina che vi avevo chiesto di preparare.

Dynamo si utilizza anche per aggirare alcune limitazioni del software, nella misura in cui alcune operazioni sarebbero anche possibili e sono previste dal suo funzionamento, ma non sono previste dai comandi base forniti nell’interfaccia. Questo è possibile perché Revit è parzialmente open source e mette a disposizione, anche on-line, la documentazione relativa alle sue API.

API è una parola magica, come WBS: tutti la invocano, ma nessuno sa bene cosa significhi. Ho chiesto quindi al mio programmatore personale di darmi una definizione. Mi ha guardato male. Si è versato da bere. Ha accampato scuse futili. Mi ha gentilmente consigliato di andare a vedere su Wikipedia. Ma alla fine mi ha dato questa definizione.

Le API sono funzioni di un’applicazione, che vengono esposte e pubblicate per poter interagire con essa.

– Tato

Se siete ancora confusi, vi consiglio di dare un’occhiata alla classe Do You Want to Build an Add-In? che l’intramontabile John Pierson ha proposto all’Autodesk University di Las Vegas l’anno scorso. Sì, adesso ho anch’io la canzoncina di Frozen appiccicata al cervelletto.

Nella sua classe, John spiega in questo modo il concetto di API.

Salvo rendersi immediatamente conto che la spiegazione risulterà oscura alla maggior parte dei professionisti nel settore delle costruzioni e ripiegare verso una spiegazione più semplice:

What is an API?
A common language for us to communicate with the receiving party.

– John Pierson

E dopo aver tentato di elaborare la spiegazione facendo esempi con Zero il labrador, ci fornisce un utilissimo link da cui è possibile consultare in un colpo solo le API di Revit, Navisworks, Rhino e Grasshopper.

Ma il punto su cui vorrei attirare la vostra attenzione, prima di perdervi inghiottiti nello sciame di API (pun intended) è un altro.

Purtroppo Dynamo funziona grazie alle API di Revit. Allo stesso modo, avete bisogno delle API per scrivere il vostro add-in in C# (la classe di John), costruire la vostra piattaforma in Forge (prossimamente su questi schermi), scrivere il vostro package (more on that later) o scriptare direttamente in Python il vostro “Hello World” personale, se volete che appaia come model text in Revit. Non è possibile sfuggire ai margini di ciò che è previsto si possa o non si possa fare. Il metodo per creare un model text all’interno di una famiglia, ad esempio, è pubblicato qui. Ma, l’ultima volta che ho controllato, non era pubblicato il metodo per creare un model text in ambiente di progetto. Ergo, è possibile creare model text in una famiglia, con un package Dynamo tanto quanto è possibile farlo con Python. Se non ci riuscite, è possibile che semplicemente non abbiate trovato il package. O che non esista. Ancora. Ma di questo vorrei parlare in seguito.

Su Udemy esiste un corso specifico sulle API di Revit, pubblicato da Harry Mattison di BoostyourBIM. L’argomento viene anche affrontato nel corso che Jeremy Graham ha caricato su LinkedIn Learning (la piattaforma precedentemente nota come Lynda.com). E naturalmente una risorsa imprescindibile è il blog di Jeremy Tammik, aka The Building Coder.

Se siete ancora con me, e non siete già in giro a ballare vestiti da API come Winnie the Pooh, sottoinsieme a questo ragionamento sono due punti:

1. Non tutto ciò che è possibile è automatizzabile;
2. Per automatizzare bisogna conoscere.

Il secondo punto è semplice, ma spesso ignorato: alcune funzioni possono sembrare strane, per il modo in cui sono esposte nelle API, ma la verità è che il loro funzionamento rispecchia spesso il funzionamento di alcuni comandi all’interno di Revit. E’ il caso dei punti di manipolazione per la pendenza di un pavimento, ad esempio, o del profilo personalizzato per un muro. Chi non riesce a comprendere le relative API, forse, dovrebbe modellare un po’ di più e scriptare un po’ di meno.

Sul primo punto spenderei volentieri un’altra parola, perché spesso Dynamo (e annessi) viene presentato come uno strumento più potente di Revit, che consente di travalicare le limitazioni del software e grazie al quale tutto è possibile.

Considerate le funzionalità di Revit come un grande sovrainsieme, all’interno del quale si trovano due altri insiemi più piccoli: uno è l’insieme delle funzioni esposte nelle API (“esposte” me l’ha suggerito, di nuovo, il mio programmatore personale) e l’altro è l’insieme delle funzioni per le quali è previsto un comando nell’interfaccia grafica. Questi due insiemi presentano un’intersezione, ovvero tutte quelle funzioni che sono previste nell’interfaccia e che è possibile invocare in Dynamo, Python, C# o con altri tipi di scettri del comando.

…provate a immaginarlo così.

Insieme 1: la sottrazione dell’insieme API e dell’insieme pulsanti di interfaccia. Tutto ciò che Revit può fare, che non è esposto nelle API e per le quali non c’è un pulsante. Ovvero, funzionalità nascoste o non ancora rilasciate, messe lì soltanto ad appesantire il software o per fingere che ci sia qualcosa di nuovo nella prossima release. Non abbiamo modo di sapere cosa siano.

Hic sunt leones.

L’intersezione tra l’insieme di ciò che ha un pulsante ed è esposto nelle API è l’insieme dei pigri. Esiste il comando, è lì, ma non ho voglia di premerlo (oppure non ho voglia di premerlo duecento volte, oppure mi si richiede un livello di precisione irragionevole, insomma scegliete voi).

L’accidia è uno dei sette vizi capitali.

L’insieme di ciò che è previsto nell’interfaccia ma non è esposto nelle API di Revit, è l’insieme di tutto ciò che Autodesk vuole tenerci nascosto. Contiene nefandezze hardcoded come il retino solido, peccati capitali come le scale e le balaustre, oggetti che fingono di essere in una categoria speciale ma che in realtà sono elementi travestiti, come il model text in ambiente di progetto o i controsoffitti, oppure oggetti che vengono da molto lontano e parlano una lingua ormai perduta, come i materiali.

That’s magagnas realm, baby.

L’ultimo insieme è quello su cui più spesso ci si sofferma: la parte in cui “posso far fare a Revit quello che voglio”. Abbiamo visto che in realtà non è vero.

Quando si usa Dynamo, ci si pone come un piccolo sottoinsieme nell’insieme d ciò che è possibile fare con le API, a cavallo tra ciò che è esposto nell’interfaccia e ciò che non lo è.

Potenzialmente, l’insieme di ciò che è possibile fare in Dynamo potrebbe coincidere con l’insieme in cui sciamano le apine. Ma non da solo. e non per magia.

Allargare il cerchio delle apine

L’ultima considerazione è quella che mi sta più a cuore e per questo l’ho lasciata per ultima. Dynamo è community-based: esiste e vive grazie al contributo costante di eroi noti e meno noti che quotidianamente sviluppano package personalizzati. I package sono ciò che ci consente di allargare il cerchio per abbracciare tutte le apine.

Questo è quindi l’insieme di cui parlavo poco fa: l’insieme di ciò che è esposto nelle API ma non è (ancora) invocabile con un package. È la zona in cui occorre qualcuno che sia in grado di scriptare.

È anche però la zona in cui diventa necessario ricordarsi come mai si è iniziato a usare Dynamo in primis: accessibilità, automazione, ma aggiungerei collaborazione. Il custom mode in python va benissimo, quindi, ma l’ideale sarebbe che diventi un package pubblicato, ad un certo punto. Più che ideale, è quasi un dovere morale.

Non sapete come fare? Ci vengono in soccorso diversi giganti del computational design:

• Nathan Miller, White-Glove Packaging: Creating Custom Dynamo Nodes;
• Thomas Mahon, Getting Started with Dynamo Custom Node Development Using C# and Zero Touch Import;
• Adam Sheater, Coding New Nodes with Dynamo.

Buon lavoro.