Skrypty Dynamo i Grasshopper jako narzędzia firmowe
Skrypty po autorach, którzy odeszli (do innego biura). Grafy padające po aktualizacji bibliotek. Jak zrobić ze skryptów pracowni narzędzia firmowe.
Skrypty Dynamo i Grasshopper jako narzędzia firmowe
Masz w firmie folder ze skryptami Dynamo albo Grasshopper? Otwórz go i zrób prostą rzecz: przy każdym pliku odpowiedz sobie na dwa pytania. Co ten skrypt robi i kto poza tobą to wie. Jeśli przy którymś zatrzymujesz się na dłużej niż kilka sekund.
Zanim pójdziesz dalej: pięć pojęć
Słowniczek: 7 pojęć z tego tekstu
- Revit
- Program do projektowania opisanego modelem: ściany, instalacje i zestawienia żyją w jednym pliku. Właściwie każdy skrypt w tym tekście chodzi po danych właśnie stąd.
- Dynamo
- Darmowe narzędzie wbudowane w Revita. Programujesz je poprzez łączenie klocków na płachcie, bez pisania kodu.
- Grasshopper
- Odpowiednik Dynama dla Rhino, czyli programu do modelowania o swobodniejszej geometrii. Ta sama idea: robota składana z klocków zamiast pisania kodu.
- Skrypt
- Plik z zaprogramowaną robotą do wykonania, na przykład zestawienie drzwi liczone przy każdym projekcie od nowa.
- Graf
- To, co widzisz po otwarciu skryptu Dynama albo Grasshoppera: mapa połączonych klocków, przez którą przepływają dane z modelu.
- NODE
- Jeden klocek grafu. Każdy robi jedną małą rzecz: weź ściany, policz pole, wypisz do Excela. Połączone dziesiątki takich klocków budują całą robotę.
- Biblioteka (pakiet)
- Zestaw cudzych dodatkowych klocków do pobrania, dorabianych przez społeczność. Gdy zmienia wersję, graf postawiony na niej potrafi runąć. To bohater początku tego tekstu.
Jak umiera skrypt
Tworzy go ktoś utalentowany, zwykle po godzinach, bo w projektach nie ma na to czasu. Ludzie go używają, korzyści rosną, graf puchnie z kolejnymi funkcjami. W pewnym momencie twórca zmienia pracę. Przychodzi wtedy aktualizacja Revita, biblioteka, na której stał graf, zmienia wersję, i skrypt przestaje działać. Cicho. Nikt nie wie, co robił, więc nikt go nie naprawia. Trafia do foldera z pamiątkami, obok szablonu sprzed lat.
Co ciekawe, Dynamo ani Grasshopper nie zawiodły. Wszystko działało dopóki był autor. To była robota osobista udająca narzędzie firmowe.
Czym narzędzie różni się od pamiątki
Dwie rzeczy. Po pierwsze: właściciel. Nie autor, bo autor odszedł, tylko osoba, która dziś odpowie na pytanie „po co to jest i czy jeszcze działa". Po drugie: historia zmian. Zaczyna się od jednej spisanej informacji, gdzie leży aktualna wersja. Repozytorium albo wspólny folder, byle opisany.
Skrypt z tymi dwoma rzeczami to wyposażenie pracowni, takie samo jak szablon arkusza albo rodzina drzwi. Skrypt bez nich to osobista robota czekająca, aż jej autor gdzieś zniknie.
Droga do wstążki
Skrypt schowany na dysku jednej osoby przestaje istnieć dla reszty pracowni. Ludzie go nie widzą, więc go nie używają. Masz je po kolei, od najprostszej: Dynamo Player uruchamia graf bez otwierania edytora, pyRevit zamienia skrypty Pythona w przyciski, a gdy automatyzacji przybywa, gotowe nakładki zbierają je w jedną zakładkę na wstążce Revita.
I jedna rzecz, którą powtarzają publiczne biblioteki skryptów: zanim odpalisz cudzy skrypt, zrób kopię pliku. Sekunda roboty, a ratuje projekt.
A chmura? Chmura rozwiązuje połowę problemu
Częsta odpowiedź brzmi: wrzućcie wszystko do chmury, i słusznie. Skrypt przestaje być plikiem na prywatnym komputerze, zespół widzi jedną aktualną wersję, a nowa osoba w projekcie nie musi nikogo prosić o dostęp. To realna poprawa.
Ale chmura jest tylko lepszym magazynem. Widzi pliki, nie rozumie ich zawartości. Na pytanie, co dokładnie zmieniło się między wczoraj a dzisiaj, odpowiada tak samo jak folder na dysku: niczym. Kontrola wersji w tym tekście znaczy coś mocniejszego: zapisywanie każdej zmiany jako osobnej wersji z autorem, datą i możliwością podejrzenia różnic.
Kontrola wersji, o której branża AEC nie mówi
Programiści rozwiązali ten mocniejszy problem dawno temu. Kontrola wersji zapisuje każdą zmianę jako osobną wersję z autorem, datą i opisem. Można wrócić do stanu sprzed wczoraj i zobaczyć, co dokładnie kto dopisał. W branży AEC ta praktyka prawie nie istnieje, choć narzędzia są gotowe. Speckle, otwarta platforma do wymiany danych projektowych, robi dokładnie to dla modeli: każda wysyłka tworzy wersję, a różnice między wersjami widać na konkretnych elementach. Jak to działa w praktyce, opisałem osobno w tekście Czym jest Speckle?.
Dla skryptów wystarczy prostszy krok: repozytorium albo choćby folder sieciowy z kopiami datowanymi w nazwie. Najgorsza opcja to jedyna kopia na dysku autora.
Kiedy NODE-ów przestaje wystarczać
Graf ogarnia wszystko, co żyje w modelu: ściany, otwory i ich ilości. Przychodzi jednak zadanie, które potrzebuje danych spoza modelu, na przykład liczb z arkusza kosztorysu albo z systemu fakturowania. Albo skrypt ma uruchamiać się u ludzi na różnych wersjach Revita. Na takie zadania gotowych klocków nie ma. Zaczyna się prawdziwe programowanie: powstaje wtyczka podpięta do Revita przez API, czyli przez oficjalne gniazdko dla rozszerzeń. Wtyczka kosztuje więcej na starcie i zwraca się latami, więc podchodzisz do niej tak samo jak do każdej innej inwestycji w pracowni.
Jedna kartka zamiast foldera pełnego zagadek (i jeden agent)
Cała metoda to jedna kartka. Lista skryptów. Przy każdym: co robi, kto ogarnia, gdzie jest aktualna wersja. Puste pola mówią same za siebie. Naprawiasz to, co warto, i kasujesz resztę bez żalu.
Kiedy z kartki wynika, że część skryptów dawno nadaje się na prawdziwą wtyczkę, to jest dokładnie to, co robię dla pracowni od kilku lat. Porozmawiajmy o twoim folderze podczas 30-minutowej rozmowy. A jeśli twoja lista zadań wygląda jak gotowa lista zadań dla agenta AI, zacznij od tekstu o wdrażaniu AI w pracowni, tam jest kolejność, w której to się robi.