W dzisiejszych czasach trudno wyobrazić sobie zespołową pracę nad złożonymi projektami bez wykorzystania systemu kontroli wersji. Hegemonem na tej płaszczyźnie jest system Git, który od dawna swoją popularnością i powszechnością miażdży konkurencyjne narzędzia [1]. Z tego względu umiejętność korzystania z Gita wydaje się być aktualnie kluczową dla efektywnego programowania.

Projektując aplikację samochodową, trzeba uwzględnić wiele wymagań, wśród których bezpieczna jazda jest tym najważniejszym. Aplikacja nie może rozpraszać osoby kierującej w trakcie jazdy, która powinna mieć ręce na kierownicy i skupiać się na drodze. Interakcje kierowcy z ekranem centralnym samochodu muszą być jak najprostsze, nierozpraszające i intuicyjne. Użytkownik nie może na długo odwracać wzroku od drogi – wystarczy, by jedynie rzucił okiem i już rozumiał treści na ekranie. A już na pewno aplikacja nie może zmuszać użytkownika do zdjęcia obu rąk z kierownicy (np. użycie gestu pinch). Ogólnie rzecz biorąc, preferowane jest nieużywanie rąk w ogóle, a w zamian komunikacja głosowa.

Nie podlega raczej dyskusji stwierdzenie, że pojawienie się świata aplikacji mobilnych otworzyło przed programistami zupełnie nowe perspektywy. Oto napisane przez nich aplikacje można teraz było mieć cały czas przy sobie i zabierać ze sobą w trasę lub w teren. Ale żeby tego było mało, z uwagi na fakt obecności w nowoczesnych telefonach komórkowych mnogości czujników takich jak GPS, akcelerometr, magnetometr i tak dalej – aplikacje te mogły teraz realizować zupełnie nowe zadania.

W artykule tym przejdziemy szybkim krokiem przez historię API graficznych takich jak DirectX, OpenGL, Vulkan oraz towarzyszącego im na przestrzeni lat rozwoju kart graficznych z jednej strony, a z drugiej – gier video. Nie będziemy się uczyli programowania w żadnym z tych API. Artykuł ten powinien być zrozumiały i zaciekawić może każdego, kto interesuje się grami czy grafiką albo przynajmniej w dzieciństwie grał w gry.

Masz fantastyczny pomysł na nowy projekt. Innowacyjny. Atrakcyjny. Porywający. Siadasz i zaczynasz pisać kod. Idzie świetnie. Aplikacja budzi zainteresowanie. Rozrasta się. Pojawiają się nowe funkcjonalności. Aż nagle przychodzi ten irytujący moment: pierwszy błąd regresji. A potem drugi. I trzeci. Coś, co do tej pory działało, nagle przestaje. I choć wszystko w tobie wzbrania się przed przyznaniem tego, musisz stawić czoła faktom: trzeba wreszcie napisać do twojego projektu automatyczne testy. Zróbmy to więc – i zróbmy to dobrze. No… przynajmniej w miarę dobrze.

W numerze 4/2024 „Programisty” ukazał się artykuł „Zbuduj własnego Linuxa z Buildrootem i Raspberry Pi”. Dzisiaj zajmiemy się głównym konkurentem Buildroota – Yocto Project. Omówimy krótko jego historię i wynikającą z niej architekturę systemu, przyjrzymy się jego elementom składowym i sposobowi działania. Na końcu użyjemy Yocto, by zbudować od zera w pełni funkcjonalny własny obraz Linuxa na popularną platformę Raspberry Pi 4.

Wytyczanie nowych szlaków zawsze wiąże się z pewnym ryzykiem, czasem jest to spowodowane koniecznością, czasem brawurą, a czasem kombinacją obu tych okoliczności. Historia powstania komputera K-202 w czasach przynależności państwa polskiego do bloku krajów Rady Wzajemnej Pomocy Gospodarczej (RWPG) jest przykładem tego, jak w trudnych warunkach PRL-u lat siedemdziesiątych można było stworzyć oryginalny projekt, mogący bez problemu konkurować, a nawet przewyższać konstrukcje zachodnie, bazując całkowicie na rodzimej myśli technicznej i błyskotliwości polskich projektantów i konstruktorów.