25 lat / Czyli jak rozumieć dzisiejszy język techniczny

W 1997 r. wiele z dzisiejszych pojęć nie istniało jeszcze w ogóle. Byliśmy o krok od stania się internautami, a nawet mózgami internetu z palmtopami u boku. Technologia nie była „inteligentna”, nic nie było „zoptymalizowane”, a o tabletach mogliśmy sobie co najwyżej pomarzyć.

Świat technologii ma wiele modnych powiedzonek. Sami mówimy o multiexperience, jedynych źródłach prawdy czy koncepcjach mobile-first. Spróbuj wytłumaczyć swoim dziadkom, że „React Native” to framework, oparty na bibliotece i zbudowany na języku. Mówisz wyrazami z zupełnie innego słownika.

Nie możemy Ci zagwarantować, że te koncepcje będą istniały za kolejne 25 lat-niektóre staną się po prostu standardem, a inne mogą być jedynie krokami na drodze do czegoś jeszcze lepszego, ale trochę tłumaczenia nigdy nikomu nie zaszkodziło, prawda? 😉

Chmura to najnowszy, ale prawdopodobnie najtrwalszy termin określający przestrzeń serwerową poza siedzibą firmy. Przepracowaliśmy już zdalne serwery, platformy hostingowe, a nawet-i tu się trochę cofniemy – „computer timesharing”. A najgorsze w tym wszystkim jest to, że raz nazywamy rzeczy po polsku, a raz po angielsku!”.

Czy tak pozostanie? W najbliższej przyszłości zapewne Chmura będzie Chmurą (bądź przesiądziemy się na ogólnoświatowe określenie Cloud), ale na horyzoncie pojawia się jedna alternatywa: obliczenia kwantowe. Jeśli/kiedy stanie się to standardem, czy będziemy nazywać to „chmurą obliczeń kwantowych”? To pokaże nam dopiero czas.

Jeszcze kilka lat temu słowo „Mach” było używane w dwóch miejscach-do mierzenia prędkości samolotów i do sprzedaży męskich żyletek.

W IT MACH jest akronimem od Microservices, API, Cloud i Headless. Pomijając fakt, że API jest akronimem w akronimie, „cloud” i „headless” również znajdują się na naszej opisywanej liście, więc… tak, powodzenia w wyjaśnianiu tego na imprezie, jeśli pracujesz na stanowisku „Architekt MACH”.

Czy tak pozostanie? Architektura MACH jako koncepcja nigdzie się nie wybiera w najbliższym czasie. Jest szybka, elastyczna i łatwa do dostosowania – to „standard”, którym IT chce być. Również tu widzimy mnóstwo buzzwordów-MACH, Headless, Composable, Jamstack – które tylko zwiększają zamieszanie. Czy naprawdę potrzebujemy ich wszystkich?

Architektura to termin wywodzący się z języka łacińskiego, a jego znaczenie poddawane było ciągłym zmianom. Dziś możemy go używać do reprezentowania analogicznych procesów w IT. Mówimy już o platformach i fundamentach – terminach również zaczerpniętych z budownictwa architektonicznego.

Jednak sam termin oznacza również zmianę w sposobie postrzegania technologii. Architektura narzuca z góry potrzebę budowania fundamentów, planowania i ogólnej strategii.

Czy tak pozostanie? Sam termin oznacza również zmianę w sposobie postrzegania technologii. Jest to pojęcie niezbędne do stworzenia backendu. Architektura to również zbiór zasad i choć nowe stacki technologiczne, takie jak MACH, będą się pojawiać (i być może odchodzić), to podstawowe wytyczne pozostaną.

Serwer to jeden z tych terminów, które w pewien sposób mają sens. Serwuje nam to, czego potrzebujemy. Największa różnica pomiędzy starym i nowym określeniem na serwer (niegdyś więc wymyślny kelner) jest taka, że poprzednio słowo to wiązało się z pewnym poczuciem luksusu, zaspokajania potrzeb. Stosikowi dysków twardych i procesów komputerowych daleko w końcu od kurtuazji.

