Wirtualne środowisko programistyczne. Wygodna konfigurcja środowiska programistycznego z Vagrant!
Alternatywą wobec WAMP/XAMPP i instalacji serwera bezpośrednio na dysku komputera jest wirtualne środowisko bazujące na tworzeniu symulacji systemu operacyjnego i warstwy sprzętowej, poprzez użycie odpowiedniego oprogramowania. Sposób przedstawiony poniżej nie jest uzupełnieniem pierwszej części, a osobną metodą na przygotowanie komputera do pracy. Programista sam musi zdecydować, która metoda mu bardziej odpowiada. Z naszej strony zachęcamy do korzystania z wirtualizacji i Vagranta. Takie środowisko będzie wykorzystywane w pozostałych wpisach dotyczących WordPress na łamach bloga Learn2Code.
Przypomnijmy, że celem przygotowania komputera do pracy i swobodnego programowania aplikacji internetowych jest pobranie i zainstalowanie wszystkich potrzebnych programów i bibliotek. W przypadku prostych, podobnych do siebie projektów, są one precyzyjnie zdefiniowane i w większości wypadków jest to proces, w którym nie spodziewamy się zaobserwować żadnych problemów. Może jednak okazać się, że dany projekt wymaga bardziej zaawansowanej konfiguracji i korzysta z większej ilości zależności, może też zdarzyć się, że musimy pracować równolegle nad projektami, a każdy z nich ma wymagania środowiskowe. Lub gdy będziemy chcieli przetestować nowe technologie i biblioteki przy kolejnych projektach, może okazać się, że jednolita konfiguracja nie jest możliwa do utrzymania. Należy też liczyć się z tym, że nawet instalacja przy użyciu bundler`a (np. WAMPa) może się zakończyć niepowodzeniem. Wystarczy, że aktualnie zalogowany użytkownik nie będzie miał wystarczających uprawnień by ukończyć instalację; będzie miał już wcześniej zainstalowaną inną wersję tych programów i przez to napotka problemy z kompatybilnością lub uruchamianiem złych plików wykonawczych. Równie ważne jest aby nasze lokalne środowisko jak najlepiej odwzorowywało środowisko produkcyjne, na którym będzie działała nasza aplikacja lub strona, co dodatkowo utrudnia przygotowanie odpowiedniej konfiguracji do pracy lokalnej.
W odpowiedzi na powyższe problemy zaleca się stosowanie wirtualnego środowiska programistycznego. Polega ono na zastosowaniu osobnego programu, który w osobnym oknie uruchomi wskazany przez nas system operacyjny, wraz z przygotowaną przez nas konfiguracją, tworząc coś na kształt symulacji komputera. Na takim wirtualnym środowisku można pracować bez żadnych ograniczeń i bez ryzyka, ze nasze zmiany wpłyną na działanie naszego komputera i istniejące na nim projekty lub inne wirtualizacje. Takie środowisko oprócz wykorzystywania zasobów komputera (mocy obliczeniowej i przestrzeni dyskowej) będzie działało niezależnie. Przykładowym programem, który możemy użyć do stworzenia symulacji jest VirtualBox.
VirtualBox to popularne narzędzie umożliwiające pracę na wirtualnym środowisku. Jest dostarczane przez firmę Oracle i w pełni darmowe. VirtualBox uruchamia system operacyjny na podstawie tzw. “obrazu” lub “wirtualnego dysku”. Jest to kopia wcześniej przygotowanej wirtualizacji, mogąca zawierać już zainstalowany system operacyjny lub programy. Dzięki szerokim zastosowaniom wirtualnych maszyn, dostępne są zestandaryzowane obrazy, przygotowane do stosowania w pracy z wybranymi technologiami i językami. Istnieje również możliwość, aby w prosty sposób utworzyć własny obraz i samodzielnie wykonać na nim instalację całego oprogramowania, w tym systemu operacyjnego.
Wirtualizacja nie jest pozbawiona wad. Minusem pracy z obrazami są przeważnie ich duże rozmiary i w związku z tym czasochłonne przenoszenie pomiędzy komputerami. Co więcej, utrzymanie spójnej i aktualnej konfiguracji na wszystkich kopiach jednego obrazu jest niemożliwe do osiągnięcia i może się okazać, że pracujemy na przestarzałej konfiguracji, podczas gdy inni członkowie zespołu pracują z najnowszymi aktualizacjami. Aby rozwiązać ten problem, zaleca się stosowanie dodatkowego narzędzia o nazwie Vagrant, stanowiącego technologię uzupełniającą VirtualBox`a.
Najlepsza dostępna konfiguracja dla web developerów pracujących z WordPress jest konfiguracja dostarczona przez Varying Vagrant Vagrants (VVV), przeznaczona do pracy z Vagrantem.
Vagrant to narzędzie ułatwiające budowę i konfigurację wirtualnego środowiska w postaci pojedynczego pliku, który możemy przekazać innym programistom pracującym nad naszym projektem i zagwarantujemy sobie jednolitą konfigurację pomiędzy wszystkimi komputerami. Jest on wykorzystywany razem z VirtualBox`em. VirtualBox jest odpowiedzialny za działanie wirtualnego środowiska, a Vagrant służy do jego wygodnej konfiguracji z poziomu linii komend.
Informacje o konfiguracji dodamy w pliku konfiguracyjnym- Vagrantfile. W ten sposób dzięki jednemu poleceniu jesteśmy w stanie stworzyć nową wirtualizację na naszym VirtualBoxie i od razu, automatycznie zainstalować na wirtualnej maszynie wybrany system operacyjny, wszystkie potrzebne nam do pracy programy w odpowiednich wersjach (taka automatyczna instalacja nazywa się prowizjonowaniem/ ang. provisioning).
Bez Vagranta musielibyśmy każdy program zainstalować osobno z poziomu wirtualnej maszyny. Osiągnięty efekt będzie ten sam, jednak pochłonie znacznie więcej czasu i kopiowanie otrzymanego w ten sposób obrazu dla innych programistów będzie trudniejsze.
Wykorzystajmy teraz VirtualBox i Vagrant, aby stworzyć środowisko programistyczne zbudowane na podstawie konfiguracji dostarczonej przez Varying Vagrant Vagrants (VVV). Zgodnie z dokumentacją VVV powinniśmy po zakończeniu procesu mieć przygotowany do pracy system o następującej specyfikacji, zawierającej m.in:
Ubuntu 18.04 LTS (Bionic Beaver)
nginx (mainline version)
MariaDB 10.1
php-fpm 7.2.x
git
phpMyAdmin (multi-language)
….
Jak widać VVV gwarantuje nam minimum niezbędne do pracy. Jest to tylko fragment listy, która jest o wiele dłuższa i zawiera wiele dodatkowych narzędzi przydatnych w codziennej pracy. Instalację i uruchomienie środowiska wykonamy na przykładzie systemu operacyjnego Windows.
Pełna dokumentacja Varying Vagrant Vagrants (VVV) jest dostępna pod adresem
Pobranie i instalacja VirtualBox
Instalator należy pobrać z oficjalnej strony . Plik powinien być wybrany pod kątem używanego systemu operacyjnego. Przygotowujemy poradnik dla Windows, więc powinniśmy wybrać odpowiedni plik (oznaczony jako Windows Host). Po instalacji zostaniemy zapytani o możliwość uruchomienia maszyny wirtualnej.
Pobranie i instalacja Vagranta
Plik jest dostępny do pobrania pod adresem:
Możliwe, że podczas uruchamiania pliku zostanie wyświetlony komunikat jak na załączonym obrazku. Plik jest pobrany z oficjalnego źródła, dlatego możemy go zignorować w tym momencie.
Pierwszy krok to uruchomienie instalatora.
W kolejnym kroku należy zaakceptować warunki licencji oprogramowania. Vagrant korzysta z licencji MIT, wspierającej rozwój wolnego oprogramowania i nie wiążą się z nią zagrożenia wynikające z niewłaściwego użytkownika.
Należy wskazać miejsce docelowej instalacji. Należy się upewnić, że posiadamy wystarczające uprawnienia i miejsce na dysku, aby móc wykonać instalację na wybranej ścieżce. Podobnie jak wcześniej, my instalujemy program na dysku D:, pod domyślnym adresem. Wybór ścieżki jest dowolny.
Do instalacji są potrzebne uprawnienia administratora.
Po zakończeniu instalacji należy zresetować komputer. Weryfikację poprawności instalacji przeprowadzimy w kolejnym akapicie.
Sprawdźmy czy instalacja zakończyła się pomyślnie i Vagrant został poprawnie zainstalowany. Robimy to z linii komend. Aby ją włączyć należy nacisnąć klawisz Windows lub włączyć menu Start, a następnie w miejscu na wyszukiwanie plików wpisać cmd i nacisnąć Enter. W linii komend należy wpisać vagrant i nacisnąć Enter. Potwierdzeniem poprawnej instalacji będzie wyświetlona lista informacji i pomoc.
Teraz możemy wykorzystać Vagrant do tworzenia wirtualnego środowiska na podstawie plików konfiguracyjnych. Będziemy budować nasze środowisko w oparciu o konfigurację przygotowaną przez VVV. Przejdźmy zatem do pierwszego kroku, czyli pobrania odpowiednich konfiguracji.
Do wykonania poleceń występujących w dalszej część, należy zainstalować system kontroli wersji GIT.
Dla komputerów z systemem operacyjnym Windows instalator można pobrać z .
Lista plików dla pozostałych systemów jest dostępna pod adresem:
Szczegółowa instrukcja instalacji GIT`a pojawi się w osobnym wpisie wprowadzającym do systemów kontroli wersji.
Podążając za dokumentacją zalecaną metodą instalacji jest sklonowanie repozytorium przy użyciu GIT`a. Z poziomu linii komend należy wykonać następujące polecenie:
git clone -b stable
Dzięki niemu system kontroli wersji GIT pobierze i umieści wszystkie niezbędne pliki we wskazanym folderze (podaj nazwę swojego folderu w miejsce ), we wskazanej lokalizacji.
W tym przykładzie docelowy folder nazywa się VVV-3.0.0 i znajduje się na na dysku D:. Komenda klonująca repozytorium do tego folderu wygląda następująco:
git clone -b stable D:/VVV-3.0.0
WAŻNE: Użytkownik musi posiadać uprawnienia administratora do uruchomienia tej komendy, w przeciwnym wypadku maszyna nie uruchomi się poprawnie. Aby uruchomić linię komend jako administrator, należy kliknąć na ikonę prawym przyciskiem myszy i wybrać opcję “Uruchom jako administrator”.
Uruchamianie i zarządzanie wirtualnym środowiskiem przez Vagrant`a odbywa się z linii komend. W celu stworzenia środowiska należy wejść do folderu (stosując linię komend; wszystkie zadania i polecenia wykonujemy z jej poziomu!) w którym znajduje się sklonowany w poprzednim kroku projekt i wykonać komendę vagrant up .
Do zmiany folderu w linii komend stosuje się polecenie cd
Ja sklonowałem projekt do folderu VVV-3.3.0 na dysku D: . Na zdjęciu widać uruchomioną linię komend z wprowadzonymi komendami wejścia do folderu projektowego cd VVV-3.3.0 i w kolejnej linijce wykonanie komendy vagrant up.
Upewnij się, że na używanym dysku masz co najmniej 500mb wolnej pamięci. Przy pierwszym uruchomieniu (czyli użycia komendy vagrant up ) Vagrant pobierze podstawowy wirtualny obraz i wszystkie potrzebne programy, dlatego proces może potrwać kilka minut i należy uzbroić się w cierpliwość. Pobrany obraz będzie posiadał system operacyjny Ubuntu (linux). Obraz zostanie pobrany tylko za pierwszym uruchomieniem vagrant up . Każde kolejne uruchomienie będzie dużo szybsze.
Jeśli proces konfiguracji maszyny zakończył się sukcesem, to po wpisaniu w przeglądarce adresu powinna nam się wyświetlić strona strona zawierająca informacje o stanie naszego środowiska.
Korzystająca z Vagrant`a, nie będziemy musieli otwierać nowego obrazu w VirtualBoxie. Vagrant domyślnie działa w trybie headless, czyli bez warstwy graficznej. Jest zarządzany z linii komend, zaś pliki edytujemy bezpośrednio na naszym komputerze. Vagrant sam poradzi sobie z mapowaniem ścieżek!
Dodanie nowego projektu WordPress
Na ten moment mamy przygotowaną wirtualną maszynę (VirtualBox) z konfiguracją i niezbędnymi programami, automatycznie zainstalowanymi (konfiguracja Vagrant`a). Środowisko uruchamiamy z linii komend, przy pomocy komendy vagrant up . W ostatnim kroku przekonaliśmy się, że taka kombinacja działa. Po wpisaniu w przeglądarce adresu wyświetliła się strona z informacjami o projektach. W tym momencie zapewne pojawiają się pierwsze pytania:
Gdzie znajdują się te projekty? Czy są na wirtualnej maszynie i znikają po jej zamknięciu? Jak można edytować i dodawać pliki? Jeśli pliki są na wirtualnej maszynie, to jest możliwość korzystania z GIT`a lub innego systemu kontroli wersji?
Pytania są w pełni zasadne. Na szczęście mamy na nie przygotowane odpowiedzi, rzucające więcej światła na tak skonfigurowane środowisko.
Po pierwsze pliki znajdują się na naszym komputerze, nie na wirtualnej maszynie. Dlatego nie znikają, gdy kończymy pracę i decydujemy się ją wyłączyć. Wirtualna maszyna wie o miejscu ich położenia dzięki informacjom zawartym w pliku konfiguracyjnym. Plik konfiguracyjny jest czytelny i jego edycja jest prosta (zajmiemy się tym w kolejnych krokach). W nim też będą definiowane nowe projekty. Dzięki temu każdy z nich będzie miał dostęp do tej samej konfiguracji, programów i bazy danych. Wszystkie pliki dodajemy i edytujemy na naszym komputerze w miejscu, gdzie zainstalowaliśmy VVV (sklonowaliśmy), w podfolderze www.
W przykładach VVV został sklonowany do lokalizacji: D:VVV-3.3.0www . Jeśli użyłeś innej, wybranej przez siebie ścieżki, to w takim przypadku musisz pamiętać, że podfolder www znajdzie się właśnie w niej.
Żeby dodać nowy projekt, który będzie widoczny dla VirtualBox i Vagrant`a nie wystarczy po prostu umieścić nowych plików w folderze www Vagranta. W tym celu należy zaktualizować konfigurację zapisaną w pliku config.yml , znajdującą się z kolei w folderze config Vagranta (dla ścieżek użytych w przykładach, znajduje się ona w D:VVV-3.3.0 configconfig.yml ).
W tym pliku należy odnaleźć sekcję sites i dodać w niej nowy projekt w postaci klucz: wartość, zachowując istniejącą notację i wcięcia. Najlepiej to zrobić na podstawie już istniejących wpisów. Należy zatem zdefiniować jego: nazwę, roboczy url oraz bazową konfigurację. Należy pamiętać, że pliki .yml mają strukturę opartą o wcięcia, dlatego należy konsekwentnie stosować się do przyjętych zasad formatowania i używania spacji lub tabulatora podczas edycji pliku.
Fragment pliku konfiguracyjnego, z wybransekcją sites zawierającą domyślny projekt wordpress-one oraz nowy projekt wordpress-dev :
... sites: # latest version of WordPress, can be used for client work and testing # Check the readme at wordpress-one: skip_provisioning: false description: "A standard WP install, useful for building plugins, testing things, etc" repo: hosts: - custom: wpconfig_constants: WP_DEBUG: true WP_DEBUG_LOG: true WP_DISABLE_FATAL_ERROR_HANDLER: true # To disable in WP 5.2 the FER mode ... wordpress-dev: # [1] description: "Projekt szkoleniowy na potrzeby L2C" # [2] repo: # [3] hosts: - # [4] ...
W powyższym fragmencie nowy projekt wordpress-dev został dodany na samym końcu sekcji sites. Na jego konfiguracje składają się:
Nazwa/identyfikator projektu Opis projektu Repo, czyli wskazanie bazowej konfiguracji, na podstawie której Vagrant pobierze domyślne pliki i uruchomi skrypty potrzebne do zainstalowania i skonfigurowania nowego projektu WordPress. W przykładzie korzystamy z domyślnego repozytorium. Adres URL projektu, pod którym będziemy mieli lokalnie dostęp do strony.
Po dodaniu zmian należy ponownie uruchomić Vagranta. Każda zmiana w pliku konfiguracyjnym wymaga uruchomienia ponownie maszyny wirtualnej wraz z prowizjonowaniem! Prowizjonowanie oznacza, że w trakcie uruchamiania środowiska (na skutek wywołania vagrant up ) zostaną automatycznie zainstalowane na wirtualnym wszystkie wymienione w konfiguracji programy czy pobrane wskazane biblioteki i utworzy dla nas wszystkie potrzebne pliki i katalogi projektowe oraz pobierze wszystkie wskazane w konfiguracji biblioteki.
Jeśli maszyna już została uruchomiona należy użyć komendy
vagrant reload --provision
Jeśli maszyna została zatrzymana lub nie była jeszcze uruchamiana należy użyć komendy vagrant up --provision
Teraz można już przetestować nową konfigurację. Po wpisaniu w oknie przeglądarki adresu URL projektu, powinna się wyświetlić podstawowa strona WordPress. Jeśli udało się osiągnąć taki efekt, oznacza to, że podczas procesu konfiguracji nie wystąpiły błędy i jesteśmy gotowi do pracy.
Jak używać Vagranta z GITem i własnym repozytorium
Jeśli korzystasz z systemów kontroli wersji takich jak Git, to na pewno zastanawiasz się jak połączyć nasze środowisko z prywatnym repozytorium (umieszczonym np. na Github). Bezpośrednie sklonowanie repozytorium do folderu public_html nie jest poprawnym rozwiązaniem, ponieważ projekt VVV jest już częścią osobnego repozytorium! Przypomnij sobie, że we wcześniejszych krokach użyliśmy komendy git clone , po to aby to repozytorium sklonować. Możesz się o tym łatwo przekonać, uruchamiając z poziomu folderu projektowego (czyli np. w folderze www/wordpress-one lub w dodanym przez nas www/wordpress-dev ) komendę wyświetlającą tzw. remote (czyli relacje z zewnętrznymi repozytoriami) dla git`a:
Wynik wywołania komendy remote -v dla automatycznie wygenerowanego przez VVV, przykładowego projektu znajdującego się na dyski D, w katalogu VVV-3.3.0.
Żeby połączyć się z własnym repozytorium należy:
zalogować się do uruchomionej wirtualnej maszyny z poziomu konsoli poprzez komendę vagrant ssh . Aby zadziałała, należy wcześniej uruchomić środowisko (w tym celu stosuje się komendę vagrant up ), wejsc do folderu, który jest mapowany na public_html, czyli
vagrant@vvv:~$ cd /srv/www/wordpress-dev/
vagrant@vvv:/srv/www/wordpress-dev$ . Informacje o mapowaniu i o tym, gdzie na wirtualne maszynie znajduje się projekt są wyświetlane w konsoli, w trakcie wykonywania komendy vagrant up skonfigurować GIT`a, aby łączyć się z wybranym repozytorium, korzystając z naszych danych logowania. Czyli należy po kolei ustawić nazwę użytkownika i e-mail:
git config --global "
git config --global "
git remote set-url origin
Vagrant korzysta z tzw. tunelowania ssh, co umożliwia pracę ze wskazanym repozytorium z poziomu wirtualnej maszyny. Pliki istniejące bezpośrednio na dysku, jak widzieliśmy należą do repozytorium VVV, które sklonowaliśmy na samym początku! Teraz jednak udało nam się odpowiednio skonfigurować repozytorium na wirtualnej maszynie i z jej poziomu możemy łączyć się z naszym repozytorium (tutaj: l2c-wordpress-basic-theme). Na poniższym zrzucie ekranu widać wyraźnie różnice między dwoma projektami dostępnymi na wirtualnej maszynie dzięki Vagrantowi. Nasz projekt o nazwie wordpress-dev łączy się z naszym repozytorium l2c-wordpress-basic-theme.git (nazwa własna, wymyślona na potrzeby wpisu) , a projekt poglądowy, domyślnie przygotowany przez Vagrant łączy się z repozytorium Varying-Vagrant-Vagrants/custom-site-template.git.
Różnica w konfiguracji repozytorium na wirtualnej maszynie dla projektów: wordpress-one korzystającego z domyślnego, przykładowego repozytorium i wordpress-dev korzystającego z własnego repozytorium
W tym momencie mamy już w pełni funkcjonalne środowisko do pracy z WordPress i systemem kontroli wersji GIT. Wirtualizacja i Vagrant dają unikalną możliwość tworzenia równolegle istniejących konfiguracji, które nie będą ze sobą kolidowały i będą zamknięte w obrębie VirtualBox`a, bez ingerencji w ustawienia systemowe. Zachęcamy do stosowania właśnie tego rozwiązania do pracy z przyszłymi projektami nowych wtyczek lub szablonów.
Transkrypt
1 Projektowanie oprogramowania systemów NARZĘDZIA PRACY GRUPOWEJ, KONTROLI WERSJI, DOKUMENTOWANIA I ŚLEDZENIA BŁĘDÓW
2 plan wykładu Narzędzia pracy grupowej Edycja grupowa w czasie rzeczywistym Narzędzia Systemy kontroli wersji Podejście rozproszone kontra klient-serwer Wspólny słownik i koncepcje Narzędzia Narzędzia generowania dokumentacji Metajęzyki dokumentowania API Narzędzia Systemy śledzenia błędów Cykl życia bug-a Narzędzia
3 edycja grupowa w czasie rzeczywistym Jak to działa? Zespół (para?) programistów pracuje równocześnie nad tym samym fragmentem kodu Zmiany wprowadzone przez któregokolwiek z członków zespołu są natychmiast widzialne w każdej kopii w ten sam sposób co edycja w Google Docs Do czego to służy? Programowanie w (rozproszonych) parach na sposób XP - natychmiastowa komunikacja między członkami zespołu prowadzi do lepszego zrozumienia logiki kodu przez programistów (w tym piszącego), co skutkuje lepszą jakością kodu Przegląd kodu - jeden członek zespołu wykonuje przegląd kodu w tej samej chwili gdy inni piszą
4 narzędzia programowania ekstremalnego specjalne krzesło albo grupowy, rozproszony edytor
5 typowe cechy Cechy komunikatora internetowego: Roster (lista użytkowników) Chat (grupowy i jeden-dojednego) Współdzielona tablica Edytor kodu Podkreślanie/kolorowanie składni Kolorowanie autorów Wizualizacja obszaru edytowanego przez innych
6 narzędzia Historycznie pierwsze sensowne podejście SubEthaEdit na Macu (komercyjny) Gobby edytor grupowy OpenSource (Unix, Mac, Windows) Działa w trybach p2p i klient-serwer Protokół Obby używany również przez inne narzędzia, m.in.: GNU Emacs z wtyczką Rudel, kompatybilny z Gobby Wieloplatformowy
7 narzędzia Microsoft Visual Studio wtyczka VS Anywhere Komercyjna (darmowa dla studentów) Tylko tryb klient-serwer
8 narzędzia Eclipse wtyczka Saros Darmowa Opiera się na standardowym protokole komunikatorowym - XMPP
9 systemy kontroli wersji kodu (VCS: version control systems) Zarządzanie zmianami kodu na przestrzeni czasu Każda zmiana kodu jest przechowywana ( popełniana ) do repozytorium i jest powiązana z autorem, numerem wersji (rewizji) i datą Członkowie zespołu pobierają ( check out ) pliki projektu z repozytorium i pracują na kopii lokalnej ( kopii roboczej ) Po napisaniu porcji kodu zmiany są wysyłane do repozytorium Pozostali członkowie zespołu uaktualniają swoje kopie robocze, pobierając popełnione zmiany
10 do czego to służy? Pozwala cofnąć się do dowolnego punktu w historii projektu np. kiedy zmiany kodu powodują nowe błędy, można to łatwo wyśledzić Dodatkowa kopia bezpieczeństwa projektu Z każdą popełnioną zmianą można powiązać znaczący komentarz Umożliwia tworzenie równoległych gałęzi (branches) kodu, w których rozwijane są nowe cechy Umożliwia odnaleźć winnych błędów ;>
11 co należy przechowywać w repozytorium VCS Kod źródłowy (poza plikami generowanymi automatycznie) Pliki projektu (poza konfiguracją specyficzną dla maszyny/użytkownika) Zasoby projektu (grafiki, tablice napisów, tłumaczenia ) Skrypty służące do pielęgnacji i budowania projektu (np. skrypty tworzące bazę danych) Wszystko, co niezbędne do zbudowania projektu od zera, a nie jest automatycznie generowane lub dostępne z publicznej lokalizacji
12 czego nie należy przechowywać w repozytorium Plików źródłowych generowanych automatycznie podczas budowania projektu Plików intermediate i wyjściowych binarnych, symboli debugowania, cache IDE ) Niczego, co jest tworzone automatycznie podczas budowania
13 architektury VCS Klient-serwer Tradycyjne podejście Repozytorium ulokowane na pojedynczym serwerze (master) VCS Każdy z członków zespołu używa klienta VCS żeby połączyć się z serwerem i pobrać/popełnić zmiany Implementacje: Subversion Visual SourceSave CVS Dużo dużo innych Rozproszona Nowoczesne podejście Jest wiele repozytoriów, każde zawiera pełną lub częściową kopię Repozytoria mogą być synchronizowane między sobą Kopie robocze członków zespołu są również rozproszonymi repozytoriami Implementacje: Git
14 graf rewizji Rewizje kodu w repozytorium tworzą graf Główna gałąź rozwijana przez cały czas życia projektu to trunk Możliwe dodatkowe gałęzie (branch), np. dla rozwijania eksperymentalnych funkcji Kiedy gałęzie rozwojowe osiągają dojrzałość, mogą być z powrotem włączone (merge) do gałęzi głównej (trunk) Kamienie milowe projektu mogą być oznaczone etykietami (tag), co umożliwia łatwe przełączanie się do wybranego kamienia milowego/wersji oprogramowania Kopia robocza użytkownika może być również postrzegana jako lokalna gałąź, która jest łączona z trunk w momencie kiedy użytkownik popełnia kod (tak to działa w Git)
15 podstawowe operacje w VCS checkout tworzy lokalną kopię roboczą repozytorium (svn checkout git checkout) commit wysyła zmiany z kopii roboczej do repo (svn commit git commit) merge łączy (synchronizuje) zmiany z dwóch gałęzi, być może powodując przy tym konflikt (svn merge git merge) update uaktualnia lokalną kopię roboczą o zmiany popełnione do repozytorium (svn update git pull) branch/tag tworzy gałąź kodu lub nadaje etykietę bazując na ostatniej rewizji pobranej z repozytorium (svn branch / tag git branch / tag) status status kopii roboczej (svn stat git stat) resolve oznacza konflikty jako rozwiązane (svn resolve git resolve) revert wycofuje zmiany wprowadzne w kopii roboczej (svn revert git revert)
16 prosty scenariusz użycia svn checkout
17 prosty scenariusz użycia svn stat svn update svn add sprawdź status kopii roboczej włącz zdalne zmiany do kopii roboczej dodaj nowy plik do kopii roboczej svn commit m [project] added file popełnij lokalne zmiany do zdalnego repo git stat git pull sprawdź status kopii roboczej włącz zdalne zmiany do do lokalnego repo i kopii roboczej git add dodaj nowy plik do kopii roboczej git commit m [project] added file git push origin
18 konflikty wersji Konflikt pojawia się kiedy więcej niż 1 użytkownik równocześnie edytuje to samo Konflikty świadczą o wadliwej komunikacji w zespole projektowym Rodzaje konfliktów Konflikt drzewa zmiana w strukturze plików/katalogów, zmiana nazwy Konflikt edycji wielokrotna edycja tego samego fragmentu plików Konflikt musi być rozwiązany przed możliwością popełnienia zmian do repo
19 narzędzia Narzędzia linii poleceń svn (Subversion); napisz svn --help git (Git); napisz git --help Narzędzia GUI TortoiseSVN (Windows) TortoiseGIT (Windows) GitHub (Windows/Mac) Git Shell Extensions (Windows)
20 narzędzia Integracja z IDE (Integrated Development Environment) AnkhSVN (Subversion for Visual Studio) Subclipse (Subversion for Eclipse) Git is integrated by default both in Visual Studio and Eclipse Dodatkowe narzędzia używane przez VCS diff narzędzie UNIX-owe do generowania plików różnic pomiędzy 2 plikami tekstowymi w formacie tzw. unified diff ; diff jest używany przez prawie wszystkie VCS do wymiany informacji o zmianach pomiędzy rewizjami patch UNIX-owe narzędzie do scalania plików diff z plikami źródłowymi
21 systemy VSC linki
22 narzędzia automatycznej generacji dokumentacji Pisanie kodu jest zbyt zabawne żeby dodatkowo się rozpraszać pisaniem dokumentacji ;) Narzędzia dokumentowania kodu służą do generowania dokumentacji automatycznie, bazując na kodzie wzbogaconym o dodatkowe tagi dokumentujące Tagi i tak trzeba niestety napisać (w formie komentarzy do kodu), ale przynajmniej nie trzeba przełączać się między edytorem dokumentacji a kodem, wszystko pozostaje w pamięci krótkotrwałej i nie powoduje to dekoncentracji W istocie pisanie dokumentacji API jest bardzo podobne do programowania parami i prowadzi do lepszej jakości kodu poprzez wczesne wyłapywanie usterek
23 metajęzyki dokumentacji kodu Niektóre języki mają wbudowany metajęzyk dokumentacji, opisany standardem i rozumiany przez kompilator i IDE Java JavaDoc C# - XML Docs Nie ma oficjalnego standardu dla C i C++ Ale jest de facto standard Doxygen Całe szczęście Doxygen rozumie również JavaDoc i XML Docs, więc jest to uniwersalne narzędzie do wszystkiego
24 cechy doxygen-a Generacja dokumentacji w formatach HTML, PDF, LaTeX, Windows Help, UNIX man i wiele, wiele innych Wsparcie dla wzorów matematycznych (LaTeX), bogatego formatowania i hyperlinkowania kodu Jeden język dokumentowania dla wszystkich sensownych języków programowania
25 doxygen w akcji
26 dodatkowe narzędzia GraphViz Graph Visualization Toolbox narzędzie wizualizacji grafów integrujące się z doxygen, pozwala m.in. automatycznie generować niektóre diagramy UML ( Manual doxygena:
27 systemy śledzenia błędzów Każde oprogramoania ma bugi Programiści starają się zapomnieć o wykrytych bugach jak tylko powrócą do pisania kodu (albo nawet szybciej) ;> Systemy śledzenia błędów (issue tracking systems) służą do zarządzania informacjami o błędach i nie pozwalają leniwym programistom o nich zapomnieć
28 cykl życia buga
29 cechy systemów śledzenia błędów Interfejs webowy dla zgłaszania bugów i zarządzania informacjami o nich Integracja z repozytoriami VCS Hyperlinkowanie raportów o błędach w komentarzach VCS (#3345) Hyperlinkowanie rewizji kodu (r109) w raportach o błędach Przeglądanie repozytorium VCS z poziomu systemu śledzenia błędów Wysyłanie powiadomień o zmianach statusu buga Integracja z IDE interfejsy zorientowane zadaniowo
30
31 narzędzia Bugzilla system śledzenia błędów oryginalnie stworzony dla przeglądarki Mozilla Trac system śledzenia błędów, zarządzania projektem i Wiki napisane w języku python (Open Source) JIRA system zarządzania wdrożeniami dużej skali i śledzenie błędów (komercyjny) Google Code Wiki projektu, repozytorium kodu i system śledzenia błędów dla projektów Open Source Mantis, Launchpad, GNATS i wiele wiele innych
32 Następny slajd jest prawdopodobnie najważniejszy w tej prezentacji
33 wymagania względem Waszego projektu Użycie systemu VCS do zarządzania repozytorium kodu zespołu projektowego Albo serwer dostarczony przez Katedrę, Albo Wasza własna instalacja Git lub SVN, Albo darmowy hosting projektu na GitHub, Google Code lub inny Wyznaczyć jednego z członków zespołu jako maintainer repozytorium odpowiedzialny za jego właściwą strukturę i zachowanie czystości Konsekwentne używanie sensownych komentarzy podczas popełniania zmian kodu Użycie tagów doxygena do dokumentowania Waszego kodu, plik konfiguracji doxygena (doxyfile) przechowywany w repozytorium VCS razem z projektem Użycie systemu śledzenia błędów do zarządzania raportami o bugach Albo serwer dostarczany przez Katedrę, Albo Wasza własna instalacja Trac-a lub Bugzilli (zintegrowana z repo VCS), Albo darmowy hosting projektu, jak wyżej. Integracja w/w narzędzi z wybranym przez Was lub Katedrę IDE
Środowiska programistyczne dostępne na bramce
Na bramce DEV dostępne są środowiska programistyczne, dzięki czemu nie tylko można uruchamiać gotowe programy ale też pisać i uruchamiać własne programy bezpośredion na urządzeniu.
Bramka AIS dom w wersji DEV może być używana tworzenia oprogramowania, edukacji informatycznej i eksperymentów. W kategorii Programowanie umieścimy kilka postów z informacjami o tym, jak zacząć programowanie na bramce. Skupimy się na językach w których napisany jest system Asystent domowy (C, Python, JavaScript i Java).
Pakiet Clang
Opis
Front-end kompilatora dla języków C, C++ oraz Objective-C, który używa LLVM jako back-end (generator kodu natywnego i optymalizator). Jest to alternatywa dla kompilatora z projektu GCC. Prace nad nim sponsorowane są przez Apple, a sam program wydany jest na licencji BSD.
Rola na bramce
Podstawa dla wszystkiego, co działa na bramce. Programy w postaci kodu maszynowego (w postaci binarnej, w slangu komputerowym binarki), które działają na bramce, są kompilowane kompilatorem Clang. Normalnie nie budujemy pakietów na bramce, ale w kontenerze i dostarczamy na bramkę już skompilowane paczki, z naszego repozytorium pakietów apt: Linux main apt repo for Pakiety takie jak Python, Node.js, rclone, Mosquito (broker mqtt) i dziesiątki innych pakietów dostarczane są na bramkę w postaci binarnej z repozytorium apt. Dostępność pakietu Clang na bramce umożliwia też kompilowanie programów bezpośrednio na urządzeniu.
Przykład programu
Można skopilować program w C bezpośrednio na bramce, a następnie uruchomić go z Asystenta domowego. Pokazujemy jak to zrobić na przykładzie:
Przykład najprostszego programu w C Programowanie Przykład najprostszego programu w C Opiszę, jak skompilować program w C bezpośrednio na bramce, a następnie uruchomić go z Asystenta domowego. Tworzymy folder z programami cd AIS/ mkdir programs cd programs Dodajemy nowy plik z kodem cd ~/AIS/programs nano Kod programu: #include
"); return 0; } [image] Kompilujemy nasz program clang Uruchamiamy skompilowaną wersję [image] Uruchamiamy program z Asystenta domoweg…
Python
Pakiet python2 i python3
Opis
Python jest językiem programowania ogólnego przeznaczenia. Ponieważ jest interpretowany, dlatego nie da się instalować pakietów Pythona bez obecności środowiska programistycznego Python na bramce. Obecnie świat używa Python 3, ale wciąż istnieją projekty korzystające z Python 2 dlatego mamy oba te środowiska na urządzeniu.
Rola na bramce
Home Assistant napisany jest w języku Python, wszystkie integracje Home Assistant są napisane w języku Python i najczęściej korzystają z dodatkowych pakietów też napisanych w języku Python.
Przykład programu
Można napisać własny program w Python bezpośrednio na bramce, a następnie uruchomić go z Asystenta domowego. Pokazujemy jak to zrobić na przykładzie:
Hello.py Przykład najprostszego programu w Python Programowanie Przykład najprostszego programu w Python Opiszę, jak dodać program w języku Python, a następnie uruchomić go z Asystenta domowego. Tworzymy folder z programami (jeżeli jeszcze go nie mamy) cd AIS/ mkdir programs cd programs Dodajemy nowy plik z naszym pierwszym kodem cd ~/AIS/programs nano hello.py Kod programu: print("Hello Jolka") [image] Uruchamiamy program python hello.py [image] Interpreter Python na bramce Język Python jest interpretowany, dlatego nie kompilujemy kodu do ko…
JavaScript
Pakiet node
Opis
Node.js to wieloplatformowe środowisko uruchomieniowe o otwartym kodzie do tworzenia aplikacji typu server-side napisanych w języku JavaScript. Podobnie jak Python JavaScript nie jest kompilowany tylko interpretowany, dlatego nie da się instalować pakietów Node.js bez obecności środowiska programistycznego Node.js na bramce.
Rola na bramce
Menedżer procesów działających na bramce to PM2, jest napisany w JavaScript. Te procesy to serwery: ssh, ftp, mqtt, ais (Home Assistant), a także tunnel (zdalny dostęp), webssh (dostęp do konsoli z aplikacji). Dodatkowo po włożeniu dongla zigbee uruchamiany jest proces zigbee2mqtt. Pakiet Zigbee2Mqtt też napisany jest w JavaScript i działa na Node.JS.
Przykład programu
Można napisać własny program w JavaScript bezpośrednio na bramce, a następnie uruchomić go z Asystenta domowego. Pokazujemy jak to zrobić na przykładzie:
Leave a Comment