Przeszukaj forum

Pracuję sam, po co mi kontrola wersji? Jeżeli słyszałeś już o Gicie, prawdopodobnie wiesz że jest doskonałym narzędziem w projektach nad którymi pracuje wiele osób. A co jeśli pracujesz sam? Czy w takim razie Git ma coś do zaoferowania? Tak. Nie musisz nawet łączyć się z internetem żeby korzystać z jego dobrodziejstw. Pomyśl o następujących scenariuszach: Chcesz wrócić do wersji kodu sprzed 2 tygodni, czwartek o 17:12. Albo do wczorajszej, bo wczoraj jeszcze działało a jesteś absolutnie pewien że nic nie ruszałeś Nie pamiętasz po co modyfikowałeś dany plik, albo nawet konkretną linię Fragment programu nie działa, nie wiesz od kiedy. Git pozwoli Ci znaleźć konkretną zmianę, która spowodowała błąd Chcesz wykonać mały eksperyment na boku, bez obaw że zepsujesz "właściwą" wersję programu Chcesz móc sprawdzić jak wyglądały Twoje postępy w projekcie Chcesz łatwo opublikować swój kod w serwisie GitHub aby się nim pochwalić lub pozwolić skorzystać komuś innemu. We wszystkich tych miejscach Git oferuje swoje wsparcie. Dlatego powstał ten artykuł - aby pomóc osobom które piszą programy jako dodatek do swojej pracy w poznaniu podstaw gita i skorzystania z jego dobrodziejstw. Nie ma żadnych specjalnych wymagań - każdy powinien być w stanie skorzystać Jeżeli jesteś zaawansowanym użytkownikiem gita to nic ciekawego tutaj nie znajdziesz, uprzedzam Ten wpis brał udział konkursie na najlepszy artykuł o elektronice lub programowaniu. Sprawdź wyniki oraz listę wszystkich prac » Partnerem tej edycji konkursu (marzec 2020) był popularny producent obwodów drukowanych, firma PCBWay. Model pracy Praca z gitem opiera się na użyciu repozytoriów. Repozytorium to "baza danych" przechowująca informacje o aktualnym oraz historycznym stanie projektu. Na potrzeby początkujących można założyć że jeden projekt = jedno repozytorium. Repozytorium może być lokalne lub zdalne. Lokalne to takie które posiadasz na swoim komputerze. Zdalne, to repozytorium znajdujące się w innej lokalizacji (np. Na githubie) do którego istnieje odwołanie w repo lokalnym. Dzięki temu możliwa jest współpraca nad jednym projektem przez wiele osób. Podstawową jednostką pracy jest commit. Jest to zapisany stan repozytorium w danym momencie. Trochę jak spakowany katalog projektu tylko bardziej inteligentny. Zdecydowana większość codziennej pracy z gitem opiera się na tworzeniu/przeglądaniu i modyfikowaniu commitów. Commit składa się z kilku elementów, m.in.: Zmian które wprowadza Autora Daty utworzenia Komentarza Wartości hash SHA-1 Listy rodziców Commity są unikalne rozróżnialne na podstawie hasha SHA-1. Jest on dosyć długi - w praktyce używa się jego skróconej wersji (pierwsze 6/8 znaków). Commity mogą też dostać dodatkowe identyfikatory poza hashem - będę je nazywał etykietami. Jest kilka rodzajów etykiet. Jedna z nich to tagi. Wyobraź sobie że twój projekt osiągnął wersję 1.0 i chcesz łatwo dotrzeć do konkretnego commita zawierającego tą wersję - możesz stworzyć tag v1.0, v1.0.1 etc aby łatwo to śledzić. Przykładowa lista commitów oraz tagów z projektu PyTorch - widać hashe, autorów, daty oraz komentarze. Innym rodzajem tagów są tzw. gałęzie o których w tym tutorialu będzie po macoszemu (gałęzie są szerokim tematem i na początek do samodzielnej pracy nie są niezbędne). Drzewo Każdy commit (poza pierwszym) ma przynajmniej jednego rodzica - tzn. commit na bazie którego powstał. Tworzy to strukturę podobną do drzewa. Poniższy rysunek przedstawia dwa przykładowe drzewa. Górne jest liniowe, dolne posiada rozgałęzienie. W obu przypadkach commit A jest pierwszym (jako jedyny nie posiada rodzica). Strzałka od X do Y oznacza "X jest potomkiem Y". Dziś skupimy się na przypadku z liniową historią, nie wszystko na raz To co muszę powiedzieć o gałęziach to, że zawsze istnieje domyślna gałąź o nazwie master. W przypadku całkowicie liniowego projektu będzie to jedyna istniejąca. Co to dla nas oznacza póki co? Ostatnio utworzony commit zawsze będzie miał dodatkową etykietę "master" co ilustruje poniższy schemat: Nowo utworzony commit przejmuje etykietę z gałęzią rodzica (ale tylko gałęzią). Dość teorii (na razie) - przejdźmy do praktyki. Instalacja i konfiguracja Będziemy potrzebowali dwóch rzeczy Konto w serwisie GitHub - https://github.com/ - poradzisz sobie sam Git dla Twojego systemu operacyjnego. Pokażę Ci jak go zainstalować dla systemu Windows - https://git-scm.com/downloads Instalacja standardowo polega na klikaniu next. Większość opcji wystarczy pozostawić domyślnymi, proponuję zmienić tylko domyślny edytor tekstowy (git czasami będzie go otwierał, sugeruję wybrać notepad++ zamiast vim). Po instalacji git będzie dostępny z każdego okna konsoli. Osobiście polecam korzystać z Git bash, który instaluje się automatycznie. Aby to zrobić kliknij PPM w dowolnym folderze i wybierz "Git Bash here". Nie ma potrzeby nic konfigurować, ja jedynie zmieniam czcionkę na większą (ppm na pasku tytułu Options/Text). Git bash emuluje podstawowe zachowanie linuksa, dlatego folder w którym jesteś zobaczysz jako np. /d/code zamiast D:\code. (Wszystkie komendy będziemy wykonywać w oknie git bash) Potrzebujemy ustawić dosłownie dwie opcje konfiguracyjne - nazwę użytkownika oraz email. Aby to zrobić wywołaj dwa polecenia (bez znaków ">" oznaczają one które polecenie powinieneś wpisać, linie bez tego znaku są wyjściem zwracamym przez gita): > git config --global user.name "NAZWA UŻYTKOWNIKA" > git config --global user.email "adres@email" Nazwa użytkownika pojawi się przy każdym commicie razem z adresem email. Adres ustaw ten sam na który zarejestrowałeś konto na GitHub. Polecenie git config służy do ustawiania/podglądania opcji konfiguracyjnych. Przełącznik --global oznacza, że chcemy ustawić opcję dla wszystkich repozytoriów - możliwe są różne ustawienia dla każdego repozytorium z osobna. Na końcu znajduje się opcja do ustawienia oraz jej nowa wartość. Projekt Github Aby uprościć nieco sprawę repozytorium załóżmy od razu na githubie. Klikamy na ikonę plusa w prawym górnym rogu i wybieramy new repository. Wpisujemy jego nazwę i zaznaczamy Initialize this repository with a README - github utworzy automatycznie pierwszy commit z readme co nam nieco ułatwi start. Po kliknięciu na Create repository repozytorium zostanie utworzone. To jest nasze zdalne repo. Musimy teraz utworzyć lokalne na jego bazie. Klikamy Clone or download, wybieramy Use HTTPS i kopiujemy URL który się pojawi. Klonowanie repozytorium W oknie git bash przechodzimy do folderu w którym trzymamy projekty (u mnie jest to D:/code) i wpisujemy > git clone SKOPIOWIANY_URL Cloning into 'git-forbot-tutorial'... remote: Enumerating objects: 3, done. remote: Counting objects: 100% (3/3), done. remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 Unpacking objects: 100% (3/3), 607 bytes | 3.00 KiB/s, done. Git utworzył nowy katalog z projektem (sklonował ze zdalnego repozytorium), wejdźmy do niego (cd nazwakatalogu) u wywołajmy polecenie git status. > git status On branch master Your branch is up to date with 'origin/master'. nothing to commit, working tree clean Czytając po kolei: Jesteśmy w gałęzi master (domyślnej) Nasza lokalna gałąź jest aktualna względem zdalnej (origin/master) Nie mamy żadnych zmian widocznych dla gita Od razu warto wyjaśnić czym jest origin - jest to nazwa zdalnego repozytorium. W naszych przykładach origin będzie odnosić się do naszego zdalnego repo na githubie. Odniesienia do zdalnych repo mogą się nazywać dowolnie (i może być ich więcej) origin jest standardową konwencją. Zobaczmy jeszcze wynik polecenia git log > git log commit e95e01842542a0a3a0380a34d863b906838ba1d4 (HEAD -> master, origin/master, origin/HEAD) Author: Mateusz Bednarski <mateusz.bednarski@windowslive.com> Date: Sat Mar 14 23:58:16 2020 +0100 Initial commit Wyświetla ono listę commitów. Widzimy wymienione wcześniej elementy. Warto jeszcze wspomnieć czym jest HEAD - jest to etykieta oznaczająca "aktualny" commit - czyli ten który będzie rodzicem dla nowo utworzonego (po jego utworzeniu HEAD przesunie się automatycznie). Jest jeszcze origin/HEAD ale tym nie musisz się na razie przejmować. Pierwszy commit Najwyższa pora utworzyć pierwszy commit. Przykład będzie w zwykłym C - dla gita nie ma to absolutnie żadnego znaczenia. Tworzymy plik main.c o treści: #include <stdio.h> int main(){ puts("Hello world"); return 0; } Zapytajmy teraz gita o status repozytorium: > git status On branch master Your branch is up to date with 'origin/master'. Untracked files: (use "git add <file>..." to include in what will be committed) main.c nothing added to commit but untracked files present (use "git add" to track) Pojawiły się nowe informacje. Git rozpoznał że w twoim working copy (czyli de facto tym co jest aktualnie w katalogu) pojawił się nowy plik - w stanie untracked. Stan ten oznacza, że git nie będzie się tym plikiem interesował. Aby wskazać, że nowy plik jest częścią projektu wydajemy polecenie: > git add main.c I jeszcze raz git status (na początku zachęcam to wydawanie tej komendy po każdej akcji - w ten sposób szybciej nauczysz się co widzi git). > git status On branch master Your branch is up to date with 'origin/master'. Changes to be committed: (use "git restore --staged <file>..." to unstage) new file: main.c Status zmienił się na staged. Co to oznacza? Plk został dodany do tak zwanego staging area albo index - jest to miejsce gdzie przygotowywany jest następny commit. W gicie tworzenie commita jest dwuetapowe - napierw dodajemy zmiany do indeksu, usuwamy je z niego, modikujemy etc - dowolnie długo do czasu kiedy nasz commit jest gotowy. Wtedy za jednym razem zapisujemy wszystkie zmiany z indeksu jako nowy commit a indeks jest czyszczony i gotowy do przygotowania następnego. Chcemy aby nasz pierwszy commit zawierał tylko tą zmianę więc jesteśmy gotowi na: > git commit -m "Hello world" 1 file changed, 6 insertions(+) create mode 100644 main.c Utworzyliśmy pierwszy commit! Jak widać służy do tego polecenie git commit. Przełącznik -m ustawia komentarz. Jeżeli go pominiesz git uruchomi edytor tekstowy gdzie będziesz mógł go wpisać. Możemy to sprawdzić wydając polecenie git log. > git log Kolejne commity Idziemy za ciosem i dodajmy kolejny. Wyedytujmy plik README: # git-forbot-tutorial A small repository for git tutorial. Oraz main.c #include <stdio.h> int main(){ puts("Hello from git-managed world!"); return 0; } Dodatkowo skompilujmy nasz program gcc main.c Jak zwykle - najpierw git status Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) modified: README.md modified: main.c Untracked files: (use "git add <file>..." to include in what will be committed) a.exe Widzimy, że git rozpoznał zmiany w śledzonych plikach jak również pojawienie się nowego. Dodajmy pliki źródłowe do indeksu git add README.md main.c (sprawdź wynik polecenia git status) Robimy commit git commit -m "Updated readme and hello world message" (sprawdź git status oraz git log) Poznaliśmy najprostszy sposób tworzenia commitów. Ignorowanie plików Pliku a.exe/a.out nie chcemy dodawać ponieważ jest plikiem wynikowym. W repozytorium powinny znajdować się tylko pliki źródłowe. Podobnie nie chcemy aby znalazły się tam pliki tymczasowe lub z logami. Niestety polecenie status będzie je pokazywać za każdym razem zaśmiecając nam obraz sytuacji. Oczywiście istnieje na to sposób - możemy stworzyć plik .gitignore w którym zawrzemy listę wzorców do ignorowania. Zawartość naszego pliku .gitignore *.exe *.out Istnieją generatory takich plików, doskonale nadają się na początkową wersję - np. https://www.gitignore.io/ Zobaczmy status > git status Untracked files: (use "git add <file>..." to include in what will be committed) .gitignore Zgodnie z tym czego oczekiwaliśmy binarka jest zignorowana. Za to plik .gitignore powinniśmy zcommitować. Zrób to sam Wycofywanie zmian Ok, potrafimy już dodawać zmiany. A co z ich usuwaniem? Rozpatrzymy kilka przypadków Sceniariusz 1 Przypadkiem zmodyfikowałem plik i chcę wrócić do wersji z ostatniego commita. Kot przebiegł mi po klawiaturze i mój README wygląda teraz tak: # git-forbot-tutorial A small repository for git tutorial. asdhawgdagwdkaw > git status Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) modified: README.md Aby wrócić do wersji z ostatniego commita wykonaj > git restore README.md To wszystko UWAGA: git restore jest dosyć nowym poleceniem (przez co jeszcze mało popularnym). Inną metodą jest > git checkout -- README.md Secnariusz 2 Dodałem zmiany do indeksu ale jednak nie chcę ich commitować, co robić? Wprowadźmy zmiany do pliku main.c #include <stdio.h> int main(int argc, char** argv){ puts("Hello from git-managed world!"); puts("I can handle args"); return 0; } I dodajemy je do staging area > git add main.c (o git status już nie będę wspominał) Niestety zaszła pomyłka i nowy commit miał wyglądać tak: #include <stdio.h> int main(int argc, char **argv){ puts("Hello from git-managed world!"); puts("I can handle args"); return 0; } Nie ma problemu! Popraw plik i zobaczmy co pokaże status Changes to be committed: (use "git restore --staged <file>..." to unstage) modified: main.c Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) modified: main.c Widać, że plik main.c pojawił się zarówno w staging area jak i jako not staged - interpretacja jest prosta - część zmian została dodana do indeksu a część nie. Jeżeli teraz wykonamy commit to znajdą się tam tylko poprzednio dodane zmiany. My jednak teraz chcemy dodać poprawki, wykonaj git add main.c i sprawdź status a następnie wykonaj commit. Scenariusz 3 A co jeśli nie chcemy poprawiać zmian tylko po prostu je wycofać ze staging area? Wystarczy wykonać > git restore --staged zmiany zostaną wycofane z indeksu ale pozostaną w kopii roboczej. Na przykład: # Modyfikujuemy plik README > git add README.md > git status (przeanalizuj) > git restore --staged > git status (przeanalizuj i sprawdź zawartosc pliku README) IMG Teraz jest dobry moment na pauzę i przećwiczenie samodzielnie powyższych poleceń Usuwanie plików No dobrze, a co jeżeli chcę usunąć plik z repozytorium? Na początek dodajmy nowy plik (może być pusty) > git add info.txt > git commit info.txt -m "Added info" Wydaj polecenie rm info.txt (lub usuń plik z poziomu IDE, wychodzi na to samo) i sprawdź status Changes not staged for commit: (use "git add/rm <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) deleted: info.txt Git zarejestrował usunięcie pliku, teraz wystarczy git add info.txt i git commit Uwaga: istnieje również polecenie git rm które pozwala na usuwanie plików z repozytorium i pozostawienie ich w kopii roboczej. Jest to nieco bardziej zaawansowany temat i teraz go pominę. Tworzenie tagów Wspominałem, że git pozwala dopasowywać dodatkowe etykiety do commitów. Zróbmy to teraz - przyda się za chwilę. Wydaj polecenie git log, wybierz dowolny commit i skopiuj pierwsze 6 znaków jego SHA-1. Następnie wywołaj > git tag -a -m "Version 1.0" v1.0 WYBRANE_SHA Przełącznik -a tworzy tzw "annotated tag" - który zawiera autora, komentarz (dodany przełącznikiem -m). v1.0 to nazwa tagu, na końcu znajduje się hash commita do otagowania. Jeżeli pominiesz ten ostatni, git wybierze aktualny (ten gdzie wskazuje HEAD, ale o tym jeszcze za chwilę). Wykonaj git log aby zobaczyć swój tag [...] commit 6146854e0e8545bbbd5968f29a805d1c728e73a0 (tag: v1.0) [...] Istnieją również "lightweight tag" które zawierają tylko nazwę taga (bez przełączników -a i -m). Ja generalnie rekomenduję użycie tagów zanotowanych - ze względu na większą ilość informacji, lekkich używam tylko do tagów tymczasowych. Przeglądanie historii Na początku mówiłem, że git pozwoli Ci cofać się w czasie - zobaczmy jak to działa. Załóżmy, że chcesz wrócić do konkretnego stanu repozytorium. Zacznijmy od tego otagowanego. Na początek upewnij się że zarówno working copy jak i indeks są czyste - nie jest to wymagane ale będzie ułatwieniem. Aby przejść do historycznej wersji kodu wpisz > git checkout v1.0 Gdzie zamiast v1.0 może być dowolny istniejący tag lub ID commita. Git wypluwa dość długi komunikat - w skrócie repozytorium jest w stanie detached HEAD. Oznacza to, że nie jesteś w żadnej gałęzi. Na tym etapie rekomenduję uznać że taki stan oznacza "nie rób żadnych zmian w kodzie ktore mozesz chcieć zachować" - o tym jak to dokładnie obsłużyć będzie w drugiej części poświęconej gałęziom. To co nas w tej chwili interesuje to fakt "HEAD is now at 6146854 Added .gitignore" - w kopii roboczej znajduje się wersja kodu z tego konkretnego commita i HEAD (czyli wskaźnik "aktualnego" commita) jest tutaj ustawiony. Możesz np. sprawdzić jakie są różnice w pliku main.c względem najnowszego > git diff HEAD master main.c Czyli "pokaż mi różnicę między commitami HEAD oraz master w pliku main.c". Wiesz co oznacza HEAD, przypomnę że master jest etykietą najnowszego commita w gałęzi master. Git diff ma dużo więcej możliwości, zachęcam do zapoznania się z dokumentacją. Ok, zrobiliśmy inspekcję i chcemy wrócić do mastera. Co zrobić? Wystarczy wywołać > git checkout master Wrócimy do naszej gałęzi, HEAD zostanie również odpowiednio ustawiony. Przywracanie plików w wersji historycznej Załóżmy, że znalazłeś w którym miejscu historii wprowadziłeś błąd i chcesz przywrócić historyczną wersję pliku. Wystarczy wykonać > git checkout ID_COMMITA nazwa_pliku Czyli "przywróć plik nazwa_pliku z commita o id ID_COMMITA" gdzie id może być skrócony hash lub tag. Zmiana od razu wyląduje w staging area. (o wykonywaniu git status nie muszę przypominać ) Podsumowanie (niektórych) operacji Synchronizacja ze zdalnym repozytorium Kiedy wejdziesz na swoje repozytorium na githubie zobaczysz że nic się nie zmieniło - taka jest idea gita - system jest rozproszony i wszystkie zmiany dzieją się lokalnie. Aby przekazać swoje zmiany do zdalnego repozytorium wydaj polecenie: > git push Git poprosi Cię o zalogowanie się. Po pomyślnym wykonaniu polecenia odśwież stronę i zobaczysz swoje zmiany. Istnieje również możliwość pracy bez podawania hasła, przy użyciu klucza SSH. Dobre praktyki Git jak każde narzędzie zaawansowane narzędzie pokazuje pełnię mocy jeśli jest używany poprawnie. Wymaga to nieco doświadczenia ale jest kilka dobrych praktyk, które mozesz wdrożyć od razu: Wiadomości w commitach powinne być dokładne Jeden commit = jedna zmiana (w sensie logicznym, jak najbardziej może to być wiele plików) Staraj trzymać się working copy czyste, sytuacja kiedy przed tygodnie masz untracked files i nie dodałeś ich do gitignore "bo później się przydadzą" to proszenie się o kłopoty Commituj często - ja w pracy zwykle robię ok. 10 commitów dziennie Często używaj poleceń log oraz status Zanim zaczniesz używać gita w swojej pracy magisterskiej nabierz nieco doświadczenia na mniejszym projekcie Wypróbuj narzędzie gitk do graficznego przeglądania drzewa Nie rekomenduję używania narzędzi do obsługi gita wbudowanych w IDE - często robią one więcej niż sugerują nazwy poleceń Git miejscami jest mało intuicyjny, nie zrażaj się że czegoś od razu nie rozumiesz. Interfejs programu gitk Zakończenie części pierwszej Ufff, spro informacji jak na jeden raz. Jeżeli mój styl pisania się Wam spodoba to przygotuję drugą część gdzie opiszę dokładniej jak pracować ze zdalnym repozytorium oraz gałęziami. Niemniej posiadasz już podstawową wiedzę, która pozwoli Ci korzystać z dobrodziejstw Gita. Powodzenia

