Na ostatnim livestreamie opowiadałem o pracy zdalnej w embedded. W związku z aktualną epidemią temat jest na czasie i pewnie wiele osób i całych firm szuka podpowiedzi jak przejść na pracę zdalną. Szczególnie jeśli nigdy wcześniej tego nie próbowaliście, a teraz nagle wszyscy muszą pracować z domów. W tym artykule zebrałem najważniejsze informacje, które również omawiam w wersji wideo:
Jak to wyglądało przed epidemią?
Jako, że obecna sytuacja – mam nadzieję – kiedyś się skończy, zacznę od opisania jak to wyglądało z pracą zdalną w embedded w normalnych warunkach.
Mało kto zgodzi się na pracę w 100% z domu. Największym problemem oczywiście jest praca ze sprzętem. Często zajmuje on dużo miejsca, może się uszkodzić w transporcie, jest objęty jakimiś tajemnicami handlowymi, NDA, IP itp. Na płytkach PCB – szczególnie we wczesnej fazie projektu – czasem trzeba robić jakieś zmiany. Musimy lutować, zamieniać PCB na nowsze wersje, robić pomiary, lutować. Do tego czasami taki sprzęt po prostu się psuje.
Jak widać z HW mamy całą masę problemów. Ale to nie koniec! Okazuje się, że nawet firmy, gdzie do pracy potrzebujemy jedynie laptopa np. we frontendzie często nie pozwalają na pracę zdalną. A już na pewno nie na nieograniczoną pracę zdalną. Tutaj blokadą są zwykle kultura firmy, chęć kontroli i potrzeba komunikacji twarzą w twarz.
Projekt, gdzie mogłem pracować z domu kiedy chcę zdarzył mi się tylko raz. Więcej w wideo wyżej. Za to praca zdalna raz na jakiś czas np. przez jeden tydzień, albo jeden dzień w tygodniu przez dłuższy czas jest jak najbardziej możliwa do osiągnięcia. Chociaż też nie wszędzie.
Pomijam tutaj freelancing, czy startupy, bo tam wszystko jest możliwe i zależy tylko od negocjacji.
Gaszenie pożaru – jak szybko przejść na pracę zdalną
Pierwsza uwaga kierowana jest do managerów – nie kontrolujcie, czy pracownik siedzi przed komputerem przy pomocy kamery! Nie dość, że poczucie bycia kontrolowanym i to we własnym domu źle się odbija na psychice i niszczy produktywność to jeszcze nie ma żadnego sensu biznesowego. Ważne jest, czy zadania posuwają się do przodu i czy nie ma jakiś blockerów. Aby to sprawdzić, wystarczy zajrzeć do JIRY albo zapytać, jak idą postępy.
Minimalny zestaw potrzebnych narzędzi
Dobra, to tyle w temacie czego nie robić. Odpowiedzmy sobie teraz na pytanie jaki jest minimalny zestaw narzędzi potrzebnych do pracy zdalnej w embedded:
- Komunikator tekstowy – przydatna jest opcja kanałów tematycznych. Dlatego najlepiej sprawdzi się Slack albo Discord (wszystkie narzędzia opisane z linkami na końcu artykułu).
- Komunikator głosowy – Czasem trudno coś wytłumaczyć tekstowo i nic nie zastąpi zwykłej rozmowy. W tym celu sprawdzi się np. Skype For Business, Discord (do 10 osób), Slack chyba też ma taką opcję, ale nie znam szczegółów.
- Udostępnianie ekranu – będzie potrzebne do prezentacji i do pomocy przy problemach w kodzie.
- Dokumentacja tekstowa – nawet jak do tej pory wyznawaliście zasadę „wiedza jest w ludziach”, przy pracy zdalnej spisywanie dokumentacji jest o wiele efektywniejsze. Przy okazji tłumaczenia komuś problemu można ją na bieżąco rozszerzać. W tym celu można użyć Markdown. Czy to w formie wiki projektu, czy w specjalnym folderze w projekcie.
- System kontroli wersji – aż głupio pisać o tak podstawowych narzędziach, ale bez kontroli wersji ani rusz. System rozproszony jak Git ogólnie jest lepszy niż scentralizowany jak SVN, ale przy pracy zdalnej jest to dodatkowo ważne.
- Minimalny zestaw sprzętu do pracy z domu – płytka produkcyjna, debuger, zasilacz, podstawowa aparatura pomiarowa.
Tyle musisz wiedzieć na początku, żeby przetrwać. Na dłuższą metę warto rozbudować swoje narzędzia i procesy. Więcej dowiesz się w kolejnych rozdziałach i w wideo.
Komunikacja – Async remote
Termin async remote w swojej nazwie ma dwie ważne cechy. Remote (zdalnie), czyli poszczególne osoby nie znajdują się w tym samym miejscu. I async (asynchronicznie), czyli odbiorca może odczytać naszą wiadomość dopiero po jakimś czasie.
Takie podejście ma bardzo poważne implikacje. Po pierwsze nie możemy w dowolnym momencie podejść do czyjegoś biurka i zapytać jak to działa. Dlatego właśnie ważna jest dokumentacja. Poza tym powinniśmy z wyprzedzeniem zebrać potrzebne informacje. Zwolennicy async remote twierdzą, że taka praca jest bardziej efektywna niż model tradycyjny. Możemy sobie zorganizować lepiej czas na komunikację i czas na „deep work” i „bycie we flow”.
Async remote to stan umysłu
Podejście async remote i ogólnie praca zdalna wymagają zmiany podejścia. Szczególnie ze strony managerów. Nie da się pracować zdalnie bez zaufania i autonomii. W wielu przypadkach zarządzanie opiera się jednak na kontroli i przyzwyczajenie się do nowego stylu pracy może być trudne i trochę potrwać. Stąd właśnie pomysł z kamerkami. Ale tak naprawdę od pracownika oczekujemy realizacji postawionych zadań i właśnie to powinno być monitorowane. Przy okazji sprawdzenie statusów JIRY, czy krótki update stanu prac od wczoraj zajmuje dużo mniej czasu i uwagi, niż kontrolowanie każdego.
Asynchroniczne daily
Rozwiązaniem, które bardzo sobie chwalę jest asynchroniczne daily. Na kanale na Slacku każdy członek zespołu codziennie pisze co zrobił wczoraj, co planuje dzisiaj i ewentualnie jakie ma problemy i inne tematy do przegadania.
Transfer wiedzy
Kolejnym problemem związanym z komunikacją jest transfer wiedzy i pomoc przy problemach np. debugowanie. Tutaj naszym przyjacielem są czat głosowy i pokazywanie pulpitu. Możemy w ten sposób debugować, tłumaczyć problemy albo programować w parach.
Firmy full remote
Async remote to wręcz filozofia niektórych osób i całych firm. Produkują one duże ilości praktycznych treści na ten temat. Szczególnie polecam tutaj firmę Arkency i jej założyciela Andrzeja Krzywdę. Inną polską firmą promującą pracę zdalną jest Nozbe. Istnieje też wiele zagranicznych firm promujących pracę zdalną. Na przykład GitLab jest w pełni zdalny. Dodatkowe materiały znajdziecie na końcu artykułu.
Typowe problemy
Typowe problemy dotyczące pracy zdalnej w ogóle są już szeroko opisane i znajdziecie je w źródłach. Do tych problemów należą:
- Brak kontaktu z ludźmi
- Pomieszanie obowiązków zawodowych i domowych
- Ustalenie granic z innymi domownikami
- Potrzeba zachowania rutyny
Przejdźmy więc do problemów specyficznych dla embedded. Wyróżniłbym tutaj:
- Zawieszający się sprzęt.
- Awarie – odpadające przewody, spalenie sprzętu, zniszczenie mechaniczne.
- Sprzęt wielkogabarytowy, którego nie możemy trzymać w domu.
- Potrzeba integracji z kodem innych osób i zewnętrznym sprzętem.
- Wiedza plemienna i rytuały dotyczące sprzętu.
- Lutowanie i aparatura pomiarowa.
- Testy na większej ilości sprzętu są niemożliwe.
- Sprzęt zajmuje dużo miejsca w domu, albo jest narażony na uszkodzenie (głównie przez dzieci lub koty :D)
Niektórych z nich nie da się przeskoczyć. Jak robimy sterownik na silnik ważący tonę po prostu nie przeniesiemy go do domu – musimy go jakoś zamockować. Możemy więc użyć jakiś rozwiązań zastępczych na poziomie softu i sprzętu, aby móc normalnie pracować. Wiele z tych praktyk usprawnia pracę również, kiedy jesteśmy w biurze.
Rozwiązania sprzętowe
Za pomocą odpowiednich rozwiązań sprzętowych możemy odczytywać i zadawać sygnały, debugować na odległość, czy resetować zawieszony sprzęt. Poniżej opiszę kilka podstawowych rozwiązań.
Zasilacz programowalny
Zasilacz laboratoryjny zawierający port szeregowy, czy USB. Można z terminala wydawać mu komendy typu „OUT1” (włącz zasilanie), „OUT0” (wyłącz zasilanie), „VOUT 15.0” (ustaw napięcie 15V), „IOUT 1.5” (ustaw prąd 1.5 A). Na streamie pokazywałem Korad KA3005P, który mam w domu, ale inne opcje są równie dobre.
Analizator logiczny
Analizator stanów logicznych każdy powinien mieć na biurku. W debugu jest nieoceniony, a kosztuje 40 zł.
Sniffery komunikacji
Sniffery są już trochę droższe i służą do podglądania ramek protokołów komunikacyjnych. Dla różnych interfejsów i protokołów potrzebujemy różnych snifferów. Na przykład dla komunikacji SPI i I2C możemy użyć Aardvarka. Sniffery takie jak ten mają często API pozwalające pisać testy automatyczne.
Symulatory
Odpalane na PC symulują działanie procesora na poziomie pojedynczych instrukcji, rejestrów i peryferiów. Zwykle są dostarczane przez producentów chipów i ich jakość niestety pozostawia wiele do życzenia. Jest też rozwiązanie open-source do ARM – QEMU. QEMU działa lepiej i jest wykorzystywane np. w satelicie PW-SAT2.
Konsola debugowa
Dodatkowy UART na płytce na który można wystawiać logi, statystyki, komendy i cokolwiek potrzebujemy. Możemy też użyć jej do wypluwania wyników unit testów na sprzęcie.
Test pady
Specjalne miejsca na debugowych płytkach PCB pozwalające łatwiej podłączyć aparaturę pomiarową i obserwować sygnały. Jeżeli zadbamy o to na poziomie projektu PCB, możemy sobie ułatwić automatyzację, czy zdalne debugowanie.
Zdalny debug
GDB daje możliwość łączenia się zdalnie na określonym porcie TCP. Inne debugery często nie mają takiej opcji. Wtedy pozostaje nam użycie zdalnego pulpitu i obsługa debugera w ten sposób.
Rozwiązania w sofcie
Z pomocą sprzętowi przychodzą oczywiście różne rozwiązania związane z oprogramowaniem.
Build system
System budowania projektu powinien być niezależny od systemu operacyjnego, IDE, czy ścieżek w systemie. Najlepiej osiągnąć to przy użyciu systemów takich jak CMake, Meson, SCons. Pod spodem mogą one też wykorzystywać GNU Make, czy Ninja. Mając takie narzędzia uchronimy się od problemów związanych z uruchamianiem projektu na różnych platformach.
Unit testy
Dzięki zastosowaniu unit testów i pracy zgodnie z Test Driven Development możemy przez długi czas nie uruchamiać w ogóle programu na sprzęcie. Oszczędzamy w ten sposób ogromną ilość czasu na wgrywanie binarek i ręczne debugowanie.
Continuous Integration + smoke testy HW
Dzięki CI osoby pracujące niezależnie od siebie mają pewność, że aktualna wersja kodu działa poprawnie. Przy każdym pushu do gita, albo co wieczór CI buduje projekt i wykonuje testy automatyczne, a raport umieszcza na stronie. W razie błędu może też wysłać maila do wszystkich. Najpopularniejszym rozwiązaniem tego typu jest Jenkins.
W embedded CI wymaga jednego ważnego usprawnienia. Aby mieć pewność, że program działa nie wystarczy wykonać testów na serwerze. Niezbędny jest pewien zestaw testów na docelowym sprzęcie, który przejdzie przez wszystkie najważniejsze przypadki i zapewni nas, że integracja ze sprzętem również działa poprawnie.
Takie testy automatyczne można przeprowadzić wgrywając testowe binarki na sprzęt sprawdzające fragmenty kodu produkcyjnego w odpowiednim frameworku testowym. Inny rodzaj testów zakłada, że wgrywamy produkcyjną binarkę i testujemy wejścia i wyjścia. W tym celu przydają się zasilacze sterowane, konsola debugowa i uruchamianie debugera z linii komend.
Code Review
Code review w przypadku pracy zdalnej nabiera dodatkowego znaczenia. Najlepiej zintegrować je z całym procesem – merge do głównej gałęzi tylko jeżeli kod przejdzie pomyślnie review. W ten sposób dodatkowo zmniejszamy ryzyko, że wysadzimy build, a ktoś inny będzie chciał pracować z kodem kiedy nas nie będzie.
Dodatkową zaletą code review jest transfer wiedzy. Zarówno tej stricte programistycznej, jak i o domenie systemu.
Ułatwienia w architekturze
Aby dało się nad projektem pracować w kilka osób, poszczególne moduły muszą być od siebie dobrze odseparowane. Im mniejsze interakcje między elementami systemu, tym developerzy będą mniej wchodzić sobie w paradę.
Drugim aspektem, ale powiązanym jest testowalność. Ale tak naprawdę testowalność i modularność są ze sobą mocno powiązane. Aby moduł był testowalny, powinien zawierać jak najmniej zależności zewnętrznych.
Źródła
Komunikacja
Komunikacja w pracy zdalnej: https://blog.arkency.com/2016/10/overcommunication-is-required-for-async-slash-remote-work/
Dalej o komunikacji: https://blog.arkency.com/2014/06/effective-async-communication/
Podcast DevTalk o pracy zdalnej: https://www.youtube.com/watch?v=FOSSJzqYG88
Książka „Async Remote”: https://blog.arkency.com/async-remote/
Wpisy i wideo o pracy zdalnej po polsku: https://nozbe.com/pl/featured-tags/remote-work-and-nozbe-team
Remote Manifesto: https://about.gitlab.com/company/culture/all-remote/guide/
https://blog.remote.com/why-you-should-be-doing-async-work
Sprzęt
Zasilacz programowalny: KD3005P – https://botland.com.pl/pl/zasilacze-laboratoryjne/5496-zasilacz-laboratoryjny-korad-kd3005p-0-30v-5a-usb-5903351240826.html
Remote debug w GDB :
http:// http://davis.lbl.gov/Manuals/GDB/gdb_17.html
https://www.thegeekstuff.com/2014/04/gdbserver-example/
https://ucgosu.pl/2017/02/uruchomienie-szablonu-projektu-stm32-eclipse
QEMU:
https://wiki.qemu.org/Documentation
https://gnu-mcu-eclipse.github.io/debug/qemu/
https://medium.com/@ly.lee/stm32-blue-pill-unit-testing-with-qemu-blue-pill-emulator-9d88002a68b2
Narzędzia
Slack: https://slack.com – Jest narzędziem dedykowanym do pracy zdalnej i ogólnie komunikacji tekstowej programistów. Posiada integracje z popularnymi narzędziami jak Jenkins, czy Jira.
Discord: https://discordapp.com/ – Discord został stworzony z myślą o graczach, ale posiada wszystkie funkcje potrzebne do pracy zdalnej w tym kanały głosowe do 10 osób i możliwość streamowania ekranu.
Dodaj komentarz