Steve Francia

Już wiele lat programujemy na różne platformy, tworzymy czasami dziwne aplikacje dla klientów. Od jakiegoś czasu w dużej mierze tworzenie aplikacji to zaimplementowanie jakiegoś API z jednego lub wielu serwisów dostępnych w sieci.

Pisanie systemów opartych o przeglądarki bardzo się zmieniło w ciągu ostatnich kliku lat, kiedyś pisanie aplikacji polegało na wrzuceniu do gara wiedzy z administracji (instalacja i konfiguracja serwerów usługowych), umiejętności programowania w jakimś języku wysokiego poziomu (PHP, Perl, Python, C/C++), dodania do wszystkiego szczypty html’a oraz css’a. Potem programista zasiadał i mieszał w garze, aż wyszło coś co można było nazwać gotowym projektem.

Teraz sytuacja się już deko bardziej uprościła, choć skomplikowała za razem. Teraz mamy backendowców, frontendowców, deploy managerów, designerów i całą inną masę tałatajstwa, która w wielu firmach jest wymagana żeby projekt rozpocząć, prowadzić i zakończyć ku uciesze właścicieli i klientów. Staramy się coraz to bardziej dochodzić do nirvany w tym cyfrowym wymiarze, pragniemy tworzyć efektowniej i efektywniej, ale czy możemy to dalej robić sami, jak przed laty kiedy znalezienie drugiej wkręconej w nowoczesne technologie osoby było nie lada wyzwaniem? Czasy się zmieniają, narzędzia i nurt pracy także. Swoją drogą ciekawe ilu z Was korzystało z CVS (taki stary system kontroli wersji), aktualnie konia z rzędem temu kto byłby w stanie prowadzić projekt wieloosobowy na tym właśnie systemie. Samo używanie SVN’a dość trąci myszką, choć wiele firm jeszcze nie zdecydowało się na przejście w coś bardziej nowoczesnego (co nie rzadko implikuje spore koszty, ale też oszczędności, ale to jest temat na osobny tekst).

Środowisko programistyczne zna chyba każdy, kto pracuje przy kodzie. Konfigurujemy sobie narzędzia tak jak lubimy, często konfigurację wypychając w chmurę, tak aby na innym komputerze pobrać i korzystać z własnych ustawień. Edytory w dużej mierze są dalej “ciosane”, a ich podstawowy interfejs nie zmienił się. Od vim’a czy emacs’a dalej mamy wielki kawał ekranu wyświetlający tekst, ładnie pokolorowany. Ale skoro ponad 50 lat pracujemy przy edytorach i poza kolorowaniem oraz ulepszaniem wyszukiwania w projekcie nie udało nam się niczego lepszego wymyślić, to co? Może za następne 50 lat będziemy pracowali tak samo? Mnie się osobiście nie wydaje. Słyszeliście o Flow-based programming ? Wymyślił go J. Paul Morrison w latach 70’tych XX wieku, czyli już ponad 40 lat temu. W/g niego każdy program składa się z pewnych klocków, elementów które coś robią (np. wyświetlają numer telefonu lub obliczają podatek VAT). Współcześnie komputery wyglądają już zupełnie inaczej niż 10 lat temu, tablety i smartfony zalewają rynek. Klasyczne środowisko programistyczne zaczyna być przestarzałe i nie nadaje się na inne niż “komputer” urządzenia. Czasami zdarza mi się poprawić jakiś kawałek kodu na tablecie, ale jest to dość nieprzyjemne i mało ergonomiczne.

Oczywiście powyższe podejście wymusza wiele zmian w sposobie programowania, oraz wymaga rozwiązania wielu problemów, które często przy współczesnej architekturze komputerów nie są tak dosłowne i proste. Całe szczęście technologia idzie do przodu, niebawem pojawią się w ogólnej sprzedaży procesory Qualcomm Zeroth, które mają szansę zrewolucjonizować wiele dziedzin. A przede wszystkim pozwoli wejść na nowe poziomy abstrakcji i stworzyć narzędzia, które za pomocą interfejsu oraz architektury pozwolą programować każdemu. Bardzo ciekawym projektem, który może dość szybko trafić pod strzechy jest noflo, mam nadzieję, że chłopaki podołają. Osobiście poza wieloletnim “myzianiem” swojego środowiska, wypracowaliśmy prosty ekosystem dla naszych aplikacji, oparty o takie narzędzia jak: vagrant, SaltStack. Aktualnie zamiast instalować to czy inne rozszerzenie do serwera, lub przetestować konfigurację serwera pod kątem wydajności czy awaryjności wykonujemy kilka komend i mamy sprawną wirtualną maszynę ze wszystkim co potrzebujemy. Dobrze zaprojektowany ekosystem zakłada, że środowiska produkcyjne oraz developerskie tak naprawdę są od siebie zależne, a zmiana parametrów konfiguracji serwerów, lub dodawanie nowych usług do naszej aplikacji może być swobodnie przenoszony z obrazów developerskich na produkcję za pomocą kilku prostych operacji. Zmiany w takim ekosystemie mogą implikować konfigurację setek serwerów działających jako backend naszej wspaniałej aplikacji. Tekst ten można traktować jako delikatne muśnięcie tematu, bo sam temat to rzeka problemów do rozwiązania, ale w pewnym momencie okaże się, że nasza włożona praca owocuje niesamowitą elastycznością rozwiązań. Jest to pierwszy artykuł o ekosystemie developerskim, w miarę możliwości i czasu postaramy się zrobić z niego cykl poświęcony założeniom, konfiguracji oraz używania opisanych powyżej technologii oraz oprogramowania.