Witajcie. Chciałbym Wam przedstawić prosty sposób wykorzystania modułu ESP-32, który użyłem do stworzenia urządzenia, za pomocą którego możecie śledzić poziom zainteresowania wybranym repozytorium GitHub. Dzięki wbudowanym dwóm wyświetlaczom, będziecie na bieżąco informowani o: aktualnej liczbie gwiazdek dziennej liczbie gwiazdek aktualnej liczbie obserwujących aktualnej liczbie forków Początkowo chciałem skorzystać ze starszego modułu ESP8266 12-F, jednak napotkałem problem który objawiał się przy wykonywaniu requesta do api GitHub. Podczas oczekiwania na odpowiedź z serwera, na wyświetlaczach zanikały wszystkie cyfry i wyglądało to jakby coś było nie tak z urządzeniem. Z pomocą przyszedł układ ESP-32, który oparty jest na dwóch rdzeniach. Była to świetna okazja aby zapoznać się z tym modułem, ponieważ wcześniejsze projekty wykonywałem na ESP8266. Użycie nowszej odsłony ESP, pozwoliło mi wysyłać requesty asynchronicznie. Do działania ramki wymagane jest połączenie z siecią poprzez WiFi. Tutaj świetnie sprawdziła się biblioteka "WiFi Manager", która umożliwiła mi szybkie podłączenie ramki do dowolnej sieci. Jeżeli chodzi o zasilanie to jest to napięcie 5V, które podaje poprzez wtyki USB. W obudowie ramki znajdują się trzy przyciski. Pierwszy służy jako włącznik. Pozostałe dwa to włączniki chwilowe. Po wciśnięciu pierwszego na wyświetlaczu prezentowany jest adres IP, który wykorzystujemy przy konfiguracji. Natomiast drugi przycisk resetuje liczbę gwiazdek z dnia. Do układu podłączona jest 3 kolorowa dioda LED, która informuje nas o stanie połączenia: CZERWONY – brak sieci, błąd podczas pobierania danych ZIELONY – połączenie sieciowe ustanowione, dane pobrane poprawnie NIEBIESKI – tryb access pointu ( zanik sieci ) Domyślnie odświeżanie danych odbywa się co 90 sekund. Oczywiście interwał można zmienić. Ale należy uważać, aby nie wykonywać do api GitHub więcej niż 60 requestów na godzinę, ponieważ serwer ma ustawiony RateLimit. Po przekroczeniu ilości zapytań zostaniemy zablokowani na godzinę. Jak już wspomniałem wyżej, pod adresem IP jaki przydzielony został do urządzenia działa prosty web server, który serwuje nam stronę z konfiguracją, gdzie musimy wprowadzić nazwę użytkownika repozytorium oraz nazwę repozytorium które chcemy obserwować. Po zapisaniu konfiguracji w pamięci EEPROM urządzenie jest restartowane i gotowe do użycia. Dodatkowym atutem urządzenia jest automatyczna aktualizacja oprogramowania poprzez HTTPS OTA. Sprawdzanie wersji następuje podczas uruchomienia oraz po północy. Urządzenie jest w pełni bezobsługowe. Gdy wystąpi zanik sieci, ESP cały czas będzie próbowało nawiązać połączenie za pośrednictwem zapamiętanych poświadczeń. Jeśli sieć nie będzie dostępna, przełączy się w tryb access pointu ( ssid: "GITHUB-FRAME"). Jeśli nie zostanie wybrana nowa sieć w menadżerze sieci, to po czasie 3 minut, nastąpi restart i proces się powtórzy. Tak pokrótce, wygląda zasada działania całego układu. Poniżej przedstawię Wam główne etapy budowy całej ramki. A więc zaczynamy. LISTA ELEMENTÓW: ESP-32 WROOM DevKit 1.0 – 1 szt. Wyświetlacz LED 4-Cyfrowy TM1637 – 0.56" – 1 szt. Wyświetlacz LED 4-Cyfrowy TM1637 - 0.36" – 1 szt. 4-pinowy przewód, żeński – żeński – raster 2.54 – 4 szt. Gniazdo + wtyk, JST – JST – 2 szt. Gniazdo + wtyk, mikro JST – mikro JST – 2 szt. Płytka uniwersalna PCB 50x70mm PI-01 – 1 szt. Rezystor węglowy – 220 ohm – 5 szt. Rezystor węglowy – 2,2k ohm – 3 szt. Zworki do płytek stykowych - 1 zestaw Wtyk goldpin kątowy 4 pinowy, raster 2,54mm – 4 szt. Dioda LED 5mm RGB wsp. Anoda – 1 szt. Dioda LED 3mm biała – 3 szt. Przełącznik chwilowy okrągły – 10mm – 2 szt. Przełącznik kołyskowy ON-OFF – 1 szt. Kabel USB A – USB micro – 1 szt. Zasilacz 5V z gniazdem USB A – 1 szt. Rurki termokurczliwe - 1 szt. Ramka IKEA RIBBA – 21x30cm ( ważne żeby była dość głęboka, aby zmieścić elektronkę ) – 1 szt. Papier samoprzylepny do drukarki – 1 szt. Rura elektroinstalacyjna RLM 16 – 1 szt. NARZĘDZIA: Lutownica Cyna Obcążki Wiertarka lub wkrętarka Wiertła: 7, 10, 13 Pistolet do kleju na gorąco Nóż Drukarka ZAŁOŻENIA: Stabilność działania Intuicyjna obsługa Szybka adaptacja w miejscu instalacji Estetyka Plan Początkowo ramka miała powstać pod konkretnie wybrane repozytorium i wyświetlać tylko liczbę gwiazdek. Ale stwierdziłem, że i tak pobieram inne dane z endpointa api to czemu miałbym ich nie wyświetlić. Postanowiłem, że dodam dwa nowe klucze: "forks" oraz "watchers" i wyświetlać je kolejno w 5 sekundowym odstępie czasowym. Jeżeli chodzi o repozytorium, to dając możliwość wprowadzenia własnych ustawień url-a, zwiększyłem tym samym skalowalność przedsięwzięcia. Do tego doszły automatycznie aktualizacje software-u. Więc taką ramkę może stworzyć każda osoba, która chociaż trochę ma pojęcie o informatyce i niekoniecznie zna się na programowaniu. BUDOWA Prace nad ramką rozpocząłem od budowy prototypu metodą na "pająka". W tym celu skorzystałem z płytki prototypowej, przycisków typu "tact switch", paru zworek oraz kilkunastu przewodów do połączenia wszystkiego w całość. Całe oprogramowanie zostało napisane za pośrednictwem Arduino IDE czyli w języku C. Gdy miałem już działający prototyp, rozpocząłem prace nad przeniesieniem całości na uniwersalną płytkę PCB. Zadanie wydawałoby się proste ale wymagało procesu planowania. W tym celu wykorzystałem oprogramowanie Fritzing. Oprogramowanie to umożliwia stworzenie całej dokumentacji projektu. Na tę chwilę wykorzystałem tylko narzędzie do stworzenia szkicu płytki prototypowej. Mając gotowy już projekt z rozlokowaniem wszystkich elementów i połączeń. Mogłem przystąpić do lutowania. Jak widać na zdjęciach, podczas montażu elementów używałem uchwytu, który stabilnie trzyma płytkę w miejscu. Bardzo ułatwił mi pracę. Po przylutowaniu wszystkich elementów elektronicznych, wlutowałem przewody z gniazdami, dzięki którym będę mógł odłączyć układ od samej konstrukcji ramki Teraz przyszedł czas na najtrudniejszy etap jakim było dostosowanie drewnianej ramki do potrzeb projektu. W programie Photoshop stworzyłem szablon do wiercenia i wycinania potrzebnych otworów. Szablony te znajdziecie również w repozytorium projektu. Po wydrukowaniu szablonu przykleiłem kartkę do “pleców ramki” i wyciąłem wszystkie otwory. Trochę trzeba się do tego przyłożyć i mieć sporo cierpliwości. Cięcie, pasowanie, cięcie, pasowanie aż do skutku. Ufff. W końcu mogłem przystąpić do zamontowania wyświetlaczy oraz diod LED. Z pomocą przyszedł mi klej na gorąco. Trzyma mocno i pewnie, wystarczająco do tego typu prac. Trzy diody LED umieściłem w przyciętych krążkach z białej rury pcv ( tych do prowadzenia przewodów po ścianach ) a górę zaślepiłem kawałkiem plastiku w którym zamocowałem diody. A tak całość prezentuje się od frontu Za pomocą 4 żyłowych przewodów zakończonych wtykami żeńskimi, połączyłem wszystkie elementy z główną płytką. W celu szybszej identyfikacji przewodów, oznaczyłem każde połączenie za pomocą lakierów do paznokci ( pozdrawiam swoją żonę Magdalenę ). Główny układ przykleiłem do pleców ramki również za pomocą kleju na gorąco. Na koniec pomalowałem cały front na biało farbą emulsyjną, ponieważ papier który używa się w drukarkach ma małą gramaturę co sprawia, że jest półprzezroczysty. Dzięki podbiciu koloru tła biel będzie intensywniejsza. W ostatecznej wersji grafikę wydrukowałem na papierze fotograficznym, który jest na tyle gruby, że malowanie okazało się być zbędne. SOFTWARE Cały program opiera się na dwóch pętlach. Pierwsza pętla Task1, sprawdza czy użytkownik wprowadził url repozytorium z którego mają zostać pobrane dane. Jeżeli konfiguracja została wprowadzona, program wywołuje funkcję getData(), która odpowiedzialna jest za pobranie danych z API. Interwał tej pętli definiuje zmienna requestInterval, która domyślnie posiada wartość 90 ( czyli 90 sekund). Druga pętla Task2, służy do wyświetlania odpowiednich danych na wyświetlaczach oraz podświetlania ikon. Tutaj również sprawdzany jest stan na pinach 27 i 15 ( przyciski BUTTON_IP oraz BUTTON_RESET_TODAY). Interwał tej pętli to około 15 sekund. Po północy następuje sprawdzenie dostępności nowszej wersji oprogramowania oraz resetowany jest licznik gwiazdek otrzymanych w ciągu całego dnia. Poniżej znajdziecie link do repozytorium z projektem: OPROGRAMOWANIE + SZABLONY DO DRUKU PODSUMOWANIE Przyznam się szczerze, że prototyp urządzenia miałem już gotowy rok temu. Ale ze względu na gruntowny remont mieszkania musiałem odsunąć hobby na dalszy plan. Rozciągnięcie projektu w czasie sprawiło, że przy każdym powrocie zawsze coś zmieniałem, rozbudowywałem. Wszystko wtedy można przemyśleć kilka razy i na spokojnie zastanowić się nad rozwiązaniem jakiegoś problemu. Na co dzień zajmuję się programowaniem front-endu, ale dzięki takim projektom mogę połączyć moje główne zainteresowania: majsterkowanie, elektronikę, grafikę i jak już wcześniej wspomniałem, programowanie i stworzyć coś namacalnego i cieszącego oko. Zachęcam wszystkich do twórczego działania i poszerzania swojej wiedzy. Tego typu projekty dadzą Wam satysfakcję, świetną zabawę oraz sporo nauczą. Także klawiatury, lutownice, piły, śrubokręty, wiertarki w dłoń i do działania! Instrukcję już macie Do następnego projektu! Pozdrawiam.