Traktuję rozwiązania no-code jak "płytkę prototypową" znaną fanom elektroniki.
Może zastosujesz to podejście w świecie programistycznym? 🤔
O co chodzi? 🧵 ↓
Prowadziłem prelekcje na temat podejścia no-code, nagrałem kilka filmów na ten temat i napisałem niezliczoną ilość wpisów. Po większości takich publikacji dostaję jakiś feedback.
Powiem wprost:
Programiści w większości brzydzą się no-codem 🤷♂️
Często pojawia się tutaj problem "programistycznej pychy".
Jak ktoś z wieloletnim doświadczeniem w programowaniu, człowiek o zdolnościach architekta systemu miałby upaść tak nisko, aby używać takich samych narzędzi jak pani Basia sprzedająca szkolenia z Canvy?! 🙀
Do tego dochodzą także czysto pragmatyczne argumenty:
↳ no-code jest mało elastycznym rozwiązaniem!
↳ to jest drogie przy dużej skali!
↳ rozwiązania w kodzie są szybsze i lepiej się skalują!
Nie ma co ściemniać — to wszystko prawda 🤷♂️
Z jakiegoś jednak powodu, elektronicy nie mają najmniejszego problemu, aby wykorzystywać płytki prototypowe. Te same, na których pracują 8-letnie dzieci na kursach elektroniki.
Nie jest to dla nich ani wstydem, ani "cofnięciem się w rozwoju" 🤔
Skąd takie odmienne podejście?
Fan elektroniki wie, że trawienie płytki i lutowanie elementów pochłania mnóstwo CZASU, a on chcę tylko sprawdzić pewną koncepcję, czy przetestować nowy moduł.
Zakłada także:
"To tylko na chwilę — w ramach prototypu. Jak zadziała, to sobie to zlutuję".
Jeśli w ten sam sposób podejdziesz do narzędzi no-code w stylu Make, czy N8N, być może Twoja niechęć minie.
Załóż, że rozwiązania te służą do PROTOTYPOWANIA. Nie musisz tego wdrażać na produkcji. To nie ma być szybkie, nie musi się skalować i nie musi być tanie.
Możesz nawet wspierać się kodem i z no-code zrobić low-code — oni tego nie sprawdzają! To jest poza systemem! 😉
Dam Ci konkretny przykład z mojego życia. Ostatnio Perplexity wrzuciło do swojego API model "sonar-deep-research".
Kolega zapytał "i jak to działa? dobre to?"
Przy klasycznym podejściu musiałbym przeczytać dokumentację API, napisać (lub wygenerować) trochę kodu, wpisać kilka zapytań, przeparsować odpowiedź i gotowe!
Włączyłem jednak Make. Położyłem bloczek "Perplexity". Ustawiłem model sonar-deep-research i testowałem — 10s ustawień.
Natychmiast mogłem przejść do testowania nowej zabawki. Jeśli mi się to spodoba, to sobie to ogarnę w kodzie, ale ja chcę wiedzieć jak szybko to działa, jakiej jakości odpowiedzi zwraca i jaką strukturę ma odpowiedź.
To rozwiązanie TYMCZASOWE.
Przy jednym module nie widać wielkiego zysku na czasie, ale pomyśl o prototypie wykorzystującym API z 6-7 serwisów. Używasz ich jednym kliknięciem i dodajesz do swojego kodu.
Przypominam:
Jak się sprawdzi, to zrezygnujesz ze swojej "płytki prototypowej".
A! Jeśli jeszcze nie widziałeś, to rzuć okiem na moje wystąpienie z Infoshare z ubiegłego roku.
Jakub Mrugalski 🔥
@uwteam
🤖 Piszę o technologii, AI, automatyzacji, cybersecurity i biznesie. 🛠 Dzielę się użytecznymi narzędziami i case-study 🤔 #DigitalEUAmbassador 🛑 Nie czytam DM
