Kategoria: Programowanie

Pod koniec lutego byłem na targach i konferencji Embedded World 2019. Poza relacją z samego wydarzenia (do przeczytania pod tym linkiem) postanowiłem opisać tematy poruszane na prezentacjach z części konferencyjnej. Było już więc o Embedded Security i o systemach operacyjnych czasu rzeczywistego. Dzisiaj pora na kolejny duży temat jakim jest jakość oprogramowania. Będzie więc o standardzie MISRA C, statycznej analizie i zwinnym podejściu do wytwarzania systemów safety-critical. Każdy z tych tematów posiadał oddzielną ścieżkę podczas konferencji. W przeciwieństwie do wpisu o RTOSach nie będę opisywał każdej prezentacji po kolei. Zamiast tego opiszę konkluzje płynące z każdej ze ścieżek.

Podczas Embedded World jednym z często powtarzających się tematów były systemy operacyjne czasu rzeczywistego, czyli RTOSy. Nie zabrakło także Linuxa. W tym wpisie opiszę kilka prezentacji na ten temat.

Podczas Embedded World 2019 dużo miejsca poświęcono tematowi Embedded Security. To wyraźne odwrócenie trendu ignorowania problemów podatności i zabezpieczeń tego typu systemów, które dominowało do tej pory. Na pewno duży wpływ na to ma rozwój Internet Of Things zapewniający nam stały dopływ niezabezpieczonych urządzeń. Swoje w tym temacie na pewno zrobiły też podatności związane z hardware’m takie jak Meltdown i Spectre. Sam w żadnym wypadku nie uważam się od eksperta od Embedded Security, ale chętnie podzielę się wiedzą otrzymaną podczas konferencji i dołożę cegiełkę do zwiększania świadomości programistów o tego typu zagrożeniach.

W dniach 26-28 lutego byłem w Norynberdze na targach i konferencji Embedded World 2019. Jest to jedno z największych wydarzeń tego typu w Europie. Na liście mailingowej oraz w social mediach pisałem już co nieco na ten temat. Teraz pora na obszerniejszą relację.

Po ostatnim artykule, gdzie opisałem, co trzeba umieć do pierwszej pracy, dostałem od Was pytania jak zdobyć wymaganą wiedzę. Z jakich kursów korzystać? Jakie książki czytać? Jakie projekty robić? Od czego zacząć? W tym wpisie znajdziesz odpowiedź na powyższe pytania.

Pytania o wymagania na pozycję junior developera są bardzo popularne. Dotyczą one zwykle frontendu, Javy, czy C# i w internecie można znaleźć na ten temat już całkiem sporo, o embedded natomiast takich informacji brakuje. Są osoby, które traktują systemy embedded jako hobby – lubią sobie dłubać przy Arduino, czy Raspberry Pi, ale pracy szukają w prawdziwym programowaniu. Jednak jeżeli sprawia Ci to przyjemność, dlaczego nie zamienić hobby w stałą pracę? W tym wpisie przedstawie jakie musisz spełnić wymagania, żeby zdobyć pierwszą pracę w systemach embedded.

Wzorce projektowe są bardzo popularnym tematem wśród programistów. Zwykle rozmawia się o nich w kontekście języków obiektowych i dużych systemów. Jednak podobnie jak z innymi zagadnieniami dotyczącymi architektury – część wzorców da się z powodzeniem przenieść na grunt systemów embedded. W dzisiejszym wpisie opowiem o trzech wzorcach z najpopularniejszego katalogu wzorców – książki „Gang of four” – które mogą zrobić najwięcej dobrego w architekturze systemów embedded.

Dobra architektura nie powstaje od razu. Jest ona raczej wypracowana na bazie różnych doświadczeń. Jednak w większości systemów jest ona określana na sztywno na samym początku, kiedy jeszcze nie mamy wystarczającej wiedzy, aby zrobić ją dobrze. Jest to źródłem wielu problemów z utrzymaniem. Zamiast tego powinniśmy pogodzić się z faktem, że dobre rozwiązania wymagają czasu i umożliwić architekturze ewolucję.

Z czego składa się architektura? Z modułów i warstw. To jest intuicyjny podział wynikający z potrzeby dzielenia złożonych problemów na mniejsze i grupowania podobnych zadań. Jednak o ile co do samego istnienia warstw i modułów nikt nie ma zastrzeżeń, to strategie ich wydzielania zależą często tylko od naszej fantazji. Dzisiaj zdefiniujemy sobie czym są owe moduły i warstwy oraz w jaki sposób powinny być wydzielane. Od razu uprzedzam, że będę tutaj mówił o architekturze dużego systemu realizującego wiele zadań jednocześnie. Duża część projektów embedded jest na tyle prostych, że tak skomplikowana architektura byłaby w nich jedynie obciążeniem.

W systemach embedded zwykle skupiamy się na niskopoziomowych interakcjach ze sprzętem. Poznajemy nowe interfejsy, wykorzystujemy kolejne zewnętrzne układy i wykorzystujemy nowe rodziny procesorów. Jednak to z czym sobie naprawdę nie radzimy to poskromienie rosnącej złożoności tworzonych przez nas systemów. W większości systemów prawdziwym problemem jest architektura, czyli systematyczne podejście do radzenia sobie z tą złożonością. Jako branża embedded nie potrafiliśmy do tej pory stworzyć jasnych zasad tworzenia architektury i utrzymywania jej w projekcie. Zwykle dominują dwa podejścia – albo architektury nie ma wcale, albo tworzona jest na początku przed rozpoczęciem kodowania i okazuje się niepraktyczna. W tym wpisie dzielę się swoimi spostrzeżeniami na temat problemów z architekturą w embedded.