A skoro mówimy o serwerach, musimy wspomnieć o serverless. Słówko to nie istnieje do końca w tradycyjnym rozumieniu języka, ale obrazuje w pewien sposób brak serwującego (lub kelnera, zależy, jak spojrzeć). W IT natomiast serverless oznacza sporą zasobność serwerową- lub dokładniej, umiejętność użycia procesów chmury obliczeniowej (ang. Cloud Computing) w odpowiednio wymaganej ilości, bez zważania na limity konkretnych serwerów.

Czy tak pozostanie? Tak czy inaczej, każde rozwiązanie wirtualne musi wyjść z jakiegoś serwera. Kto wie, może dożyjemy czasów, gdy wszystko będzie odbywać się w chmurze…? Wtedy serverless będzie miało jeszcze mniej sensu! Ale to historia na inny dzień, nadal mamy sporo czasu na zaprzyjaźnienie się z serwerami.

Gdzieś pomiędzy serverless, a headless możemy stwierdzić, że półświatek IT nie do końca rozumie stwierdzenia “-less”. Istne urwanie głowy z tym “headless”…

Jeśli więc “head”, a więc głowa, odnosi się do interfejsu graficznego (frontend), a backend (zaplecze techniczne) do „body”, czyli ciała, to oznacza to, że systemy headless pozbywają się frontendu (zewnętrznej warstwy prezentacji). Komunikacja pomiędzy frontendem a backendem odbywa się poprzez API (interfejs programowania aplikacji). Headless oznacza także, że żadna “głowa” nie jest jasno przypisana do konkretnego “ciała”, a więc firma może swobodnie dodawać swoją “głowę” lub nawet “głowy”!

Czy tak pozostanie? Czy powinniśmy nazwać to headmore? Headfree? Hed…onizm? Mówiąc szczerze, brzmi to po prostu głupio. Istnieje spora szansa, że headless zostanie wchłonięte przez terminologię „ composable”, w każdym razie na poziomie koncepcyjnym. Gdy mówimy jednak o poziomie technologii, z pewnością możemy się spodziewać rzeczy typu Headless CMS przez następnych parę lat. Mówiąc szczerze, już teraz trwają rozmowy nad wprowadzeniem Hybrid CMS, więc nie cytujcie nas w tej kwestii 😉

Słówko “composable” może być użyte w kontekście architektury, ale najczęściej używa się go w określeniu “composable commerce”. To nadal dość nowy termin, który oznacza używanie nowoczesnych technologii, aby umożliwić większą elastyczność.

Dodatkowo jednak jest to stwierdzenie bardzo podobne do innych na tej liście (i poza nią). Composable commerce skupia się na architekturze używającej najlepszych rozwiązań dla konkretnych projektów i biznesów, które później zostaną ze sobą połączone. Na pewno w tym kontekście usłyszysz słówka typu API, Mikroserwisy, Chmura… i jeśli myślisz, że brzmi to znów jak sytuacja z MACH, witamy w świecie niejasności! Używa się tego również naprzemiennie z headless commerce, a gdy zaczniemy już rozdzielać rzeczy, zwykle dzielimy je też na backend i frontend.

Czy tak pozostanie? Cóż, mamy już sporo określeń znaczących podobne rzeczy. A skoro composable commerce brzmi bardzo poetycko, ale też niezwykle niejasno- ciężko powiedzieć.

Abstrahując od architektury, framework to następny element, który technologia zapożyczyła od budownictwa. Frameworki są przydatne- umożliwiają firmom ruszyć z kopyta. Tworząc podstawowy szkielet projektu, zespoły mogą skupić się na budowaniu unikatowych elementów zamiast próbie  wymyślenia manualnie koła na nowo.

Jest wiele przestrzeni, które okazują się być identyczne w różnych biznesach, więc frameworki pozwalają developerom uniknąć powtarzania się i dają możliwość dostosowania konkretnych elementów projektu.

Czy tak pozostanie? Tak samo jak architektura, frameworki reprezentują bardziej zorganizowane, skupione na pracy podejście do tworzenia rozwiązań. Możemy wyróżnić frameworki mobilne jako narzędzia do tworzenia aplikacji, frameworki e-commerce (dla e-commerce, oczywiście) i wiele więcej. W przyszłości z pewnością zobaczymy frameworki MACH i inne… ale to nadal tylko frameworki😉

Biblioteki zazwyczaj „zszywają” software developmentu. Zawierają w sobie potrzebne skrawki kodu, z których trzeba korzystać raz za razem- te przeróżne interakcje i skrypty są potrzebne, aby różne rzeczy mogły działać.

Można również spojrzeć na Design Systems jako rodzaj biblioteki- posiadają wirtualny kod, którego re-używa się w różnych miejscach na stronie czy aplikacji.

Czy tak pozostanie? Gdy przenosimy się w stronę systemów composable oraz elementów wielokrotnego użytku, potrzeba bibliotek z istniejącym już zestawem funkcji będzie tylko rosnąć. Są odpowiednikami frameworków- de facto, to często frameworki (React Native) buduje się za pomocą blibliotek (React JS).

Termin “odrzuć ciasteczka” jest nam wszystkim bardzo dobrze znany. Gdy Internet raczkował, ciasteczka były potrzebne do pobierania danych użytkownika i tym samym wspierały działania nad ulepszeniem działania strony. Teraz zwykle dotyczą reklam, zbierania danych i spowalniania naszych przeglądarek, gdy zapomnimy o usunięciu ich po kilku latach surfowania po internecie.

A jeśli zastanawiasz się, skąd pochodzi ta terminologia, to wywodzi się ona od „magic cookie”, czyli zestawów danych używanych w Unix. A to z kolei wzięło się z… eh, to długa historia.

Czy tak pozostanie? Ostatnie kilka lat nie było zbyt łagodne dla ciasteczek. GDPR i inne inicjatywy sprawiły, że ciasteczka są coraz bardziej zagrożone. Narzędzie przeglądarkowe ma przed sobą spore wyzwanie, biorąc pod uwagę fakt, że można je zwyczajnie usunąć.

Zakończmy ten wywód na jednym z zabawniejszych tutaj zwrotów. Przez bardzo długi czas „git” był w języku angielskim używany jako obraźliwy zwrot. Można być zrzędliwym gitem, można być bezczelnym gitem, można też być starym gitem. Więc czemu teraz odnosimy się do gitów jako do software’u śledzącego zmiany w pliku?

Wina leży po stronie twórcy Linuxa, który nazywa się, cóż… Linux Torvalds.

Czy tak pozostanie? Cóż, nadal potrzebujemy sposobów na rozwijanie naszego software’u, a lepszego rozwiązania na horyzoncie nie widać. Oczywiście, dopóki nie jesteś developerem związanym z konkretnym projektem, nie będziesz tego słówka wysłuchiwać zbyt często.

Akurat tak się składa, że my pracujemy w takim biznesie, że słyszymy je prawie cały czas. 😉

Teraz już znasz nasz dialekt!

To zdecydowanie nie jest  nasz cały słownik. Nowe terminy pojawiają się codziennie, a nie chcieliśmy zawrzeć tu takich, które mogą okazać się szybko przemijającą nowinką lub takich, które zwyczajnie nie są wg nas ważne.

Mamy jednak nadzieję, że nakreśliliśmy kilka najczęściej używanych terminów IT i wytłumaczyliśmy, co znaczą i jaki może być ich wpływ- lub jego brak- na biznes.

Więc następnym razem, gdy ktoś z IT zaproponuje ci zaimplementowanie frameworku serverless dla twojego chmurowego rozwiązania w stylu headless oraz composable, zrozumiesz co miał na myśli. A potem poprosisz, żeby mówił po polsku 😉