Kiedy myślimy o tworzeniu aplikacji mobilnej na iOS, kluczowym wyborem jest decyzja pomiędzy natywnym a hybrydowym podejściem do developmentu. Oba rozwiązania mają swoje zalety i wady, a właściwy wybór wymaga przeprowadzenia badań i skonfrontowania ich z własnymi celami. Jeśli chodzi o hybrydowy development, najczęściej wybieranym narzędziem jest React Native od Facebooka, natomiast w przypadku natywnego rozwoju najprawdopodobniej sięgniemy po dedykowany język Apple, czyli Swift. Oczywiście to tylko podstawy — wybór nie jest wcale tak prosty.

## Sukcesor Swifta

Swift został stworzony jako następca języka Objective-C, którego Apple używało przez dziesięciolecia. Objective-C stał się już nieco przestarzały, by nie powiedzieć delikatnie — brakowało mu nowoczesnych funkcji, co wynikało z faktu, że powstał w latach 80. Swift został zaprezentowany podczas Worldwide Developers Conference w 2014 roku jako dedykowany język do budowy aplikacji iOS i od tej pory otrzymał wiele znaczących aktualizacji. Wiele bardzo popularnych aplikacji jak Twitter, SlideShare czy Airbnb powstało właśnie w Swift i z dużym prawdopodobieństwem można stwierdzić, że do tej listy już wkrótce dołączą kolejne.

## Hybrydowy development aplikacji = React Native

React Native to framework JavaScriptowy stworzony przez Facebooka, służący do tworzenia aplikacji wieloplatformowych. Był wykorzystywany również przy tworzeniu wielu znanych aplikacji, takich jak SoundCloud, Instagram oraz oczywiście oficjalnej aplikacji Facebooka. Główną ideą było umożliwienie programistom pisania kodu i budowania aplikacji jednocześnie na iOS i Androida, przy czym elementy interfejsu są renderowane natywnie dla każdej z platform. To sprawia, że proces developmentu jest zauważalnie szybszy niż tworzenie oddzielnych zespołów programistycznych pod każdą platformę, zachowując przy tym wrażenia użytkownika charakterystyczne dla danej platformy.

## Swift vs React Native dla iOS

Oczywistą przewagą hybrydowego podejścia jest możliwość korzystania z jednej bazy kodu do tworzenia aplikacji na obie platformy. Android posiada dużą część rynku, więc nawet jeśli początkowo skupiasz się tylko na iOS, dobrze jest zostawić sobie otwartą furtkę na przyszłość. Mimo to, React Native posiada kilka kluczowych zalet nawet przy samym rozwoju aplikacji iOS. Ostatecznie wybór powinien opierać się na celach konkretnego projektu i na tym, co w nim priorytetowe. W rzeczywistości dobór technologii jest znacznie bardziej złożony niż tylko kwestia przyspieszenia developmentu, dlatego warto głębiej przyjrzeć się kluczowym różnicom:

* **UI**: Programiści Swifta mogą wykorzystać SwiftUI i od podstaw tworzyć interfejsy ściśle dopasowane do iOS. Z kolei React Native korzysta z bibliotek JavaScriptowych do budowania interfejsów użytkownika. To daje sporo korzyści — dostęp do przydatnych narzędzi firm trzecich, bibliotek i wielu wielokrotnie używanych komponentów, co znacząco upraszcza tworzenie natywnego UI zarówno na iOS, jak i Androida.
* **Szybkość kodowania**: Chociaż Swift zdecydowanie usprawnił pracę w stosunku do Objective-C i pozwala szybciej budować aplikacje iOS, React Native ma pod tym względem przewagę. JavaScript jest od dłuższego czasu najpopularniejszym językiem programowania i nie bez powodu. Społeczność, liczba narzędzi i rozwiązań są ogromne i znacznie ułatwiają pracę nawet mniej doświadczonym programistom.
* **Nauka**: Apple zadbał o bardzo dobrą dokumentację i udostępnił środowiska testowe, jednak trudno konkurować tutaj z JavaScriptem — praktycznie każda informacja jest na wyciągnięcie ręki po szybkim wyszukaniu w Google. Ta różnica może z czasem się zmniejszać, lecz obecnie, z racji liczby dostępnych narzędzi, poradników i deweloperów, przewaga JavaScript w tej kwestii jest ogromna.
* **Wydajność**: Wydajność aplikacji zależy od wielu czynników — od konfiguracji po rozmiar i złożoność projektu. Mimo to React Native wykorzystuje natywne optymalizacje i narzędzia, które istotnie wpływają na wydajność, niezależnie od innych czynników.
* **Stabilność**: Tutaj Swift wyraźnie góruje nad React Native. To język zaprojektowany pod konkretną platformę, korzysta z type safety, dzięki czemu łatwiej wychwycić błędy, a wydajność i stabilność są zoptymalizowane pod kątem iOS. Hybrydowe podejście i nacisk na szybszy development mają w tym aspekcie pewne minusy w porównaniu do języka tworzonego z myślą o jednej platformie. Oczywiście mowa tu o standardowym przypadku, bo różne biblioteki i narzędzia platformowo-specyficzne mogą znacząco wspomagać React Native w tej dziedzinie.

## A może oba?

Społeczność JavaScript jest znacznie starsza i większa, co samo w sobie jest ogromnym atutem. Bez względu na projekt, możesz być raczej pewien, że JavaScript przewyższy Swifta pod kątem dostępności programistów, kosztów, czasu realizacji, wsparcia społeczności i ilości dostępnych bibliotek third-party. Mimo to środowisko Swifta prężnie się rozwija i jeśli masz zamiar stworzyć aplikację iOS maksymalnie dostosowaną do platformy i korzystającą bez problemów ze wszystkich jej funkcjonalności, to Swift może lepiej sprawdzić się niż React Native. W typowych przypadkach, gdzie największą rolę grają czas i koszty, React Native pozostaje najczęściej najlepszym wyborem. Na koniec warto dodać, że jeśli dopiero zaczynasz swoją przygodę z programowaniem, dobrze opanować oba rozwiązania – krzywa uczenia nie jest stroma dla żadnego z nich, a możliwość pracy z oboma technologiami znacznie zwiększy Twoje szanse na rynku i będzie dużym atutem na przyszłość.

Krótki przegląd zalet Swift i React Native — które rozwiązanie lepiej sprawdzi się w Twoim projekcie.

Swift czy React Native – co lepsze do tworzenia aplikacji iOS?

Gdy już poznamy psychologiczne aspekty podejścia do estymacji i mamy odpowiednie zaplecze techniczne, możemy przejść do jednego z kluczowych pojęć w estymacji projektów IT - **skali trudności.** Dzięki niej programiści, managerowie oraz klienci mogą w prosty sposób zobaczyć zaawansowanie danego zadania oraz jego orientacyjny czas realizacji. Na podstawie skali trudności możemy również analizować velocity zespołu, co pozwala na jeszcze dokładniejsze estymacje. W praktyce stosuje się wiele różnych abstrakcyjnych jednostek służących do pomiaru skali trudności.

*Dlaczego więc używamy jednostek abstrakcyjnych, a nie godzin?*

Otóż estymacje w godzinach tworzą wrażenie, że dokładnie wiemy, ile czasu zajmie dane zadanie. To pozorna precyzja, która nie uwzględnia kontekstu, nieoczekiwanych problemów czy różnic między platformowych. Do tego dochodzi indywidualna moc przerobowa dewelopera - jedno zadanie może zająć jednej osobie 2 godziny, a innej dokładnie to samo zadanie 6 godzin. Co najgorsze, godzinowe estymaty łatwo stają się obietnicą wobec biznesu. Jeśli powiemy, że coś zajmie od 3 do 5 godzin, klient może spodziewać się efektów już po 2,5 godziny. W efekcie psuje to relacje i zaufanie między deweloperami a biznesem, bo takie estymaty często są nietrafione. Z punktu widzenia Project Managera, godzinowe wyceny utrudniają również planowanie sprintów i tworzenie roadmapy, ponieważ nie oddają relatywnej trudności zadań.

*Na swojej drodze możesz spotkać się jeszcze z terminami względnej bądź absolutnej złożoności zadań.*
*Absolutna złożoność zadań to nic innego jak konkretna informacja godzinowa - “To zajmie 2h”. Względna złożoność zadań wykorzystuje abstrakcyjne jednostki (np. Story Points) co pozwala powiedzieć - “To zadanie jest mniej więcej dwa razy trudniejsze niż tamto”. Badania pokazują, że zespoły dochodzą do konsensusu szybciej porównując relatywnie („czy to bardziej jak login, czy bardziej jak wdrożenie płatności?”), dzięki czemu estymata jest stabilniejsza i odporniejsza na indywidualne różnice.*

Mając już to wyjaśnione, przejdźmy do najczęściej stosowanej skali oceny trudności.

## 1. Story Points

**Story Pointy** to jeden z kluczowych elementów metodologii SCRUM. Są to jednostki miary (abstrakcyjne), które służą do estymacji pracy, biorąc pod uwagę zarówno złożoność, jak i wysiłek potrzebny do ukończenia user story. Dzięki Story Pointom:

* możemy porównywać **relatywną trudność zadań** - np. zadanie o wartości 2 SP jest mniej więcej dwa razy trudniejsze niż zadanie o wartości 1 SP,
* unikamy estymacji w godzinach, co pozwala skupić się na **względnym porównywaniu zadań między sobą**,
* estymacja obejmuje nie tylko czas, ale także **złożoność techniczną, ryzyko i niepewności**.

Dodatkowym dużym atutem stosowania Story Pointów jest możliwość pomiaru **velocity zespołu**, co ułatwia planowanie sprintów i prognozowanie dostarczanej wartości.

Najczęściej do określania Story Pointów używa się liczb z ciągu Fibonacciego (1, 2, 3, 5, 8, 13…). Wynika to z faktu, że zespołowi łatwiej jest zdecydować, czy dane zadanie zasługuje na 8 SP, czy wystarczy 5 SP, niż precyzyjnie porównywać np. 6 SP do 5 SP - **zasada ograniczenia iluzji precyzji**. Rosnące wartości w ciągu Fibonacciego odzwierciedlają również fakt, że im większe zadanie, tym więcej niepewności i trudniej ocenić jego dokładną złożoność. W kilkuosobowych zespołach stosowanie takiego podejścia generuje też pożyteczne pytania w dyskusji: np. „Dlaczego przypisałeś temu zadaniu 8 SP? Ja uważam, że wystarczą maksymalnie 3 SP.”

*Jak Story Pointy odzwierciedlają niepewność?*

Małe zadania, zwykle o wartości 1-3 SP, są stosunkowo pewne, a ryzyko ich realizacji niewielkie. Średnie zadania, przyjmujące wartości 5-8 SP, zawierają już pewne niewiadome - mogą wiązać się z integracjami, różnicami między platformowymi lub wymagać dodatkowej analizy. Duże zadania, o wartości 13 SP i wyżej, są obarczone wysoką niepewnością; wymagają pogłębionej analizy i dyskusji, a niekiedy konieczna jest ich dekompozycja na mniejsze części, aby móc je wiarygodnie oszacować.

## 2. Alternatywne metody oceniania skali trudności

### 2.1 Skala liniowa 1-6

Na początku zespoły często wybierają **skalę liniową**, aby łatwiej wystartować, a dopiero później przechodzą na Story Pointy i ciąg Fibonacciego. W tej metodzie zespół stosuje proste wartości: 1, 2, 3, 4, 5, 6, gdzie:

* 1 to bardzo małe i proste zadanie,
* 6 to bardzo duże, trudne i obarczone ryzykiem zadanie.

Zaletą skali liniowej jest niewątpliwie niski próg wejścia dla nowych osób - jest po prostu łatwa do zrozumienia. Wytłumaczenie jej klientowi również nie stanowi problemu: „6 to zadanie najtrudniejsze, 1 to najprostsze”. Dodatkowo, dla nas - Polaków - jest naturalna, ponieważ przypomina szkolną skalę ocen.

Niestety skala liniowa jest obarczona dużą **iluzją dokładności** i słabiej podkreśla niepewność przy większych zadaniach. Dla porównania, w ciągu Fibonacciego widzimy wyraźny przeskok między zadaniem 3 SP a 13 SP, co naturalnie skłania do rozbijania większych tasków na mniejsze części. Skala liniowa często prowadzi też do nadmiernej „matematyzacji” estymacji i sporów o detale - deweloperom łatwiej jest dyskutować, czy zadanie powinno mieć 5 SP czy 8 SP, niż czy powinno mieć 3 czy 4 SP.

### 2.2 T-shirt sizes

Jest to kolejna łatwa do wyobrażenia skala - **t-shirt sizes**: XS, S, M, L, XL (czasem XXL). Każdy z rozmiarów odpowiada relatywnej złożoności i wysiłkowi, przy czym pomijamy używanie liczb.

Skala jest bardzo intuicyjna, ponieważ wszyscy na co dzień rozumiemy różnicę między S a XL, co ułatwia jej wprowadzenie zarówno do nowego, jak i doświadczonego zespołu. Unika iluzji precyzji, bo nie opiera się na liczbach - jest to jednak jednocześnie jej największa wada. Brak liczb utrudnia mierzenie **velocity zespołu**, a same rozmiary są mniej dokładne przy planowaniu sprintu. Doskonale nadaje się do **porównywania i priorytetyzowania zadań**, ale trudniej budować na niej konkretny plan realizacji sprintu.

## 3. Story points dla React Native - przykłady

### 1-2 SP: Proste zmiany

* zmiana tekstu,
* zmiana koloru tekstu,
* drobna poprawka w stylach (np. zwiększenie `paddingHorizontal` dla danego ekranu),
* dodanie/podmiana ikony w istniejącym przycisku,
* podmiana endpointu w istniejącym API callu.

### 3-5 SP: Standardowe funkcjonalności

* nowy ekran z podstawowym formularzem i walidacją (np. dane Twojego zwierzaka),
* ekran z listą dostępnych gości pobraną z API z podstawowym loading/error state,
* dodanie lokalnego storage (async-storage, MMKV) dla podstawowych danych,
* integracja z bibliotekami UI,
* stworzenie prostej nawigacji,
* dodanie splash screena.

### 8-13 SP: Złożone funkcjonalności

* wieloetapowy bądź złożony w inny sposób formularz z walidacją i obsługą błędów,
* synchronizacja danych offline-online za pomocą Tanstack Query + persystencja MMKV,
* integracja z Google Maps/Stripe,Firebase, Push Notifications (rejestracja urządzenia, obsługa tokenów, reakcje na kliknięcia),
* zaawansowana nawigacja,
* obsługa deeplinków,
* złożone animacje wymagające React Native Reanimated / React Native Gesture Handler.

### 21+ SP: Ogromne zadania przeznaczone do dekompozycji

* system zamówień z koszykiem, checkout, płatnościami,
* migracja na nową dużą bibliotekę (upgrade Apollo / React Navigation etc.),
* pełna obsługa offline-first z kolejką mutacji oraz retry logic,
* zaawansowany system skanowania QR/Barcode’ów wraz z integracją z API,
* integracja z wieloma usługami naraz (np. logowanie Google/Apple/Facebook + backend).

## 4. Skala 1-6 dla React Native - przykłady

### 1: Proste zmiany UI/tekstu

* zmiana koloru przycisku,
* zmiana koloru tekstu,
* podmiana ikony,
* poprawa literówki,
* dodanie marginesu w stylach.

### 2: Podstawowe formularze, proste komponenty

* dodanie prostego formularza logowania z `TextInput` + `Button`,
* walidacja formularza logowania,
* stworzenie komponentu `UserAvatar` z obrazkiem i username,
* stworzenie prostej listy elementów statycznych za pomocą `FlatList`.

### 3: Integracja API, nawigacja

* pobranie danych z API używając Axios/Fetch,
* wyświetlanie listy produktow z backendu używając `FlatList` i obsługą paginacji,
* konfiguracja react navigation i dodanie szczegółów produktu z parametrami w `navigation.navigate()` aby otworzyć ekran ze szczegółami produktu.

### 4: Złożona logika, state managment

* użycie TanStack Query/Apollo do cachowania i synchronizacji danych,
* obsługa trybu offline-first używając MMKV i NetInfo,
* implementacja optymistycznych updateów,
* zagnieżdżone formularze z walidacją warunkową,
* integracja z Redux/Zustand do globalnego stanu,
* własne hooki zarządzające logiką biznesową.

### 5: Integracja z Native modules, rozwiązywania problemów międzyplatformowych

* podłączenie SDK do płatności np. Stripe, Adyen, które wymagają natywnej konfiguracji w plikach natywnych,
* własny native module,
* integracja push notyfikacji wykorzystując Firebase Cloud Messaging i APNs,
* debugging różnic pomiędzy iOS i Android,
* debugging problemów tylko na jednym systemie.

### 6: Zmiany architekturalne, poprawa performance aplikacji

* migracja do React Native New Architecture (Fabric + TurboModules),
* refaktoryzacja całego state managmentu,
* wprowadzenie modułowej architektury,
* optymalizacja list,
* code splitting,
* profilowanie i usuwanie memory leaków,
* wdrożenie CI/CD wykorzystując Bitrise/EAS.

## 5. Czynniki zwiększające złożoność

Oprócz samych skal zadań (1-6, Story Points) istnieją czynniki, które znacząco zwiększają złożoność implementacji. Można je traktować jak **multiplikatory trudności**. Część z nich można zauważyć już w przytoczonych wcześniej przykładach dla poszczególnych skal.

Jednym z największych czynników zwiększających złożoność w tworzeniu aplikacji mobilnych za pomocą React Native (choć podobne zjawisko można zauważyć także we Flutterze) są **różnice między iOS a Androidem**. Oba systemy mają własny sposób przyznawania uprawnień, znaczące różnice w wyglądzie i zachowaniu oraz często całkowicie inne API. Co działa „out of the box” na Androidzie, może wymagać dodatkowej konfiguracji na iOS lub, co gorsza, w ogóle nie być możliwe do wykonania.

Kolejnym istotnym czynnikiem zwiększającym złożoność jest **integracja z zewnętrznymi systemami**. Niejednemu deweloperowi sen z powiek spędziła np. integracja z SDK do płatności czy logowanie przez OAuth/SSO. Do tej samej kategorii można zaliczyć również integracje z hardware’em lub backendami, które nie posiadają stabilnego i dobrze udokumentowanego API.

Tworząc aplikację mobilną, musimy mieć na uwadze **skalowalność projektu**. Z tego powodu dużą uwagę należy poświęcić szeroko pojętemu **performance aplikacji**, który można traktować jako kolejny czynnik zwiększający złożoność. Dlaczego? Ponieważ nie istnieje jedna uniwersalna metoda optymalizacji. Co dla użytkownika może być płynnym działaniem aplikacji, dla nas oznacza m.in.: optymalizację list, animacji w 60 FPS, zarządzanie pamięcią (np. cache obrazków, unikanie memory leaks), obsługę offline-first z optymistycznymi update’ami i synchronizacją danych, a także lazy loading i code splitting przy ciężkich ekranach.

Ale to nie wszystko. Żyjemy w 2026 roku, w dobie AI, gdzie wycieki danych i oszustwa zdarzają się coraz częściej. Dlatego kolejnym czynnikiem zwiększającym złożoność jest **bezpieczeństwo danych**. Wymaga ono szczególnej uwagi przy przechowywaniu tokenów, szyfrowaniu danych, ochronie komunikacji, obsłudze informacji wrażliwych oraz bezpiecznym przechowywaniu tokenów w plikach `.env`.

To wszystko sprawia, że zadanie, które na pierwszy rzut oka mogłoby być ocenione na 3 SP, może w rzeczywistości wymagać nawet 21 SP. Przykładem może być logowanie, które angażuje co najmniej trzy z wcześniej wymienionych czynników zwiększających złożoność.

## 6. Jak dekompozycja wpływa na ocenę? To samo zadanie w różnych skalach

Aby pokazać Ci jak podział wpływa na skalę i story pointy, przedstawię jeden przykład - “Lista zamówień” w dwóch podejściach.

### Wersja 1 (bez dekompozycji)

**Opis: Stwórz ekran listy zamówień z integracją z API, obsłuż paginację, możliwość zmiany statusu zamówienia, trybem offline-first i push notyfikacjami.**

Biorąc pod uwagę przykłady wymienione wcześniej w tym artukule możemy oszacować czas tego zadania:
**- Skala: 5-6** (mamy integrację API, logikę offline, natywne moduły)
**- Story Points: 13+** (duże ryzyko, dużo zależności, jeden wielki moduł do dowiezenia)

**Jakie są problemy z tym zadaniem?**
Trudno je oszacować. Zakres jest bardzo szeroki i zakrawa o trudne i wymagające czasu zagadnienia. Dodatkowo, istnieje duże ryzyko poślizgu spowodowane np. blokadą na API lub problemami z Firebase.

### Wersja 2 (po dekompozycji)

Przeprowadźmy podstawową dekompozycję zadania na mniejsze taski.

#### Task 1 - Wyświetlanie listy zamówień

***Skala: 2
SP: 2***

**Efekt:** można klikać w UI, widać postęp

#### Task 2 - Integracja z API + paginacja

***Skala: 3
SP: 5***

**Efekt:** dostęp do realnych danych i działającej listy

#### Task 3 - Zmiana statusu zamówienia (optimistic updates)

***Skala: 4
SP: 5-8***

**Efekt:** interaktywność, zarządzanie zamówieniami, wstęp do offline-first

#### Task 4 - Offline first mode (persist + sync)

***Skala: 5
SP: 8***

**Efekt:** Lista zamówień działa bez internetu, pamięta co użytkownik miał w liście.

#### Task 5 - Push notifications

***Skala: 5
SP: 8***

**Efekt:** użytkownik dostaje informacje o zmianach w zamówieniach

Na tym przykładzie widać, że dekompozycja **obniża ocenę poszczególnych elementów** – zamiast jednego dużego zadania o wysokiej ocenie i dużym ryzyku, mamy kilka mniejszych zadań z mniejszym ryzykiem. Dzięki temu łatwiej planować sprinty, developer szybciej może pokazać efekty swojej pracy (np. wyświetlenie listy pobranej z API), a ryzyko blokad spada, ponieważ reszta zadań może być realizowana równolegle, np. oczekując na gotowość backendu.

## 7. Podsumowanie

Ten artykuł miał na celu pokazanie, czym są skale trudności i jak ich używać, korzystając z realnych przykładów. Przedstawione skale 1-6, Story Points oraz dekompozycja dużego zadania służą przede wszystkim technicznej ocenie zadań i planowaniu pracy zespołu. W komunikacji z biznesem lub osobami nietechnicznymi nie zawsze chodzi o wchodzenie w szczegóły implementacyjne. Ważne jest, aby podkreślić, że skala używana do estymaty **nie przekłada się na godziny** - wyceny czasowe to osobna kwestia. Z perspektywy developera nie ma sensu również tłumaczyć np.: „To zadanie ma 8 SP, bo musimy użyć TanStack Query, zrobić offline-first, persist, sync i optimistic updates.” Lepiej powiedzieć: „To zadanie jest duże, ponieważ wymaga integracji z kilkoma systemami i musi działać płynnie również bez internetu, dlatego traktujemy je jako większe zadanie, które zajmie więcej niż jeden sprint.” Dekompozycja zadań dodatkowo poprawia komunikację - zamiast jednego dużego „będzie za dwa miesiące”, możemy pokazywać kolejne kamienie milowe. Wszystko po to, aby w prosty sposób powiedzieć biznesowi, **co dostanie, kiedy i z jakim ryzykiem**.

Przewodnik szacowania trudności w React Native przy użyciu punktów story points, skali 1–6 i innych metod w celu lepszego planowania i zarządzania ryzykiem.

Skale trudności - Story Points, skala 1-6 i inne metody w oparciu o React Native

Podstawą rozwoju cywilizacji człowieka rozumnego są pomyłki - to na ich podstawie wyciągnął odpowiednie wnioski i dzięki temu jesteśmy w miejscu, w jakim jesteśmy.

![Kanban planning](https://aexol-cms.fra1.cdn.digitaloceanspaces.com/aexolcom/media/planning-board-in-office-2025-03-10-05-20-45-utc-1753860929432.webp)

Ale czy zastanawiałeś się kiedyś, dlaczego operujemy szacunkami? Co za tym stoi i jak zagadnienia psychologiczne wpływają na nasze podejście do estymacji?

Fakt, że człowiek woli szacować niż podawać konkretne liczby, znany jest od długiego czasu, szczególnie w psychologii. Ludzki mózg przetwarza ogromne ilości danych w tym samym momencie [1], więc segreguje informacje oraz optymalizuje proces ich przetwarzania. Szacowanie to dla mózgu sposób na uproszczenie zadania - mózg nie musi przeliczać ani dokładnie pamiętać danych liczbowych. Dzięki tej optymalizacji nie musi pracować na wysokich obrotach w codziennym życiu, ponieważ nasza percepcja czasu, odległości czy ilości działa głównie w sposób przybliżony, np. dużo, daleko, mniej więcej pół godziny.

W świetny sposób można to sprawdzić, prosząc dziecko o podanie rozmiaru kilku piłek. Dziecko będzie miało problem, żeby to określić i prawdopodobnie ucieknie się do mówienia o różnicach w ich rozmiarze. Natomiast gdy poprosisz dziecko, by ułożyło piłki od najmniejszej do największej - nie powinno mieć z tym żadnego problemu [2].

W branży IT tendencja do szacowania jest szczególnie wyraźna, a developerzy zazwyczaj omijają estymacje w godzinach, ponieważ:

 -   wiąże się to z ryzykiem pomyłki (a człowiek szacuje również z powodu uniknięcia stresu decyzyjnego [3]),

 -   środowisko nieustannie się zmienia,

 -   ułatwia zarządzanie ryzykiem interpersonalnym na linii zespół-klient,

 -   developerzy, podświadomie stosując fizjologię ANS (Approximate Number System), są w stanie na oko ocenić złożoność/rozmiar, np. w story pointach [4].

Wydawać by się mogło, że trzeba z tym walczyć. Otóż nic bardziej mylnego - okazuje się, że lepiej jest wykorzystać fizjologię niż z nią walczyć. Choć Agile (w tym SCRUM) nie został bezpośrednio oparty na psychologii poznawczej, w praktyce odpowiada na zjawiska opisane przez Janisa i Manna, takie jak unikanie stresu decyzyjnego czy wykorzystanie ANS [3]. Ramy Agile redukują presję na precyzję, promując przybliżenia i adaptacyjne podejście.

## Wpływ autorytetu na szacowanie w zespole

Jednym z najczęstszych problemów w szacowaniu w grupie (podstawa SCRUM) jest niepodważalna decyzja osoby, która jest autorytetem/przywódcą grupy [2]. Może to być zarówno najlepszy programista, osoba z najdłuższym stażem, jak i osoba, która przejawia interpersonalne predyspozycje przywódcze czy autorytarne. Jeśli według tej osoby dane zadanie zajmie godzinę, mimo że każdy z pozostałych członków zespołu spędziłby nad nim dwa dni, to nikt nie sprzeciwi się na forum grupy, ponieważ reszta członków tłumi własne wątpliwości w celu konformizmu (groupthinking). Rezultatem tego będzie, zapisanie "godziny" przez SCRUM Mastera, co może być ewidentnym błędem estymacji już na samym jej początku. Jest to kolejne ciekawe zagadnienie psychologiczne, u którego podstaw leży słynny już eksperyment Milgrama [5].

Szczególnie jest to zauważalne, gdy w spotkaniach bierze udział przełożony, kierownik działu bądź szef. Członkowie grupy automatycznie dostosowują swoje odpowiedzi do jego opinii - nawet gdy jest ona błędna. Efektem zjawiska "Authority bias" jest brak szczerej dyskusji i presja zgodności z oczekiwaniami przełożonego [6]. Dodatkowo członkowie zespołu mogą mieć problemy z przeciwstawieniem się bądź powiedzeniem: "to będzie trudne" z powodu lęku zarówno przed negatywną oceną, jak i przed podważeniem kompetencji [7] [8].

Obecność przełożonego zwiększa również stres poznawczy, co pogarsza jakość osądów i decyzji oraz ogranicza working memory (wtedy zamiast rzetelnej analizy pojawia się reakcja: "co mam powiedzieć, żeby było dobrze?"). To z kolei skutkuje brakiem bezpieczeństwa w wyrażaniu niepewności, utratą przestrzeni do zadawania pytań i ujawniania wątpliwości [9] oraz - co najważniejsze - **zaniżaniem estymat w obawie przed wyjściem na wolnego czy niekompetentnego.**

To właśnie z tych powodów Agile/SCRUM jest jednym z najpopularniejszych modeli prowadzenia zespołów, ponieważ bazuje na psychologicznych aspektach. W SCRUMie promowane są estymacje prowadzone przez zespół developerski bez udziału osób decyzyjnych. PM może jedynie przedstawić kontekst, ale nie powinien sugerować konkretnych liczb.

## Czym jest złudzenie planowania (planning fallacy)?

Planning fallacy to systematyczna tendencja ludzi do zaniżania czasu, kosztu i zasobów potrzebnych do wykonania zadania, nawet jeśli mają wcześniejsze doświadczenia, które przeczą tym optymistycznym szacunkom. Jest szczególnie zauważalna w mobile developmencie z powodu dynamicznie zmieniających się środowisk, trudnych do przewidzenia zależności (unknown unknowns) czy też presji szybkiego dostarczenia ficzerów/aplikacji.

Kilka przykładów:
-   "Działa u mnie, więc pewnie działa wszędzie" - a potem zderzenie z różnymi wersjami Android/iOS, urządzeniami i edge case'ami na realnych urządzeniach.
-   "Biblioteka to załatwi" - a potem niekompatybilność wersji, błędy runtime.
-   "Wystarczy to zmienić tylko na backendzie" - a potem rozsypane hooki, przebudowa cachingu i ogólne problemy z offline mode.
-   "Robiliśmy już coś takiego ostatnim razem, to teraz pójdzie szybciej" - ignorowanie historycznych danych; mimo napotkanych opóźnień zespół wierzy, że tym razem się uda.

## Skoro wiemy o tym zjawisku, dlaczego nadaj ono występuje w IT?

Z perspektywy developera widzę kilka powodów, dla których w IT nadal występuje planning fallacy. Jednym z głównych jest nadmierna wiara w to, że wszystko pójdzie idealnie, co prowadzi do ignorowania niejawnych zależności oraz historycznych danych, tworzy iluzję optymizmu i nie uwzględnia buforów bezpieczeństwa pozwalających na reakcję. Stworzyłem od zera już kilka komercyjnych projektów, w kilku innych byłem developerem odpowiedzialnym za utrzymanie i rozwój. Uwierzcie mi - nigdy nic nie jest idealnie, co nie znaczy, że nie staramy się, żeby tak było.

Kolejnym powodem, który dość często zauważam, jest złudna motywacyjna mgła, która dopada często młodych developerów, ale nie tylko. Wychodzimy z założenia, że powiedzenie, że to jest proste i zajmie mniej czasu, pokaże, że jesteśmy dobrymi developerami, a nas zmotywuje do produktywniejszej pracy (bo trzeba to zrobić w tym czasie). W efekcie, podczas gdy estymata się nie spełnia, spadają morale, narasta stres, developer przechodzi w tryb intuicyjny i robi "na szybko", aby tylko skończyć jak najszybciej. To skutkuje często nieprzetestowanym rozwiązaniem, które prędzej czy później i tak trzeba będzie naprawić i jeśli już stawia developera w jakimś świetle - to raczej negatywnym.

Bardzo duży wpływ na planning fallacy, w mojej ocenie, ma również wpływ efektu Dunninga-Krugera.

> *Efekt Dunninga-Krugera – błąd poznawczy  polegający na tym, że osoby niewykwalifikowane w jakiejś dziedzinie życia mają tendencję do przeceniania swoich umiejętności w tej dziedzinie, podczas gdy osoby wysoko wykwalifikowane mają tendencję do zaniżania oceny swoich umiejętności [10].*

W naszym developerskim świecie oznacza to ni mniej, ni więcej, że juniorzy uważają, że potrafią bardzo dużo, a seniorzy wiedzą, ile nie wiedzą - przez co ci pierwsi zaniżają estymaty, a ci drudzy je wydłużają. Działa to z powodu dwóch kluczowych elementów: brak umiejętności skutkuje brakiem zdolności do rzetelnej samooceny, a rosnąca kompetencja skutkuje większą świadomością i krytycyzmem wobec siebie.

## Jak deadline wpływa na jakość estymacji

Choć psychologicznie i procesowo jest to absurdalne, możesz spotkać się z deadlinem na estymację. Z definicji estymacja ma być oszacowaniem niepewności oraz czymś, co wymaga refleksji, analizy i rozmowy zespołu. Wprowadzanie ograniczeń czasowych wprowadza presję, która znacząco pogarsza jakość estymacji, sprzyja efektom wymienionym w poprzednich punktach (planning fallacy, groupthinking, efekt autorytetu, strach przed oceną) oraz zaburza samo założenie Agile.

Z perspektywy developera bądź zespołu postawionego przed takim oczekiwaniem to nic innego jak zgadywanie tego, co chce usłyszeć biznes - w znakomitej większości przypadków ma to potwierdzić własne założenia. W efekcie doprowadzamy do sytuacji: "daj mi liczbę, która zmieści się w narracji", a nie "daj mi realistyczne ryzyko projektu". Na koniec zawsze każdy na tym traci. Developerzy pod presją czasową przełączają się w tryb "szybko i na skróty", a nie "dokładnie i dobrze" [11]. Zwiększa się poziom stresu, co z kolei skutkuje zawężonym polem uwagi, obniżką zdolności do rozpoznania ryzyk i zależności oraz pojawieniem się efektu uproszczeń [12]. Zespół boi się przesadzić z dużą estymacją, tak by nie wyjść na wolnych i niewydajnych, o czym pisałem wyżej. W efekcie powstaje estymacja z zaniżonym kosztem czasu i zasobów, z niewykrytymi ukrytymi zależnościami i edge case'ami, która ma rażący wpływ na samego klienta i projekt.

**Zamiast tego warto zacząć od ustalenia tego, jak estymujemy (bez udawania, że szybkie jest precyzyjne), robić eksploracje oraz operować na zakresach, a nie konkretnych datach i godzinach.**

## Podsumowanie

Szacowanie w IT to nie tylko planowanie, ale przede wszystkim psychologia. Nasze mózgi działają na przybliżeniach, a nie precyzyjnych wartościach - i to jest jak najbardziej normalne. Problemem jest nacisk na dokładność zespołu w niepewnym środowisku, pod presją czasu i autorytetów. Dobre estymowanie nie polega na podaniu konkretnej liczby - zakres lepiej uwzględnia zmienność, ryzyko i nieprzewidywalność. Nie można traktować tego jako słabość, tylko jako realizm.

Naukowo udowodniono, że wpływ osób decyzyjnych może nieświadomie zaniżać estymaty przez efekty autorytetu, groupthink czy strach przed oceną kompetencji.

Stworzenie warunków do eksploracji i szczerej rozmowy to najlepsze, co możemy zrobić. Estymaty powinny wynikać z refleksji i doświadczenia, a nie oczekiwań. Tylko wtedy mają realną wartość i mogą służyć zarówno zespołowi, jak i projektowi.

**Literatura:**

* Miller, G. A. (1956). The magical number seven, plus or minus two: Some limits on our capacity for processing information. Psychological Review.
* Kaczor, Ł. (2020). Scrum i nie tylko. Teoria i praktyka w metodach Agile. Warszawa: PWN.
* Janis, I. L., & Mann, L. (1977). Decision Making: A Psychological Analysis of Conflict, Choice, and Commitment.
* Dehaene, S. (2011). The Number Sense: How the Mind Creates Mathematics (Rev. and Expanded ed.). Oxford University Press.
* Wikipedia. (2024, June 26). Milgram experiment. [https://en.wikipedia.org/wiki/Milgram\_experiment.](https://en.wikipedia.org/wiki/Milgram_experiment.) Accessed: July 28, 2026.
* Janis, I. L. (1972). Groupthink. Houghton Mifflin.
* Milgram, S. (1974). Obedience to Authority: An Experimental View. Harper & Row.
* Rosenberg, M. J. (1965). Cognitive structure and attitudinal affect.
* Edmondson, A. (1999). Psychological safety and learning behavior in work teams. Administrative Science Quarterly.
* Wikipedia. (2024, July 17). Dunning-Kruger effect.  [https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger\_effect.](https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect.) Accessed: July 28, 2026.
* Kahneman, D. (2011). Thinking, Fast and Slow. New York: Farrar, Straus and Giroux.
* Hockey, A. (1993). Cognitive-energetical control under pressure. In A. Baddeley &
* L. Weiskrantz (Eds.), Attention: Selection, awareness, and control (pp. 328–345). Oxford: Clarendon Press.

 Psychologia estymacji - dlaczego się mylimy

Dokładne spojrzenie na wszystkie aspekty dostępności aplikacji internetowych - standardy, wytyczne i ich wdrażanie.

Kompleksowy przewodnik po dostępności aplikacji internetowych

Wyobraź sobie programowanie bez stresu związanego ze składnią czy powtarzalnym kodem. Po prostu opisujesz, co chcesz osiągnąć – i *bum* – kod pisze się sam. Brzmi jak magia? Witaj w świecie **vibe codingu.**

W ostatnich miesiącach deweloperzy na Twitterze i LinkedInie nie przestają mówić o tym nowym sposobie budowania oprogramowania – gdzie **bardziej czujesz** niż ręcznie piszesz, a AI ogarnia większość szczegółów.

W tym wpisie wyjaśnię, czym tak naprawdę jest vibe coding, skąd się wziął, jak narzędzia takie jak ChatGPT i GitHub Copilot to umożliwiają – i dlaczego programiści są tym podekscytowani (i trochę przerażeni). Spodziewaj się memów, historii z życia i luźnego stylu – więc chwyć coś do picia i wchodzimy w vibesy.

## **1. Czym właściwie *jest* Vibe Coding?**

W skrócie, **vibe coding to oddanie AI żmudnej roboty**, żebyś mógł skupić się na tym, co faktycznie chcesz zbudować.

Zamiast pisać wszystko od zera, opisujesz swój cel – po prostu, po angielsku – a resztę kodu uzupełnia AI. Wyobraź to sobie tak:

*„Chcę formularz z trzema polami i przyciskiem submit. I niech to wygląda schludnie.”*

...i kod po prostu się pojawia.

Jedna z definicji mówi tak:

*„Nowe podejście do tworzenia oprogramowania, w którym wykorzystuje się narzędzia AI do pomagania ludziom w budowie aplikacji bez głębokiej wiedzy programistycznej.”*

Innymi słowy: **ty określasz wizję, AI pisze kod**.

Twoja rola zmienia się – zamiast stukać każdą linijkę, prowadzisz, wybierasz i dopieszczasz to, co zaproponuje AI. Mniej walki ze składnią, więcej reżyserowania całego procesu.

## **2. Skąd się wzięły „vibesy”?**

Zapłon? Tweet badacza AI **Andreja Karpathy’ego** z początku 2026 roku.

Opisał styl programowania, w którym po prostu *„widzi rzeczy, mówi rzeczy, uruchamia rzeczy, kopiuje-wkleja rzeczy”* – a AI robi całą robotę. Używał Cursor Composer, programował nawet głosem. Zero walenia klawiaturą. Zero przeglądania diffów.

*„Wchodzę w vibesy i zapominam, że kod w ogóle istnieje.”*

Ten tweet wystrzelił. Pojawiły się memy. Programiści zaczęli nazywać to vibe codingiem.

Ludzie żartowali nawet, że legendarny producent muzyczny **Rick Rubin** to patron vibe codingu – koleś znany z tego, że nie ma technicznych skillsów, ale ma genialny gust.

Nagle wszyscy zaczęli dzielić się swoimi zasadami vibe codingu. Na przykład:

*„Vibe coding jest łatwy. Vibe debugging jest trudny.”*

No… coś w tym jest.

## **3. AI jako Twój Kodujący Sidekick**

Dlaczego to wszystko w ogóle stało się możliwe? Proste: **narzędzia AI do kodowania zrobiły się absurdalnie dobre**.

Przez ostatnie lata GitHub Copilot, ChatGPT, Replit Ghostwriter, Cursor i inne – wyewoluowały od podpowiadających autouzupełniaczy do pełnoprawnych współprogramistów.

Te narzędzia potrafią dziś:

* Przekształcać zwykły angielski w działające funkcje
* Generować całe komponenty, strony, czy API
* Debugować błędy
* Pisać testy
* A nawet uruchamiać czy lintować Twój kod

Możesz dosłownie powiedzieć:

*„Dodaj obsługę błędów i zamień to na endpoint REST.”*

I oglądać, jak dzieje się to na Twoich oczach.

Niektóre narzędzia obsługują nawet **komendy głosowe**. Karpathy użył voice-to-code z SuperWhisper i Cursor. Klawiatury niemal nie dotykał – a mimo to zbudował pełną aplikację.

## **4. Dlaczego To *Czuje* Się Inaczej**

Oto, dlaczego „vibe coding” stało się popularne – tu nie chodzi tylko o używanie AI.

Tu chodzi o to, jak **płynny** jest cały proces. Jak jazz. Jak granie na żywo z zespołem.

Zamiast planować każdy szczegół, po prostu:

* Próbujesz czegoś
* Patrzysz na efekt
* Modyfikujesz
* Powtarzasz

Dostajesz natychmiastową informację zwrotną. Flow jest szybki i kreatywny. Nie stresujesz się składnią – po prostu łapiesz klimat, iterujesz i wprowadzasz poprawki intuicyjnie.

Ten styl „kodu na wyczucie” daje moc. Jeden z founderów bez technicznego zaplecza zbudował betę swojej aplikacji w jeden weekend przy pomocy ChatGPT. Nawet nie wiedział, na jakim stosie pracował – AI wyjaśniło to dopiero później.

Tu chodzi o **szybkość, kreatywność i rozpęd** – nawet jeśli nie rozumiesz w 100% tego, co dzieje się „pod maską”.

## **5. Dlaczego Devsi To Kochają**

Zobaczmy, co sprawiło, że to podejście się przyjęło:

* **🚀 Dzika Szybkość**
  Budowanie MVP kiedyś zajmowało tygodnie. Teraz – weekend, a nawet jeden dzień.


* **🎨 Kreatywny Flow**
  Koniec z zacięciem się na składni. Skupiasz się na pomysłach i designie.


* **🤝 Większa Dostępność**
  Nawet osoby spoza IT mogą stworzyć coś funkcjonalnego. AI zasypuje przepaść.


* **😎 To Po Prostu Fajne**
  Jest coś frajerskiego w powiedzeniu „Zbudowałem to, bo współgrałem z ChatGPT”.

Jest tu trochę chaosu, trochę magii, i ludzie są zachwyceni tą jazdą.

## **6. Ale Uwaga – Jest Haczyk**

Oczywiście, **są też minusy**. Nie zawsze jest klimat.

Co może pójść nie tak:

* **🐞 Debugowanie Na Vibe To Mordęga**
  Gdy coś się sypie (a się sypie), dojście *dlaczego* jest trudne. Nie pisałeś tego kodu, siedzisz i próbujesz rozgryźć, co miało na myśli AI.


* **🧠 Utrata Umiejętności**
  Za bardzo polegając na AI, rozleniwiasz mięśnie programistyczne. Przestajesz myśleć „jak to działa”.


* **⚠️ Ryzykowne Na Produkcji**
  AI nie zawsze trzyma się dobrych praktyk. Wkradają się kiepskie wzorce, brakuje testów, a czasami nawet pojawia się niebezpieczny kod.


* **📦 Chaotyczny Kod**
  Jeśli projekt rośnie, pliki generowane przez AI szybko robią się bałaganiarskie. Jedna zmiana potrafi namieszać w dziesięciu innych miejscach.



Konkluzja? Vibe coding jest świetny do szybkich prototypów, ale jeszcze (jeszcze!) nie zastąpi solidnego inżynieringu.

## **8. Podsumowanie**

**Vibe coding to fakt, i zostaje z nami.**

Sprawia, że programowanie jest szybsze, bardziej kreatywne i bardziej dostępne niż kiedykolwiek. Nie musisz znać się na wszystkim – wystarczy, że wiesz, co chcesz stworzyć.

Ale to nie magia. Nie zastępuje dobrego rzemiosła. Przy poważnych projektach musisz dalej testować, refaktorować i rozumieć, co się dzieje.

Podsumowując:
**Vibe coding służy do odkrywania, prototypowania i jamowania – ale nie zapominaj, jak faktycznie grać na swoim instrumencie.**

Jeśli połączysz klimat z umiejętnością, nie tylko stworzysz coś fajnego szybciej – ale będziesz mieć przy tym dużo więcej frajdy.

Do dzieła. Oglądaj. Mów. Odpalaj. Niech vibe będzie z Tobą.

Wyobraź sobie programowanie bez stresu związanego ze składnią czy powtarzalnym kodem. Po prostu opisujesz, czego potrzebujesz, a kod tworzy się sam – brzmi jak magia? Witaj w świecie vibe coding!

Witamy w erze „vibe coding”

Aplikacje mobilne stały się nieodłącznym elementem codziennego życia Polaków. W 2026 roku aż 82,86% internautów korzystało z aplikacji Google, a takie platformy jak Facebook, Messenger, YouTube, Instagram czy TikTok regularnie przyciągają miliony użytkowników miesięcznie. Coraz większą popularnością cieszą się także aplikacje zakupowe (Allegro, OLX, Temu) oraz lojalnościowe (Żappka, Lidl Plus, Biedronka), co pokazuje, jak bardzo zmieniają się potrzeby konsumentów i jak istotne jest posiadanie własnej aplikacji mobilnej w strategii rozwoju firmy.

## Dlaczego warto zainwestować w aplikację mobilną?

* **Zwiększenie zasięgu i lojalności klientów** – aplikacje mobilne pozwalają na stały kontakt z użytkownikiem, wysyłanie powiadomień push, personalizację oferty i budowanie trwałych relacji.
* **Nowoczesny kanał sprzedaży** – aplikacje e-commerce umożliwiają szybkie zakupy online, dostęp do promocji i programów lojalnościowych, co przekłada się na wzrost sprzedaży.
* **Budowanie wizerunku innowacyjnej marki** – własna aplikacja mobilna to sygnał, że firma jest nowoczesna i dba o wygodę swoich klientów.

## Jak powstaje skuteczna aplikacja mobilna? – Rozbudowany proces krok po kroku

**1. Analiza potrzeb biznesowych i użytkowników**

Proces tworzenia aplikacji mobilnej rozpoczyna się od dogłębnej analizy biznesowej oraz zrozumienia, kim są docelowi użytkownicy i jakie mają potrzeby. Kluczowe jest, aby już na tym etapie precyzyjnie określić cele biznesowe aplikacji, zidentyfikować wyzwania, które ma rozwiązać, oraz ustalić, jak wpisuje się ona w strategię rozwoju firmy. W praktyce oznacza to:

* Prowadzenie warsztatów z klientem, podczas których omawiane są założenia projektu i oczekiwania wobec aplikacji
* Badania rynku oraz analiza konkurencji, by lepiej zrozumieć trendy i preferencje użytkowników
* Tworzenie person użytkowników – wyobrażonych profili reprezentujących różne grupy odbiorców aplikacji
* Wykorzystywanie wywiadów, ankiet i testów prototypów, by zebrać bezpośrednie opinie potencjalnych użytkowników i zidentyfikować ich rzeczywiste potrzeby

Na tej podstawie powstają mapy procesów oraz diagramy przepływu informacji, które pomagają określić kluczowe funkcjonalności aplikacji i jej rolę w realizacji celów biznesowych

**2. Projektowanie UX/UI – intuicyjna nawigacja, estetyczny wygląd, responsywność**

Projektowanie aplikacji mobilnej to nie tylko tworzenie ładnego interfejsu, ale przede wszystkim zadbanie o pozytywne doświadczenia użytkownika (UX) oraz atrakcyjny i spójny wygląd (UI). Kluczowe elementy tego etapu to:

* Tworzenie makiet (wireframes) i prototypów, które pozwalają przetestować różne koncepcje funkcjonalne i układy ekranów
* Projektowanie intuicyjnej nawigacji – użytkownik powinien łatwo odnaleźć się w aplikacji, a wszystkie funkcje muszą być dostępne w logiczny sposób
* Dbałość o przejrzystość, spójność wizualną oraz odpowiednie dopasowanie do wytycznych platform iOS i Android
* Uwzględnienie responsywności – aplikacja powinna działać płynnie i wyglądać dobrze na różnych urządzeniach i rozdzielczościach ekranów
* Testowanie prototypów na użytkownikach, by szybko wykryć i wyeliminować potencjalne problemy z użytecznością

Warto pamiętać, że zarówno funkcjonalność, jak i estetyka są kluczowe dla przyciągnięcia i utrzymania użytkowników.

**3. Wybór technologii – natywne, multiplatformowe, no-code/low-code**

Dobór odpowiedniej technologii ma ogromny wpływ na wydajność, możliwości rozwoju oraz koszty utrzymania aplikacji. Najczęściej stosowane rozwiązania to:

* **Aplikacje natywne** – tworzone osobno dla systemów iOS (Swift) i Android (Kotlin, Java). Zapewniają najwyższą wydajność, dostęp do wszystkich funkcji urządzenia i najlepsze dopasowanie do wytycznych platform
* **Aplikacje multiplatformowe (cross-platform)** – budowane przy użyciu frameworków takich jak Flutter czy React Native, pozwalają na jednoczesne tworzenie wersji na Android i iOS, co skraca czas i obniża koszty wdrożenia
* **No-code/low-code** – narzędzia takie jak Adalo czy Bubble umożliwiają szybkie prototypowanie i wdrażanie prostych aplikacji bez konieczności zaawansowanego programowania, co jest idealne dla MVP lub mniej złożonych projektów

Wybór technologii powinien być zawsze dostosowany do specyfiki projektu, oczekiwań klienta oraz planów rozwoju aplikacji.

**4. Testowanie i optymalizacja – gwarancja jakości i satysfakcji użytkowników**

Ostatni, ale nie mniej ważny etap to wieloetapowe testowanie i optymalizacja aplikacji. Obejmuje on:

* Testy funkcjonalne – sprawdzanie, czy wszystkie funkcje działają zgodnie z założeniami.
* Testy użyteczności – weryfikacja, czy aplikacja jest intuicyjna i wygodna w obsłudze dla użytkowników docelowych
* Testy wydajnościowe i bezpieczeństwa – ocena szybkości działania oraz odporności na potencjalne zagrożenia.
* Testy na różnych urządzeniach i systemach operacyjnych – zapewnienie pełnej responsywności i kompatybilności
* Iteracyjne poprawki na podstawie zebranych danych i opinii użytkowników – proces optymalizacji nie kończy się po wdrożeniu, aplikacja powinna być stale rozwijana i dostosowywana do zmieniających się potrzeb rynku

Dzięki takiemu podejściu powstaje aplikacja mobilna, która nie tylko realizuje cele biznesowe, ale przede wszystkim odpowiada na rzeczywiste potrzeby użytkowników i zapewnia im pozytywne doświadczenia na każdym etapie korzystania z produktu.

## Pozycjonowanie aplikacji mobilnych (ASO) – jak zdobyć więcej pobrań?

Aby Twoja aplikacja mobilna była widoczna w Google Play i App Store, niezbędna jest optymalizacja pod kątem słów kluczowych (ASO – App Store Optimization). Najważniejsze elementy skutecznego pozycjonowania aplikacji to:

* **Analiza słów kluczowych** – wybór fraz, które najczęściej wpisują użytkownicy (np. „aplikacja mobilna dla firm”, „aplikacja zakupowa”, „tworzenie aplikacji mobilnych”, „aplikacje na Android i iOS”).
* **Umieszczanie fraz w tytule i opisie aplikacji** – tytuł powinien zawierać najważniejsze słowa kluczowe, a opis szczegółowo przedstawiać funkcje i korzyści aplikacji.
* **Stosowanie fraz long tail** – mniej konkurencyjne, ale precyzyjne frazy zwiększają szansę na dotarcie do konkretnej grupy odbiorców.
* **Monitorowanie pozycji i analiza konkurencji** – regularne sprawdzanie skuteczności wybranych słów kluczowych i reagowanie na zmiany trendów.

## Najczęściej wyszukiwane frazy związane z aplikacjami mobilnymi

* aplikacje mobilne dla firm
* tworzenie aplikacji mobilnych
* aplikacje na Android i iOS
* aplikacje zakupowe
* aplikacje lojalnościowe
* projektowanie aplikacji mobilnych
* aplikacje webowe
* aplikacje e-commerce
* aplikacje dla sklepów internetowych
* aplikacje dla przedsiębiorstw

## Podsumowanie

Aplikacje mobilne to dziś nie tylko narzędzie komunikacji, ale także platforma sprzedażowa, rozrywkowa i organizacyjna. Ich rosnąca popularność wśród polskich użytkowników sprawia, że inwestycja w nowoczesną aplikację mobilną i webową to kluczowy krok w rozwoju każdej firmy. Jeśli chcesz dowiedzieć się, jak zaprojektować skuteczną aplikację mobilną dla swojego biznesu lub potrzebujesz wsparcia w zakresie pozycjonowania aplikacji, skontaktuj się z naszym zespołem – pomożemy Ci osiągnąć sukces w świecie mobilnych technologii.

Aplikacje mobilne – klucz do sukcesu Twojego biznesu online

Wczoraj (25 stycznia 2024) Apple ogłosił znaczące zmiany w iOS, Safari i modelu działania App Store, które wpłyną na aplikacje deweloperów w Unii Europejskiej. Motywacją do tych zmian jest dostosowanie się do Digital Markets Act (DMA), który wszedł w życie w listopadzie 2022. Przyjrzyjmy się najciekawszym nowościom albo, jeśli chcesz zobaczyć pełną listę zmian, przejdź do [oficjalnego ogłoszenia Apple](https://www.apple.com/newsroom/2024/01/apple-announces-changes-to-ios-safari-and-the-app-store-in-the-european-union/).

## Co nowego w iOS

Aby iOS, Safari oraz App Store stały się zgodne z DMA, Apple został zmuszony znacząco poluzować wiele dotychczasowych restrykcyjnych zasad działania, co przełoży się na:

* **Nowe frameworki i API dla silników przeglądarek** — umożliwią deweloperom używanie silników przeglądarek innych niż domyślny iOS WebKit w aplikacjach przeglądarkowych oraz aplikacjach z wbudowaną przeglądarką, co jest dużą zmianą dla deweloperów i powinno dać więcej możliwości przy korzystaniu z WebView.
* **Formularz żądania interoperacyjności** — dzięki któremu deweloperzy mogą ubiegać się o odblokowanie dodatkowych funkcjonalności sprzętowych i programowych iPhone i iOS, co może zaowocować powstaniem ciekawych, nowych produktów.

Wielu z was może powiedzieć:

> "Hej, a co z deregulacją alternatywnych marketplace’ów aplikacji?"

wygląda więc na to, że rzeczywiście dostaniemy nowe API i narzędzia do publikowania, pobierania, a nawet aktualizacji aplikacji z alternatywnych marketplace’ów, ale będzie się to wiązać z dodatkowymi zabezpieczeniami (regulacjami?) w postaci:

* Notaryzacji aplikacji iOS
* Arkuszy instalacji aplikacji
* Autoryzacji dla deweloperów marketplace’ów
* Dodatkowych zabezpieczeń antywirusowych

co raczej nie dziwi, ponieważ może stanowić ryzyko dla użytkowników końcowych iPhone. Szczerze wierzę, że i tak większość użytkowników i ruchu pobrań aplikacji pozostanie w App Store. To uporządkowane, znane i godne zaufania środowisko, więc nic się nie zmieni, dopóki nie pojawi się alternatywa o równie wysokim poziomie zaufania.

## Co nowego w App Store

Zmiany w warunkach korzystania z App Store budzą, delikatnie mówiąc, mieszane uczucia. Otrzymujemy narzędzie pozwalające szacować opłaty, lepiej rozumieć metryki powiązane z **nowymi warunkami biznesowymi Apple dla aplikacji w UE** (o których za chwilę) oraz kilka naprawdę fajnych deregulacji, takich jak możliwość:

* **korzystania z dostawców płatności zewnętrznych** — wreszcie otrzymujemy sposób na obsługę płatności za cyfrowe towary i usługi bezpośrednio z aplikacji iOS (bez dodatkowej opłaty na rzecz Apple),
* **przetwarzania płatności przez link-out** — użytkownicy mogą finalizować transakcje za cyfrowe towary i usługi na zewnętrznej stronie dewelopera (bez dodatkowej opłaty dla Apple),

ale jest jedno ale. To prowadzi nas do...

### Nowe warunki biznesowe dla aplikacji w UE

Zacznijmy od tego, że możemy wybrać, czy chcemy zaakceptować nowe warunki biznesowe, czy pozostać przy dotychczasowych warunkach Apple, jednak wcześniej wspomniane deregulacje są dostępne **tylko** w nowych warunkach.

Przyjrzyjmy się więc szczegółom. Zaczyna się to atrakcyjnie od dwóch mocnych punktów:

* **Obniżona prowizja** — aplikacje iOS w App Store będą płaciły obniżoną prowizję w wysokości 10 procent (dla zdecydowanej większości deweloperów oraz subskrypcji po pierwszym roku) lub 17 procent od transakcji za cyfrowe towary i usługi.
* **Opłata za przetwarzanie płatności** — aplikacje iOS w App Store mogą korzystać z obsługi płatności przez App Store za dodatkową opłatą 3 procent. Deweloperzy mogą także skorzystać z usług zewnętrznego operatora płatności w aplikacji lub przekierować użytkownika do swojej strony www, by zrealizować płatność **bez dodatkowej opłaty dla Apple**.

ale potem pojawia się:

* **Core Technology Fee** — aplikacje iOS dystrybuowane z App Store i/lub alternatywnego marketplace’u będą płaciły 0,50 € za każdą pierwszą roczną instalację powyżej progu 1 miliona,

ponieważ otrzymujemy supernarzędzie do „*szacowania opłat i lepszego zrozumienia metryk Apple*”, policzmy. Jak trafnie napisał Nikita Bier na swoim Twitterze [@nikitabier](https://twitter.com/nikitabier), aplikacja, która działa i sprzedaje cyfrowe dobra na nowych warunkach, generując 10 000 000 instalacji rocznie i mając prognozę 10 000 000 $ przychodów, musi się liczyć z opłatami rzędu 500 000 $ miesięcznie. OK, roczny APRU 1 $ jest nieco wyższy (czy może znacznie wyższy?) niż średnia rynkowa, ale jak widać w poniższej rozpisce, większość kosztu to tzw. „Technology Fee” powiązana z liczbą instalacji.

![new fee structure](https://aexol-cms.fra1.cdn.digitaloceanspaces.com/aexolcom/media/bier-1730907775025.webp)

## Podsumowanie

Biorąc wszystko powyższe pod uwagę – czy rzeczywiście otrzymujemy dawkę deregulacji, czy tylko zgodną z DMA iluzję alternatywnego rozwiązania, które przy zestawieniu z obecnym wypada tak słabo, że niewielu będzie z niego korzystać? Apple śmiało szacuje, że nowe warunki biznesowe zmniejszą lub utrzymają obecny poziom opłat pobieranych przez Apple dla 99% deweloperów, a mniej niż 1% będzie musiało zapłacić Core Technology Fee za swoje aplikacje w UE. Poczekajmy i zobaczmy.

Apple została zmuszona do dostosowania się do wymogów DMA w Unii Europejskiej, ale czy wprowadzane przez nich zmiany są korzystne czy niekorzystne dla twórców aplikacji?

Zmiany Apple DMA – na lepsze czy gorsze?

Gdy Tailwind CSS pojawił się na rynku, wprowadził podejście utility-first do stylowania, które diametralnie zmieniło sposób, w jaki deweloperzy budują aplikacje. Pozwalając na stosowanie styli bezpośrednio w znacznikach, obiecywał szybszy workflow i bardziej konsekwentny system projektowania. Jednocześnie wywołał jednak debatę. Krytycy twierdzą, że taka wygoda może mieć swoją cenę — zniechęcać deweloperów do nauki podstawowych zasad CSS. Czy więc Tailwind sprawia, że stajemy się leniwi, czy może umożliwia nam mądrzejszy rozwój? Przyjrzyjmy się temu pytaniu na podstawie rzeczywistych perspektyw i przykładów.

## **Postrzegany problem: Czy zapominamy o podstawach CSS?**

Dla niektórych Tailwind to skrót — sposób na pominięcie głębszych niuansów CSS. Wyobraźmy sobie junior developera, który nigdy nie miał do czynienia z kaskadą czy specyficznością, a mimo to potrafi zbudować w pełni responsywną, atrakcyjną wizualnie stronę z Tailwind. Czy to zwycięstwo produktywności, czy może strata dla wiedzy fundamentalnej?

Weźmy przykład zespołu, który buduje komponent z użyciem Tailwind:

```html
<div class="bg-gray-100 p-6 rounded-lg shadow-lg">
  <h1 class="text-2xl font-bold mb-4">Welcome</h1>
  <p class="text-gray-700">This is a simple card.</p>
</div>
```

To zwięzłe i czytelne — nie potrzeba osobnego pliku CSS. Ale czy takie podejście nie grozi zamianą CSS w czarną skrzynkę? Krytycy ostrzegają, że poleganie na klasach narzędziowych może doprowadzić do powstania pokolenia deweloperów, którzy nie wiedzą, jak działają ich narzędzia „pod maską”.

## **Kiedy Tailwind błyszczy: Najlepszy sposób na oszczędność czasu**

Pomimo krytyki, zwolennicy Tailwind wskazują na jego niezaprzeczalne zalety. Dla projektów, gdzie szybkość jest kluczowa, a reużywalność nie jest priorytetem, Tailwind sprawdza się jak żaden inny framework. Skupiając się na utility, eliminuje potrzebę rozbudowanych plików CSS pełnych jednorazowych reguł. Deweloperzy mogą szybko prototypować, dopracowywać wygląd bezpośrednio w znacznikach i narzucać spójny język wizualny w całej aplikacji.

Wyobraźmy sobie dynamiczny projekt freelancerski, gdzie klient potrzebuje w pełni funkcjonalnego MVP w kilka dni. Predefiniowane klasy narzędziowe Tailwind pozwalają wykonać to zadanie bez nadmiaru stylów lub oddzielnych plików CSS.

Na przykład:

```html
<div class="grid grid-cols-3 gap-6">
  <div class="bg-blue-500 p-4 text-white">Card 1</div>
  <div class="bg-blue-500 p-4 text-white">Card 2</div>
  <div class="bg-blue-500 p-4 text-white">Card 3</div>
</div>
```

Z Tailwind, spójność odstępów i stylowania osiąga się z łatwością dzięki klasom utility. Ta szybkość i prostota mogą całkowicie odmienić sytuacje, gdzie liczy się czas wprowadzenia produktu na rynek.

## **Wyzwania skalowania z Tailwind**

Jednak w większych projektach, gdzie kluczowa jest reużywalność i łatwość utrzymania, podejście Tailwind do styli inline może być wyzwaniem. Wraz ze wzrostem bazy kodu, HTML może być przeładowany nazwami klas, co utrudnia identyfikację i aktualizację wspólnych styli. Może to prowadzić do frustracji w aplikacjach na dużą skalę, gdzie najważniejsze są spójność projektu i czysta architektura.

Na przykład, gdy zespół pracuje nad design systemem używanym w wielu produktach, wyodrębnienie styli reużywalnych do komponentów lub plików CSS może być lepsze w dłuższej perspektywie. Pomocne mogą być narzędzia jak @apply:

```ts
.btn-primary {
  @apply bg-blue-500 text-white py-2 px-4 rounded hover:bg-blue-700;
}
```

Takie podejście łączy szybkość Tailwind z organizacją tradycyjnego CSS, dając zbalansowaną alternatywę.

## **Tailwind w praktyce: Znaj swoje zastosowanie**

Kluczem do efektywnego korzystania z Tailwind jest zrozumienie jego zalet i ograniczeń. Jeśli pracujesz nad projektem, w którym liczy się szybki rozwój i minimalna złożoność architektury, Tailwind może być najlepszym wyborem. To idealne rozwiązanie dla prototypów, małych aplikacji i sytuacji, gdy reużywalność nie ma kluczowego znaczenia.

Natomiast jeśli tworzysz dużą aplikację z naciskiem na skalowalność i łatwość utrzymania, być może będziesz musiał uzupełnić Tailwind innymi narzędziami lub technikami. Połączenie Tailwind z frameworkami komponentowymi jak React może złagodzić niektóre jego wady:

```ts
const Card = ({ children }) => (
  <div className="bg-blue-500 p-4 text-white rounded-md">
    {children}
  </div>
);
```

Enkapsulując style w reużywalnych komponentach, możesz utrzymać czysty i uporządkowany kod, jednocześnie korzystając z utility Tailwind do szybkiego stylowania.

## **Dlaczego warto korzystać z Tailwind CSS**

Tailwind CSS nie sprawia, że deweloperzy są leniwi; sprawia, że są efektywni. Poprzez zredukowanie tarcia między projektem a developmentem, umożliwia szybszą iterację i bardziej konsekwentne stylowanie. Jego paradygmat utility-first rzuca wyzwanie tradycyjnemu podejściu do CSS — i niekoniecznie jest to coś złego.

Dla deweloperów, którzy stawiają na szybkość i prostotę, Tailwind to oczywisty wybór. Pozwala skupić się na budowie funkcji i dostarczaniu wartości zamiast tonąć w szczegółach CSS. Choć może nie jest idealnym rozwiązaniem w każdym przypadku, zrozumienie kiedy i jak go używać pozwala uwolnić pełen potencjał tego narzędzia.

Czy więc Tailwind czyni nas leniwymi? W żadnym wypadku. Daje nam narzędzia do mądrzejszej pracy — a w dynamicznym świecie współczesnego web developmentu to kompromis, który zdecydowanie warto zaakceptować.

Czy Tailwind sprawia, że stajemy się leniwi, czy raczej pozwala nam rozwijać się mądrzej?

Czy Tailwind CSS rozleniwia programistów?

# Pełne bezpieczeństwo typów full-stack z Axolotl, Zeus i Vite

Od lat tworzę API GraphQL i największą bolączką zawsze było utrzymanie spójności typów. Piszesz swój schemat, ręcznie tworzysz typy TypeScript dla resolverów, generujesz typy klienta i masz nadzieję, że nic się nie rozjedzie. Jedna literówka w typie zwracanym przez resolver i debugujesz błędy czasu wykonania.

Ten przykład pokazuje inne podejście — prawdziwe, kompleksowe bezpieczeństwo typów od schematu aż po komponenty React, uruchomione na jednym serwerze.

## Konfiguracja

Przykład `yoga-federated` uruchamia wszystko na jednym porcie:

* **Backend**: Express + GraphQL Yoga z typami generowanymi przez Axolotl
* **Frontend**: React + Vite z klientem GraphQL generowanym przez Zeus
* **Oba**: Ten sam serwer, to samo origin

http://localhost:4002/         -> Frontend React (SSR)

http://localhost:4002/graphql  -> GraphQL Playground

W trybie deweloperskim Vite działa jako middleware Express dla HMR. W produkcji Express serwuje zbudowany frontend. Jedno wdrożenie, zero konfiguracji CORS.

## Dyrektywa @resolver

Oto schemat:

```gql
type Todo {
  _id: String!
  content: String!
  done: Boolean
}

type AuthorizedUserMutation {
  createTodo(content: String!, secret: Secret): String! @resolver
  todoOps(_id: String!): TodoOps! @resolver
}

type Query {
  user: AuthorizedUserQuery @resolver
}
```

Dyrektywa `@resolver` oznacza, które pola wymagają implementacji. Pola bez niej są rozwiązywane automatycznie na podstawie obiektu nadrzędnego.

To właśnie sprawia, że Axolotl świetnie współpracuje z asystentami AI. Gdy Copilot lub Cursor widzi schemat, dokładnie wie, które pola wymagają resolverów, a które nie. Zero zgadywania.

Podpowiedz AI: „Implement all @resolver fields” i otrzymasz poprawny kod, ponieważ schemat jasno określa, co trzeba zaimplementować.

Uruchom `axolotl build` i otrzymujesz typowane modele.

## Frontend z Zeus

Zeus generuje typowanego klienta GraphQL na podstawie schematu.

```ts
// frontend/src/api.ts
import { Chain } from '../../src/zeus/index';

export const createGqlClient = (token?: string) => {
  const headers: Record<string, string> = {
    'Content-Type': 'application/json',
  };
  if (token) {
    headers['token'] = token;
  }
  return Chain('/graphql', { headers });
};
```

Zapytania są type-safe:

```ts
// frontend/src/hooks/useTodos.ts
const fetchTodos = async () => {
  const data = await gql()('query')({
    user: {
      todos: { _id: true, content: true, done: true },
    },
  });

  // TypeScript wie, że data.user?.todos to Todo[]
  if (data.user?.todos) {
    setTodos(data.user.todos);
  }
};
```

Mutacje również:

```ts
const createTodo = async (content: string) => {
  await gql()('mutation')({
    user: {
      createTodo: [{ content }, true],
    },
  });
};
```

Składnia `[{ content }, true]` oznacza: przekaż te argumenty, zwróć to pole. TypeScript sprawdza, czy `content` zgadza się ze schematem.

## Express + Vite na jednym serwerze

Cały stack działa na jednym serwerze Express:

```ts
// src/index.ts
async function startServer() {
  const app = express();

  // Podłącz GraphQL
  const { yoga } = adapter({ resolvers, directives });
  app.use('/graphql', yoga);

  // Tryb deweloperski: Vite middleware dla HMR
  if (!isProduction) {
    const vite = await createViteServer({
      server: { middlewareMode: true },
      appType: 'custom',
    });
    app.use(vite.middlewares);
  } else {
    // Produkcja: serwuj zbudowane zasoby
    app.use(sirv(resolve(__dirname, '../dist/client')));
  }

  // SSR dla wszystkich innych tras
  app.use('*all', async (req, res) => {
    const { html } = await render(req.originalUrl);
    res.send(html);
  });
}
```

Masz:

* HMR w trybie deweloperskim
* SSR dla SEO
* Jeden artefakt wdrożeniowy
* Bez konfiguracji proxy

## Przepływ typów

Todo przechodzi przez system w następujący sposób:

1. **Schema** definiuje `createTodo(content: String!): String!`
2. **Axolotl** generuje `args: { content: string }` dla resolverów
3. **Resolver** używa `{ content }` z wsparciem TypeScript
4. **Zeus** generuje typy klienta na podstawie tego samego schematu
5. **React hook** wywołuje `createTodo: [{ content }, true]` z type checkingiem
6. **Response** wraca z odpowiednimi typami

Zmień schemat, uruchom `axolotl build`, a TypeScript pokaże, co się zepsuło.

## Wypróbuj

```ts
cd examples/yoga-federated
npm install
npm run dev
```

Otwórz http://localhost:4002:

![](https://aexol-cms.fra1.cdn.digitaloceanspaces.com/aexolcom/media/screenshot-login-1765204379116.png)

Zarejestruj się i jesteś w środku, możesz tworzyć todo

![](https://aexol-cms.fra1.cdn.digitaloceanspaces.com/aexolcom/media/screenshot-todo-created-1765204389217.png)

GraphQL Playground pod adresem http://localhost:4002/graphql:

![](https://aexol-cms.fra1.cdn.digitaloceanspaces.com/aexolcom/media/screenshot-playground-1765204385463.png)

## Co mi się w tym podoba

Po zastosowaniu tego wzorca parę rzeczy się wyróżnia:

1. **Zmiany w schemacie propagują się wszędzie** – zmodyfikuj pole, uruchom build, TypeScript powie Ci co nie działa po stronie backendu i frontendu
2. **AI assistant rzeczywiście pomaga** – dyrektywa `@resolver` pozwala Copilotowi zrozumieć, co zaimplementować, bez tłumaczenia architektury
3. **Jedno `npm run dev`** – nie trzeba osobnego terminala dla frontendu, nie ma potrzeby proxy, zero problemów z CORS
4. **SSR po prostu działa** – co przydaje się jeśli zależy Ci na SEO

Minusem jest sprzężenie – frontend i backend są wdrażane razem. Dla większości projektów to w porządku. Jeśli potrzebujesz niezależnego skalowania, wtedy rozdzielisz je później.

## Linki

* [Dokumentacja Axolotl](https://axolotl.aexol.com)
* [Dokumentacja GraphQL Zeus](https://zeus.aexol.com)
* [Przykładowy kod źródłowy](https://github.com/aexol-studio/axolotl/tree/main/examples/yoga-federated)

***


*Zbudowane z Axolotl + GraphQL Yoga + Zeus przez* [Aexol Studio](https://aexol.com)

Od lat tworzę API GraphQL i największą bolączką zawsze było utrzymanie spójności typów. Piszesz swój schemat, ręcznie tworzysz typy TypeScript dla resolverów, generujesz typy klienta i masz nadzieję, że nic się nie rozjedzie. Jedna literówka w typie zwracanym przez resolver i debugujesz błędy czasu wykonania.

Pełne bezpieczeństwo typów full-stack z Axolotl, Zeus i Vite

## 1. Wstęp

**“Ile to zajmie?” - to pytanie, które każdy developer bez względu na staż usłyszał setki razy. Za każdym razem, na usta ciśnie się to samo stwierdzenie - to zależy…**

Z wykształcenia, jestem inżynierem Mechatroniki na Wydziale Mechanicznym Politechniki Białostockiej. Niejednokrotnie, miałem okazję projektować bądź wytwarzać jakąś rzecz za pomocą obrabiarek, zarówno tych manualnych jak i tych sterowanych numerycznie. Celem zwizualizowania sobie procesu wytwarzania elementu w inżynierii mechanicznej, wyobraźmy sobie wytwarzanie Łącznika ciesielskiego płaskiego z 10 otworami.

Na początku konstruktor projektuje element. Dobiera rodzaj materiału, wymiary elementu, rozstaw i wielkość otworów. Następnie, operator obrabiarek sterowanych numerycznie (CNC) bądź operator klasycznej frezarki, w oparciu o dokumentację, dobiera odpowiednie narzędzia, posuwy i inne istotne w tym procesie elementy po to by mieć możliwość wytworzenia tego elementu. Obrabiarka wykrawa element z kawałka ustalonej blachy, wierci otwory oraz wykańcza krawędzie. Na koniec tego procesu, operator wyciąga gotowy przedmiot i zabiera się za wykonywanie drugiego. Dodatkowo, obrabiarki sterowane numerycznie, są w stanie wytwarzać kilka bądź kilkanaście takich elementów na raz a cały proces może być zautomatyzowany. W jednym i drugim przypadku zawsze możemy mieć pewność bądź przypuszczać z dużym prawdopodobieństwem, że proces ten zajmie (przy zastosowaniu tych samych warunków: materiał, ustawienia obrabiarki) tyle samo czasu. Dodatkowo, nowoczesne obrabiarki CNC pokazują, jak długo będą wytwarzać element, którego program właśnie został wybrany.

Właśnie dlatego, estymacja projektów IT to jedna z najtrudniejszych umiejętności w branży, ponieważ diametralnie różni się od wymienionego wyżej przykładu. Nie ma dwóch identycznych aplikacji. Każdy projekt jest unikalny, z indywidualnym designem, oparty na innych założeniach i celach biznesowych. Często nie ma gotowych szablonów a każda, nawet najprostsza funkcjonalność, może być ciężka do implementacji w danym środowisku.

Różnice między systemami Android i iOS często komplikują pracę deweloperów. Warto też pamiętać, że React Native umożliwia tworzenie nie tylko aplikacji mobilnych, ale również webowych, a także tych przeznaczonych na Apple Watch czy TV.

W takim razie, ktoś mógłby stwierdzić, że estymacje są bez sensu albo, że estymacja to loteria; ale nie jest to do końca prawda.

*Ten artykuł to pierwszy z serii, w której pokażę, jak ja – React Native Developer z kilkuletnim doświadczeniem – podchodzę do estymacji. Niezależnie od tego, czy jesteś deweloperem, który musi oszacować lub wycenić zadanie, czy CEO próbującym zrozumieć, dlaczego "prosty" projekt trwa trzy miesiące – mam nadzieję, że przedstawione tu informacje rzucą nowe światło na cały proces estymacji.*

*Zaczniemy od poznania podstawowych pojęć i podstaw estymacji. Dowiemy się, co w tym takiego trudnego oraz jak spróbować połączyć świat techniczny, ze światem biznesowym -  co moim zdaniem jest kluczowym aspektem każdego projektu w IT.*

## 2. Podstawowe definicje

*Tutaj będzie troszkę suchych regułek ale mam nadzieję, że w zrozumiałej formie* 🙂

### 2.1 Estymata

To proces szacowania czasu, wysiłku i zasobów potrzebnych do wykonania danego zadania lub projektu. Jest kluczowym elementem planowania i zarządzania projektem, pozwalającym na określenie realistycznych celów i efektywne alokowanie zasobów.

Zazwyczaj, estymata nie jest jednorazowym działaniem, a procesem, który ewoluuje w miarę postępu projektu. Dzięki niej możemy stworzyć realistyczne harmonogramy, stworzyć odpowiednie priorytety oraz monitorować postęp. Pomaga również w określaniu ryzyka i zarządzaniu oczekiwaniami.

Tworzona jest zazwyczaj przez developerów bądź zespół techniczny. Określana najczęściej w Story Pointach, rzadziej w godzinach.

***Czy wiesz, że?***

> Prawo Hofstadtera - Wykonanie zadania zawsze trwa dłużej, niż zakładasz, nawet jeśli
> weźmiesz pod uwagę prawo Hofstadtera.

### 2.2 Wycena

To przeliczenie estymat na konkretną kwotę pieniężną. Składa się na nią: estymata + stawka + marża + ryzyko i ma charakter zewnętrzny, kontraktowy. Jest przedstawiana klientowi oraz podlega negocjacjom. Jeśli estymacja została przeprowadzona w godzinach, przeliczenie jej na czas trwania projektu jest stosunkowo proste. W przypadku estymacji w Storypointach, konieczne jest jednak uwzględnienie velocity zespołu — czyli średniej liczby punktów realizowanej w jednym sprincie. Jeśli pracujesz nad nowym projektem lub z nowym zespołem i nie dysponujesz takimi danymi, musisz założyć przybliżone velocity na podstawie dostępnych informacji lub doświadczenia.

### 2.3 Task

To pojedyncza jednostka pracy, którą trzeba wykonać w ramach większego projektu. Jest konkretny i mierzalny, np. "Zrób białe tło na ekranie logowania" - jesteśmy w stanie wywnioskować o co w nim chodzi, oraz jesteśmy w stanie zweryfikować jego wykonanie.

Często wyposaża się go w dodatkowe informacje jak osobę odpowiedzialną za jego wykonanie, priorytet czy status. Wykorzystywany powszechnie w życiu codziennym (podział dużego zadania na mniejsze) oraz w narzędziach jak Jira, Asana, Trello czy Basecamp.

Jest podstawowym elementem w zarządzaniu pracą.

* **Epic:** Logowanie użytkownika
* **User Story:** “Jako użytkownik chce się zalogować, żeby mieć dostęp do mojego konta”
* **Tasks:**
* **1.** Stwórz formularz logowania (frontend)
* **2.** Obsłuż zapytanie (backend)
* **3.** Dodaj walidację
* **4.** Stwórz testy jednostkowe
* **5.** Sprawdź poprawność UX

### 2.4 Epic

To duży, wysokopoziomowy element pracy, ciężki do realizacji w ramach jednego sprintu (ale nie niemożliwy). Reprezentuje cel biznesowy, np. logowanie użytkownika do aplikacji. Dzieli się na mniejsze taski i user stories.

### 2.5 Project

To ogólne przedsięwzięcie mające na celu stworzenie konkretnego rozwiązania, np. aplikacji mobilnej. Charakteryzuje się tym, że ma swój początek i koniec, realizuje konkretny cel biznesowy, wymaga współpracy różnych ról, składa się z wielu epików.

Może trwać tygodnie, miesiąca a nawet lata. W nowoczesnych zespołach, często zarządzany metodą jedną z metod Agile (Scrum lub Kanban).

### 2.6 Złożoność

To stopień trudności technicznej związany z wykonaniem zadania, funkcji bądź projektu. Nie oznacza czasu, ale wpływa na ryzyko, podnosi koszt oraz zwiększa prawdopodobieństwo błędów lub zmian.

Częstymi przykładami czynników wpływających na złożoność są: nietypowa architektura, skomplikowane designy, edge-casey, brak jasnych wymagań biznesowych lub technologicznych, nowe technologie, czy też skala.

**Czy złożoność wpływa na pracę?**
*Zdecydowanie tak. Taski tej samej długości czasowej mogą mieć różną złożoność. Zbyt dużo złożonych tasków w jednym sprincie znacząco wpływa na ryzyko opóźnień a co za tym idzie, zwiększa stawki i bufory bezpieczeństwa.
Ocena złożoności danego zadania odbywa się najczęściej za pomocą story points bądź innych metod punktowych (t-shirt sizing, fibonacci).
Dopiero po określeniu złożoności zadania, możemy przewidywać, ile czasu zajmie to zadanie konkretnej osobie. Na czas wpływają umiejętności developera oraz znajomość projektu czy technologii. Na przykład ten sam task junior zrobi w 5 dni a senior w 2 dni. Na tej podstawie, licząc koszt czyli czas \* stawka + bufor + marża możemy określić swoje oczekiwania, i oddelegować jego wykonanie odpowiedniej osobie.*

* **Task:** "Dodaj logowanie przez Google"
* **Złożoność:** 5/6 (wymaga OAuth, obsługi tokenów, integracji)
* **Czas:** 3 dni dla senior developera, 6 dni dla junior developera
* **Koszt:** 2400€ (senior) vs. 1800€ (junior) - ale senior wykona go 2x szybciej

## 2.7 Storypoint

Do oszacowania złożoności, wysiłku i niepewności zadań lub user stories służą storypointy. **NIE SĄ** to godziny, dni ani żadna inna jednostka czasu.

Do ich określenia, najczęściej używa się ciągu Fibonacciego: 0.5, 1, 2, 3, 5, 8, 13, 20, ... , ponieważ w większości przypadków, różnice są trudne do oceny a zespołowi prościej jest ocenić zadanie w skali 5 czy aż 8, niż 5 czy 6.

W uproszczeniu, zadanie wycenione na 5 Storypointów (SP) jest około dwa razy bardziej złożone niż takie, które ma 2SP. Po pewnym czasie stosowania tej metody można zacząć mierzyć velocity zespołu, czyli liczbę Storypointów realizowanych w trakcie jednego sprintu — na przykład 30SP na sprint.

**Storypoint to narzędzie do planowania, a nie mikro zarządzania!**

Poniżej znajdziesz podstawowe różnice pomiędzy storypointami a godzinami.

|                   | Storypoint                                                                                                     | Godzina                                                                                      |
| ----------------- | :------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------- |
| **Czym jest?**    | Jednostka względna złożoności                                                                                  | Jednostka czasu                                                                              |
| **Kto estymuje?** | Zespół deweloperski, developer (np. na planningu)                                                              | Zespół developerski bądź developer we współpracy z managerem                                 |
| **Do czego?**     | Planowanie sprintów, mierzenie velocity                                                                        | Wycena, planowanie kalendarza, roadmapy.                                                     |
| **Po co?**        | Porównanie zadań, przewidywanie wydajności, określenie trudności zadań a następnie ich prawidłowe zaplanowanie | Wycena kosztu wykonania taska, projektu, funkcjonalności. Rozdysponowanie czasu developerów. |
| **Dokładność**    | Przybliżona, odporna na różnice umiejętności pomiędzy developerami                                             | Pozornie dokładna – ale może być myląca bez danych                                           |
| **Kiedy NIE?**    | Nie używane do wyceny lub umów (np. fixed-price), bo SP ≠ godziny                                              | Nie wyceniaj samodzielnie bez udziału osób technicznych                                      |

## 3. Dlaczego IT tak bardzo różni się od produkcji?

Podstawową różnicą pomiędzy IT a tradycyjną produkcją jest unikalność każdego projektu. W produkcji seryjnej, jesteśmy przyzwyczajeni do powtarzalnego procesu wytwarzania serii produktów, a sam ten proces jest ściśle ustandaryzowany.

W procesie wytwarzania aplikacji IT, są znaczące różnice klientów, ich oczekiwań oraz specyficzne wymagania danych technologii, przez co możemy cały proces jedynie ustandaryzować, natomiast nigdy to nie będzie powtarzalny proces wytwarzania serii aplikacji ponieważ każda z nich jest inna.

Nie bez przyczyny wspominam o istocie klienta, ponieważ to klient, odgrywa jedną z kluczowych ról w branży IT. Jest on nie tylko odbiorcą końcowym ale i aktywnym uczestnikiem procesu tworzenia. To jego potrzeby definiują kształt aplikacji, a jego decyzje (często w trakcie procesu developmentu) wpływają na przebieg prac. Programista musi być gotowy na dostosowanie się do wymagań klienta, które mogą zmieniać się w trakcie całego procesu.

Kolejnym istotnym czynnikiem jest dynamika technologii. W IT, a szczególnie w branży aplikacji mobilnych - nowe narzędzia, biblioteki czy całe architektury pojawiają się z tygodnia na tydzień. Idealnym przykładem jest React Native - technologia, która w ostatnich latach nabrała niesamowitego wiatru w żagle i praktycznie każdy update, wprowadza coś innowacyjnego. Całkiem niedawno, mierzyłem się z updatem stacka w jednej z aplikacji nad którą pracuję. Okazało się, że w tym czasie, React Native przeszedł na nową architekturę ([https://reactnative.dev/architecture/landing-page](https://reactnative.dev/architecture/landing-page)). Update środowiska i przejście na nową architekturę spowodowało brak wstecznej kompatybilności z wieloma bibliotekami, które były użyte w projekcie, co zmusiło mnie do szukania nowych rozwiązań, szybkiego przyswajania wiedzy i implementacji tych rozwiązań w istniejące oraz rozwinięte środowisko. Coś co trwa zazwyczaj kilka godzin, trwało kilka dni 🙂

Tworzenie między platformowych aplikacji mobilnych ma jeszcze jedno istotne wyzwanie. Są to różnice pomiędzy platformami - iOS i Android rozwijają się niezależnie, mają odmienne wymagania, inne rozwiązania na te same kwestie oraz mogą powodować ciężkie do przewidzenia problemy. Z pozoru proste zadania, mogą ulec ogromnemu opóźnieniu przez specyfikę danej platformy, nieoczekiwane błędy lub konieczność znalezienia alternatywnych rozwiązań. Weźmy np. zablokowanie możliwości robienia screenshotów w aplikacji. Na Androidzie sprawa jest bardzo prosta - wystarczy dodać FLAG\_SECURE w MainActivity. iOS natywnie nie daje takiej możliwości, więc albo używamy jakiegoś rozwiązania z Githuba, albo musimy sami napisać metodę, która podczas życia aplikacji, podmieni zrobiony screenshot bądź nagranie na czarne tło. Brzmi prosto? A czy nadal brzmi tak samo prosto, jak wyobrazisz sobie, że dostajesz to zadanie bez żadnego kontekstu gdy byłeś Junior React Native Developerem z 3 miesięcznym stażem? 🙂

W efekcie, praca w IT to nieustanna nauka, adaptacja i elastyczność. To branża, w której trudno bazować na stałych schematach i korzystać z wydeptanych ścieżek. Zdolność reagowania na zmiany i rozwiązywania problemów zanim staną się krytyczne, jest jedną z najważniejszych cech zarówno developerów ale i firm.

## 4. Popularne mity

### 4.1 “2 developerów = 2x szybciej”

Nie zawsze da się łatwo podzielić zadania – wiele z nich musi być realizowanych sekwencyjnie. Doskonałym przykładem jest tworzenie aplikacji mobilnej od zera. Trudno pracować nad ekranem filtrów gości, jeśli lista gości jeszcze nie istnieje lub jest w trakcie tworzenia przez innego developera. 🙂

Do tego dochodzą konflikty podczas mergowania kodu, code review, problemy z synchronizacją pracy... A to dopiero początek. Najważniejszym (i często niedocenianym) aspektem jest komunikacja, której złożoność rośnie wykładniczo: przy 2 osobach mamy 1 połączenie, ale przy 4 osobach już 6 – i z każdym kolejnym członkiem zespołu robi się tylko trudniej.

### 4.2  “Już to robiłeś, więc szybko zrobisz”

W punkcie 3. przedstawiłem różnicę między projektem IT a produkcją łączników ciesielskich. Podobnie można to ująć tutaj. Każdy projekt jest inny — ma swoją architekturę, inne wymagania, technologie ciągle się zmieniają, a do tego klient i kontakt biznesowy też bywają różni.

Dla porównania — gdy byłem juniorem, implementowałem autoryzację przez Okta OAuth. W kolejnym projekcie wymogiem było użycie Azure. Myślałem, że będzie to bardzo podobne, ale… szybko się przekonałem, że się myliłem. Azure miało swoje specyficzne wymagania dotyczące klienta, a na tamten moment w React Native były z tym problemy. Musiałem więc napisać własne rozwiązanie, co oznaczało konieczność dokładnego poznania całego procesu dołączania tokenów i ich przechwytywania, żeby Azure to w ogóle zaakceptowało.

Różnice czasowe to ok. 1 tydzień do 1 miesiąca.

### 4.3 “To tylko frontend”

Sam możesz sobie odpowiedzieć na pytanie jak często to słyszałeś 🙂. “Tylko frontend” to często: responsywność na różnych urządzeniach, różnice między platformowe lub między przeglądarkowe, customowe animacje i komponenty oraz różne API.

## 5. Podsumowanie

Pamiętaj o tych rzeczach a zmienisz swoje podejście do estymat ale i całej branży o 180 stopni

#### - Estymacja to sztuka

Pamiętaj, że nie ma wzoru matematycznego na perfekcyjną estymację. Głównym czynnikiem mającym ogromny wpływ na jej dokładność jest doświadczenie. Jako zespoły, developerzy, ale i osoby zarządzające ludźmi, musimy zaakceptować, że błędy wystąpią. Ważne jest, aby wyciągać z nich wnioski i nie popełniać ich w przyszłości.

#### - Niepewność jest normalna

To naturalne, że nie jesteś pewny swojej estymaty. Dlatego moim zdaniem najlepszym sposobem komunikacji są zakresy czasowe, a nie sztywne liczby — lepiej powiedzieć „1-2 tygodnie” niż „8 dni”. Unknown unknowns zawsze się pojawią, więc warto zostawić sobie bufor na nieprzewidziane sytuacje, który choć trochę ochroni zespół lub dewelopera przed negatywnymi konsekwencjami.

#### - Komunikacja dev-biznes jest kluczowa

Developerzy to  eksperci techniczni, a biznes zna kontekst i priorytety. Transparentna komunikacja o ryzykach i założeniach oraz zrozumienie celów biznesowych pomaga w lepszych estymacjach.

#### - Dokumentuj swoje estymaty

Pomoże ci to w przyszłości, a po pewnym czasie zauważysz, jakie błędy udało się wyeliminować.

#### - Nie bój się być konserwatywny

Lepiej dostarczyć coś wcześniej niż później. Staraj się zawsze dokładać bufory do swoich estymacji. Pamiętaj, że klient będzie dużo bardziej zadowolony, gdy zrobisz coś w 2 dni przy estymacie 3 dni, niż gdy zrobisz to w 3 dni, mając obiecaną 2-dniową realizację.

#### - Wyceniaj całym zespołem zaangażowanym w projekt (jeśli zespół to jedna osoba, to nie bój się radzić się innych)

#### Pamiętaj: "Under-promise, over-deliver"

Proces estymacji projektów i jego typowe problemy z perspektywy React Native developera z kilkuletnim stażem

Dlaczego estymacje w software developmencie są trudne?

W dzisiejszym cyfrowym krajobrazie doświadczenie użytkownika to więcej niż tylko ładny interfejs – to angażująca podróż. Animacje ewoluowały od prostych przejść CSS do dynamicznych, złożonych interakcji napędzanych zaawansowanymi bibliotekami JavaScript, a nawet technologiami 3D. Ten wpis na blogu śledzi ewolucję animacji webowych, podkreśla kluczowe technologie stojące za nimi i prezentuje praktyczne przykłady, które mogą zainspirować Twój kolejny projekt.

## **1. Ewolucja animacji webowych**

Animacje od dawna są tajnym składnikiem tworzenia immersyjnych doświadczeń webowych. Początkowo proste animacje i przejścia CSS dawały nam płynne efekty hover i subtelne wskazówki wizualne. Dziś deweloperzy łączą CSS z potężnymi bibliotekami JavaScript – takimi jak GreenSock (GSAP), Anime.js oraz Framer Motion – by tworzyć animacje, które potrafią opowiadać historie, prowadzić interakcje użytkownika i ożywiać interfejsy w sposób nieosiągalny wcześniej.

## **2. Animacje CSS: Podstawa płynnych interfejsów**

CSS nadal pozostaje podstawowym narzędziem do prostych animacji. Dzięki właściwościom takim jak **transition** i **@keyframes**, CSS umożliwia osiągnięcie efektów od zanikania po przesuwanie elementów przy minimalnej ilości kodu. Przykładowo, efekt hover może wyglądać tak:

```css
.button {
  background-color: #3498db;
  color: #fff;
  padding: 1em 2em;
  border: none;
  border-radius: 4px;
  transition: background-color 0.3s ease;
}

.button:hover {
  background-color: #2980b9;
}
```

Ten przykład pokazuje, jak prosta zmiana koloru może wzmocnić wrażenie interaktywności przycisku. Animacje CSS są nie tylko lekkie, ale także optymalizowane przez przeglądarki, dzięki czemu idealnie nadają się do wielu popularnych efektów.

## **3. Zaawansowane biblioteki: Odblokowanie złożonych animacji**

Do bardziej zaawansowanych animacji CSS może nie wystarczyć. Wtedy do akcji wkraczają zaawansowane biblioteki:

### **3.1. GreenSock (GSAP)**

GSAP to potężne narzędzie do tworzenia animacji o wysokiej wydajności. Pozwala kontrolować czas, sekwencjonować skomplikowane animacje, a nawet synchronizować je ze zdarzeniami scrollowania. Oto przykładowy fragment kodu prezentujący prostą animację w GSAP:

```ts
// Animate an element with the ID 'hero'
gsap.from("#hero", { 
  duration: 1.5, 
  y: -50, 
  opacity: 0, 
  ease: "power2.out" 
});

```

Ten kod powoduje pojawianie się elementu z góry poprzez stopniowe zwiększanie jego opacity, tworząc dynamiczny efekt wejścia, który może być częścią szerszej narracji na stronie głównej.

### **3.2. Anime.js i Framer Motion**

Zarówno Anime.js, jak i Framer Motion oferują deklaratywne podejście do zarządzania animacjami w aplikacjach webowych. Anime.js świetnie nadaje się do animowania wielu właściwości oraz złożonych ścieżek SVG, natomiast Framer Motion integruje się płynnie z React, przez co często bywa wyborem przy tworzeniu interaktywnych UI.

*Przykład użycia Anime.js:*

```ts
anime({
  targets: '.box',
  translateX: 250,
  rotate: '1turn',
  duration: 2000
});
```

Ten fragment przesuwa element poziomo i jednocześnie go obraca, pokazując, jak animacje mogą zmienić statyczną treść w angażujące doświadczenie.

## **4. Praktyczne zastosowania: Animacja w akcji**

Współczesne animacje webowe to nie tylko estetyka – rozwiązują rzeczywiste wyzwania UX:

* **Wskaźniki ładowania:** Animowane loadery informują użytkowników o pobieraniu danych.
* **Mikrointerakcje:** Subtelne animacje przy polubieniu posta czy dodaniu produktu do koszyka zwiększają informację zwrotną dla użytkownika.
* **Opowiadanie historii:** Parallax scrolling i interaktywne linie czasu prowadzą użytkownika przez narrację na stronach landingowych.
* **Wizualizacje 3D:** Biblioteki takie jak Three.js pozwalają deweloperom tworzyć interaktywne sceny 3D, zamieniając strony www w miniaturowe wirtualne światy.

Na przykład, interaktywny dashboard może wykorzystać GSAP do animowania przejść danych, zapewniając użytkownikom wizualne śledzenie zmian w złożonych zestawach danych.

## **5. Najlepsze praktyki nowoczesnych animacji webowych**

* **Celowość:** Dbaj, by każda animacja służyła użyteczności, a nie rozpraszała użytkownika.
* **Wydajność:** Nadmiar ciężkich animacji może pogorszyć wydajność; gdzie to możliwe, optymalizuj efekty przy pomocy akceleracji sprzętowej CSS.
* **Dostępność:** Zapewnij opcje ograniczenia ruchu dla użytkowników wrażliwych na animacje.
* **Testuj na różnych urządzeniach:** Zawsze sprawdzaj, czy animacje działają płynnie na różnych rozmiarach i typach ekranów.

## **6. Podsumowanie**

Nowoczesne animacje webowe łączą świat designu z interaktywnością, czyniąc interfejsy nie tylko funkcjonalnymi, ale i prawdziwie zachwycającymi. Niezależnie czy korzystasz z prostych przejść CSS, czy wdrażasz zaawansowane biblioteki jak GSAP czy Anime.js, kluczowe jest eksperymentowanie i znalezienie równowagi, która podniesie komfort użytkowania bez utraty wydajności. Wykorzystaj moc animacji i pozwól, by kreatywność przemieniła Twój kolejny projekt webowy w angażujące cyfrowe doświadczenie.

Przegląd trendów w animacjach internetowych oraz najpopularniejszych bibliotek animacji.

Nowoczesne animacje webowe: CSS i nie tylko

W ciągu ostatniego roku termin **Agent AI** przeszedł od modnego słowa do pola bitwy - nie tylko ze względu na szum, ale także na rzeczywistą produktywność. Być może widziałeś nagłówki o "kodowaniu agentowym" lub "sztucznej inteligencji wykonującej zadania", ale oto prawda:

> Agenci AI to nie tylko trend. Na nowo definiują to, co oznacza bycie wydajnym, nowoczesnym programistą

Przeanalizujmy, czym są agenci AI i dlaczego każdy programista powinien zacząć z nich korzystać.

## Czym jest agent AI?

Mówiąc najprościej, **agent AI** to oprogramowanie, które może:

1. **Zrozumieć zadanie lub cel**
2. **zaplanować, jak je osiągnąć**
3. **Podejmowanie samodzielnych działań** - takich jak pisanie kodu, testowanie, uruchamianie poleceń lub odpytywanie interfejsów API
4. **Reagować na wyniki** i dostosowywać zachowanie

Podczas gdy tradycyjna sztuczna inteligencja (taka jak GitHub Copilot lub ChatGPT) może automatycznie uzupełnić funkcję lub pomóc w debugowaniu linii, agent AI może **naprawić błąd, napisać test, uruchomić go i otworzyć PR** - wszystko samodzielnie.

Agenci zmieniają sztuczną inteligencję z *inteligentnego narzędzia* w *półautonomicznego współpracownika*.

## Ok, więc jak działają agenci AI?

Pod maską większość agentów jest zasilana przez zestaw łamigłówek, takich jak:

* **duże modele językowe (LLM)**, takie jak GPT-4 lub Claude
* **pamięć/kontekst** do śledzenia tego, co robią w czasie
* **dostęp do narzędzi** - takich jak powłoki, API, systemy plików, bazy kodu
* **Planiści**, którzy decydują, jaki krok podjąć w następnej kolejności
* **Pętle sprzężenia zwrotnego** (czasami nawet samokorygujące zachowanie)

Ramy takie jak **OpenAI Assistants API**, **LangChain**, **AutoGPT** i **Microsoft Copilot Agents** przewodzą temu ruchowi - pozwalając programistom tworzyć lub integrować tych agentów z przepływami pracy przy minimalnej konfiguracji.

## W czym agenci AI są dobrzy?

Odpowiedź jest oczywista - w żmudnych, ogólnych zadaniach, na które większość deweloperów ma alergię. Oto jak to wygląda w praktyce:

### 1. **Refaktoryzacja i czyszczenie kodu**

Agenci mogą skanować repozytorium, identyfikować zapachy kodu, stosować spójne formatowanie, a nawet modernizować starszy kod (np. konwertując komponenty klas na funkcjonalne w React).

### 2. **Bezpieczeństwo i aktualizacje zależności**

Zamiast tylko ostrzegać o lukach w zabezpieczeniach, agent może:

* Aktualizować zależności
* Sprawdzić kompatybilność
* Uruchomić zestaw testów
* Otworzyć PR
  A wszystko to przy kawie.

### 3. **DevOps & Automation**

Od dostarczania infrastruktury po ponowne uruchamianie zablokowanych usług, agenci AI DevOps są wdrażani w celu **monitorowania, działania i naprawiania problemów**, zanim jeszcze zobaczysz alert.

## Czy agenci AI faktycznie zwiększają wydajność?

Tak - a oto dowody:

* **50-80% oszczędności czasu** na rutynowych zadaniach, takich jak linting, formatowanie, generowanie testów i aktualizacje zależności.
* **Mniej przełączeń kontekstu**: Pozostajesz w przepływie, podczas gdy agent zajmuje się konfiguracją, dokumentacją, standardami i czyszczeniem.
* **Krótszy czas realizacji**: Dzięki automatyzacji powtarzalnych etapów kodowania lub debugowania, szybciej przechodzisz od pomysłu do PR.
* **Lepszy DX**: Deweloperzy zgłaszają większą satysfakcję, gdy rozwiązują problemy - a nie gonią za zepsutymi konfiguracjami lub powtarzają polecenia git.

> Rezultat? Piszesz mniej standardowej dokumentacji i wykonujesz bardziej kreatywną pracę.

Firmy takie jak **GitHub**, **Microsoft**, **Replit** i **Sourcegraph** już używają agentów w produkcji - nie tylko jako dowód słuszności koncepcji, ale do **automatyzacji 20-40% rutynowych zadań programistów**.

## Nie zastępowanie deweloperów - wzmacnianie ich pozycji

Powszechną obawą jest: *"Czy agenci mają nas zastąpić? "*

Ale prawda jest taka: **są tu po to, by nas wywyższyć**.

Agenci AI nie zabierają ci pracy - zabierają twoje bilety Jira!&#x20;

Wkraczamy w erę, w której zrozumienie, jak **organizować i współpracować z agentami AI** będzie tak samo istotne, jak znajomość Git lub Docker. Programiści, którzy wcześnie je zaadoptują - i nauczą się, jak skutecznie nimi kierować - znacznie wyprzedzą swoich rówieśników. Jeśli chcesz być bardziej wydajnym programistą, nie używaj sztucznej inteligencji tylko do autouzupełniania -&#x20;
**zacznij budować z agentami, zacznij pracować z agentami**

Agenci AI: Nowi członkowie zespołu, dzięki którym programiści pracują 10x szybciej

Dostajemy dziennie pytanie: 'ile kosztuje aplikacja?' Odpowiedź: to zależy.

Ale wiemy, że to frustrująca odpowiedź. Dlatego stworzyliśmy przejrzysty cennik.

## Mała aplikacja — 7 000 €
MVP, do 5 ekranów. Idealny na start. Przykład: apka do zamawiania jedzenia z jednym flow.

## Średnia aplikacja — 14 000 €
Pełny produkt z backendem, panelem admina, integracjami. Przykład: marketplace z 3 typami użytkowników.

## Duża aplikacja — enterprise
AI, dedykowany zespół, architektura na lata. Przykład: platforma bettingowa z real-time odds.

## Co jest w cenie
- Design (UI/UX)
- Development (frontend + backend)
- Deployment
- Wsparcie po wdrożeniu (30-90 dni)

Żadnych ukrytych kosztów. Żadnego 'a to jednak będzie więcej'.

Rozbijamy budżet na części: design, backend, frontend, AI, devops. Zero wróżenia z fusów.

Ile kosztuje aplikacja w 2025? Konkretne liczby

Zacznijmy od podstaw. Adres URL (Uniform Resource Locator) to po prostu jednoznaczny adres, który pozwala odnaleźć konkretną stronę, plik czy zasób w sieci. Wpisując adres URL w przeglądarce, trafiasz dokładnie tam, gdzie chcesz – czy to na stronę główną sklepu, artykuł na blogu, czy obrazek. Bez adresów URL internet byłby chaosem, bo nie byłoby sposobu, by wskazać, gdzie znajduje się dana treść.

**Co to adres URL i z czego się składa?**

Jeśli zastanawiasz się: co to adres URL i jak wygląda, warto wiedzieć, że każdy taki adres zbudowany jest z kilku elementów:

* protokół (najczęściej https lub http)
* domena (np. twojastrona.pl)
* ścieżka (np. /blog/co-to-adres-url)
* czasem parametry (np. ?sort=desc)
* fragment (np. #sekcja1)

Najbardziej zaufane wśród użytkowników Polskiego internetu są domeny narodowe, w przypadku Polski z rozszerzeniem „pl”. Przykładowy adres URL może wyglądać tak:
[https://twojastrona.pl/blog/co-to-adres-url?sort=desc#sekcja1](https://aexol.com)

**Adres URL a SEO – dlaczego to takie ważne?**

No dobrze, ale co to jest adres URL w kontekście SEO? Okazuje się, że adres URL to jeden z pierwszych elementów, na które zwracają uwagę zarówno wyszukiwarki, jak i użytkownicy. Dobrze skonstruowany adres URL pomaga Google zrozumieć, czego dotyczy strona, a użytkownikowi – szybciej zdecydować, czy kliknie w wynik wyszukiwania.

Przyjazny adres URL, czyli taki, który jest krótki, czytelny i zawiera słowa kluczowe, może poprawić widoczność strony w Google. Przykład? Jeśli prowadzisz bloga o podróżach, lepiej użyć adresu url: *twojastrona.pl/blog/japonia-poradnik niż twojastrona.pl/blog/?id=1234*.

**Najważniejsze zasady tworzenia adresów URL pod SEO**

Zanim przejdziemy do konkretnych zasad, warto podkreślić, że odpowiednia konstrukcja adresu URL to podstawa skutecznej optymalizacji SEO. Przyjazny i dobrze przemyślany adres URL nie tylko ułatwia robotom wyszukiwarek indeksowanie strony, ale także poprawia doświadczenie użytkowników, zwiększając szanse na wyższe pozycje w wynikach wyszukiwania. Poniżej znajdziesz najważniejsze wskazówki, które pomogą Ci tworzyć adresy URL zgodne z najlepszymi praktykami SEO.

* Stosuj protokół https – to buduje zaufanie i jest sygnałem jakości dla Google.
* Używaj krótkich, zwięzłych i logicznych ścieżek.
* Wstawiaj słowa kluczowe związane z treścią strony, ale nie przesadzaj z ich ilością.
* Oddzielaj słowa myślnikami (nie podkreślnikami).
* Unikaj polskich znaków i znaków specjalnych.
* Nie zmieniaj adresów URL bez powodu – to może zaszkodzić SEO.

**Adres URL – co to oznacza dla użytkownika?**

Dobrze przygotowany adres URL to nie tylko ukłon w stronę wyszukiwarek, ale też wygoda dla odwiedzających. Przejrzysty adres url łatwiej zapamiętać, skopiować i udostępnić. Dzięki temu użytkownicy chętniej wracają na stronę i polecają ją innym.

**Podsumowanie**

Podsumowując: co to jest adres URL? To internetowy adres, dzięki któremu każdy może trafić na konkretną stronę lub plik. W kontekście SEO adres URL to jeden z kluczowych elementów wpływających na pozycjonowanie i odbiór strony przez użytkowników. Warto zadbać o jego przejrzystość, unikalność i zgodność z najlepszymi praktykami SEO. Dobrze przemyślany adres url może być Twoim sprzymierzeńcem w walce o lepsze pozycje w Google.

Adres URL – co to?

Aplikacja mObywatel to jedno z najważniejszych narzędzi cyfrowych w Polsce, które w ostatnich latach zrewolucjonizowało sposób, w jaki obywatele korzystają z usług publicznych i zarządzają swoimi dokumentami. Wpisuje się ona w globalny trend cyfryzacji administracji oraz rosnącej roli aplikacji mobilnych w codziennym życiu społecznym. Warto jednak pamiętać, że wraz z rosnącą popularnością aplikacji pojawiają się również nowe zagrożenia, takie jak „fake mObywatel” – fałszywe aplikacje, które mogą służyć cyberprzestępcom do wyłudzania naszych danych osobowych do których dostęp ma aplikacja. Dlatego zawsze należy pobierać aplikację wyłącznie z oficjalnych sklepów (Google Play lub App Store) i zachować ostrożność wobec podejrzanych linków, żeby uniknąć nieupoważnionego dostępu osób trzecich do Twoich danych np. jeśli masz przypisane w mObywatel prawo jazd itp.

## Nowy trend: cyfrowa tożsamość i e-usługi

Wprowadzenie mObywatela to odpowiedź na rosnące oczekiwania społeczeństwa dotyczące wygody, szybkości i dostępności usług publicznych. Polska, podobnie jak wiele innych krajów europejskich, stawia na rozwój cyfrowych rozwiązań tożsamościowych zgodnie z unijnym rozporządzeniem eIDAS 2.0, które ma na celu ujednolicenie cyfrowej identyfikacji w całej Unii Europejskiej. Aplikacja pozwala obywatelom na korzystanie z elektronicznych wersji dokumentów, takich jak dowód osobisty, prawo jazdy czy legitymacje, a także na dostęp do szeregu usług – od sprawdzania jakości powietrza, przez zgłaszanie wykroczeń środowiskowych, po płatności za podatki lokalne.

## Jak założyć mObywatel? To naprawdę proste!

Proces założenia konta w aplikacji mObywatel jest szybki i intuicyjny. Wystarczy pobrać oficjalną aplikację mObywatel ze sklepu Google Play lub App Store, a następnie przejść przez proces rejestracji, który polega na potwierdzeniu swojej tożsamości (np. przez profil zaufany lub bankowość elektroniczną). Po aktywacji aplikacji można od razu korzystać z jej funkcji i mieć swoje dokumenty zawsze pod ręką.

## Zalety mObywatela

Aplikacja mObywatel zdobyła popularność dzięki wielu korzyściom, które oferuje użytkownikom. Jej funkcje ułatwiają codzienne życie, czyniąc kontakt z administracją publiczną prostszym i bardziej dostępnym. Oto najważniejsze zalety tego rozwiązania:

* **Wygoda i oszczędność czasu:** Użytkownicy mogą załatwiać wiele spraw urzędowych bez wychodzenia z domu, co znacząco skraca czas obsługi i eliminuje konieczność noszenia papierowych dokumentów.
* **Szeroki zakres funkcji:** Aplikacja umożliwia m.in. sprawdzenie punktów karnych, historii pojazdu, korzystanie z e-recept, zgłaszanie pomysłów na rozwój aplikacji czy blokowanie numeru PESEL w przypadku zagrożenia.
* **Wysoka popularność:** mObywatel został pobrany ponad 16 milionów razy, a jego oceny w sklepach z aplikacjami są bardzo wysokie.
* **Bezpieczeństwo i transparentność:** Twórcy aplikacji podkreślają, że dane są wykorzystywane głównie do realizacji usług, które państwo już wcześniej świadczyło, a aplikacja powinna być projektowana zgodnie z zasadami privacy-by-design i privacy-by-default.

## Wady i wyzwania

Mimo licznych zalet, mObywatel nie jest rozwiązaniem pozbawionym wad. Wraz z rozwojem tego typu technologii pojawiają się nowe wyzwania, zarówno techniczne, jak i społeczne, które wymagają uwagi i dalszego doskonalenia. Do najważniejszych z nich należą:

* **Ograniczenia prawne i techniczne:** mObywatel nie zastępuje fizycznego dowodu osobistego przy przekraczaniu granicy czy w niektórych instytucjach, gdzie wciąż preferowana jest tradycyjna weryfikacja tożsamości.
* **Nierównomierna adopcja nowych funkcji:** Nie wszystkie instytucje wdrożyły najbardziej zaawansowane metody weryfikacji (np. kryptograficzną), co naraża użytkowników na ryzyko oszustw i phishingu.
* **Wątpliwości dotyczące prywatności:** Eksperci zwracają uwagę, że rozwój aplikacji powinien być transparentny, najlepiej w modelu open source, a użytkownicy powinni mieć łatwy dostęp do informacji, jakie dane i przez kogo są przetwarzane.
* **Możliwość nadużyć:** Istnieją doniesienia o potencjalnych lukach bezpieczeństwa, takich jak możliwość manipulacji danymi przez zewnętrzne aplikacje czy niewystarczająca ochrona kodów QR.
* **Fake mObywatel:** Coraz częściej pojawiają się ostrzeżenia przed fałszywymi wersjami aplikacji mObywatel, które mogą być wykorzystywane przez cyberprzestępców do wyłudzania danych osobowych. Dlatego tak ważne jest, by pobierać aplikację wyłącznie z oficjalnych źródeł i zawsze sprawdzać jej autentyczność.

## Społeczne znaczenie aplikacji mobilnych

mObywatel jest przykładem szerszego trendu, w którym aplikacje mobilne stają się nieodłącznym elementem codziennego życia – od bankowości, przez zdrowie, po relacje z administracją publiczną. Z roku na rok rośnie zakres spraw, które możemy załatwić za pomocą smartfona, co czyni nasze życie wygodniejszym, ale też stawia przed nami nowe wyzwania związane z bezpieczeństwem i ochroną prywatności.

"Kluczowe jest, by aplikacje nie były obowiązkowe i by każdy mógł decydować, czy z nich korzysta. To kwestia wolności wyboru i zaufania do państwa" – podkreśla Janusz Cieszyński, były minister cyfryzacji.

## Podsumowanie

Aplikacja mObywatel to narzędzie, które znacząco wspiera Polaków w codziennych czynnościach, oferując wygodę i szeroki zakres funkcji. Jej rozwój wpisuje się w globalny trend cyfryzacji życia społecznego. Jednak wraz z rosnącą rolą aplikacji mobilnych rosną także oczekiwania dotyczące bezpieczeństwa i transparentności. Warto pamiętać o zagrożeniach, takich jak fake mObywatel, i zawsze dbać o bezpieczeństwo swoich danych.

Z każdym rokiem aplikacje te stają się coraz ważniejsze i obejmują coraz więcej obszarów naszego życia – od urzędów po zdrowie i edukację. Trend cyfryzacji nie dotyczy wyłącznie życia społecznego, ale również działalności firm. Coraz więcej przedsiębiorstw modernizuje swoje procedury wewnętrzne, wdrażając nowoczesne systemy ERP, CRM, CMS, rozwiązania chmurowe oraz automatyzację procesów. Takie działania pozwalają firmom działać sprawniej, szybciej i bardziej elastycznie, co jest kluczowe w dynamicznie zmieniającym się otoczeniu biznesowym. Cyfryzacja firm to kolejny wymiar transformacji cyfrowej, który wspiera rozwój gospodarki i zwiększa konkurencyjność polskich przedsiębiorstw.

Chcesz wdrożyć nowe rozwiązania w Twojej firmie? Napisz do nas!

mObywatel – cyfrowa rewolucja czy klapa?

Hexagonal architecture, czyli architektura heksagonalna, to wzorzec projektowy, który zyskuje coraz większą popularność w świecie programowania. Jej celem jest stworzenie aplikacji o luźno powiązanych komponentach, które można łatwo wymieniać i testować niezależnie od zewnętrznych zależności. W tym artykule wyjaśnimy, czym dokładnie jest hexagonal architecture, jakie są jej kluczowe elementy oraz dlaczego warto ją stosować. Na koniec przedstawimy praktyczne przykłady, które pomogą lepiej zrozumieć, jak wdrożyć ten wzorzec w codziennej pracy.

## Czym jest hexagonal architecture?

Hexagonal architecture, znana także jako architektura portów i adapterów (ports & adapters), została zaproponowana przez Alistaira Cockburna w 2005 roku. Jej głównym założeniem jest oddzielenie logiki biznesowej (domeny) od wszelkich zależności zewnętrznych, takich jak bazy danych, interfejsy użytkownika czy zewnętrzne API. Dzięki temu aplikacja staje się bardziej modularna, łatwiejsza w utrzymaniu i testowaniu.

W przeciwieństwie do tradycyjnej architektury warstwowej, gdzie zależności biegną od warstw wyższych do niższych, w hexagonal architecture zależności kierowane są od zewnętrznych komponentów do wnętrza aplikacji, czyli do domeny. To domena definiuje porty – interfejsy komunikacji, a adaptery są ich implementacjami po stronie zewnętrznej.

## Kluczowe elementy hexagonal architecture

1. **Domena (Core)**
   To serce aplikacji, gdzie znajduje się logika biznesowa i przypadki użycia. Domena nie zna szczegółów implementacji zewnętrznych systemów i nie zależy od nich.
2. **Porty**
   Są to interfejsy definiujące, jak aplikacja komunikuje się ze światem zewnętrznym. Porty mogą być wejściowe (np. przyjmujące żądania od użytkownika) lub wyjściowe (np. wysyłające dane do bazy).
3. **Adaptery**
   Implementują porty i odpowiadają za komunikację z konkretnymi technologiami, takimi jak bazy danych, interfejsy użytkownika, API czy systemy zewnętrzne. Adaptery można łatwo wymieniać bez wpływu na logikę biznesową.

## Zalety stosowania hexagonal architecture

* **Modularność i wymienialność komponentów**
  Dzięki wyraźnemu podziałowi na porty i adaptery można łatwo podmieniać technologie, np. zmienić bazę danych lub interfejs użytkownika bez ingerencji w logikę biznesową.
* **Łatwość testowania**
  Logika biznesowa jest całkowicie odseparowana, co umożliwia testowanie jej w izolacji, bez konieczności uruchamiania zewnętrznych systemów.
* **Niezależność od frameworków i technologii**
  Kod domeny nie zależy od konkretnych bibliotek czy frameworków, co zwiększa jego stabilność i ułatwia rozwój.
* **Wsparcie dla Domain-Driven Design (DDD)**
  Hexagonal architecture dobrze współgra z podejściem DDD, ponieważ skupia się na domenie i jej przypadkach użycia.

## Praktyczne przykłady zastosowania hexagonal architecture

Aby lepiej zrozumieć, jak działa hexagonal architecture, warto przyjrzeć się kilku praktycznym przykładom z różnych obszarów.

**Aplikacja e-commerce**

Wyobraźmy sobie aplikację do sprzedaży online. W centrum (domenie) mamy logikę zarządzania zamówieniami, produktami i płatnościami. Porty definiują, jak aplikacja komunikuje się z zewnętrznym światem:

* **Port wejściowy** – API REST przyjmujące zamówienia od klientów.
* **Port wyjściowy** – interfejs do systemu płatności, który realizuje transakcje.

Adaptery implementują te porty:

* Adapter REST obsługuje żądania HTTP i przekazuje je do domeny.
* Adapter płatności integruje się z zewnętrznym serwisem, np. PayU lub Stripe.

Dzięki takiemu podejściu, jeśli za rok zdecydujemy się zmienić system płatności, wystarczy wymienić adapter płatności bez konieczności modyfikowania logiki biznesowej.

**System zarządzania treścią (CMS)**

W systemie CMS domena odpowiada za zarządzanie artykułami, użytkownikami i uprawnieniami. Porty mogą obejmować:

* **Port wejściowy** – interfejs użytkownika (np. panel administracyjny) lub API do publikowania treści.
* **Port wyjściowy** – dostęp do bazy danych lub systemu plików do przechowywania obrazów.

Adaptery to konkretne implementacje:

* Webowy frontend jako adapter wejściowy.
* Adapter bazy danych, np. do PostgreSQL lub MongoDB.
* Adapter do chmury, jeśli przechowujemy pliki na Amazon S3.

Dzięki hexagonal architecture możemy łatwo wymieniać bazę danych lub dodawać nowe kanały publikacji bez wpływu na domenę.

## Jak zacząć wdrażać hexagonal architecture?

1. **Zdefiniuj domenę i jej granice**
   Skup się na logice biznesowej i przypadkach użycia, które są sercem Twojej aplikacji.
2. **Określ porty**
   Zdefiniuj interfejsy komunikacji z zewnętrznym światem – zarówno wejściowe, jak i wyjściowe.
3. **Stwórz adaptery**
   Implementuj porty dla konkretnych technologii, takich jak bazy danych, API, interfejs użytkownika.
4. **Testuj domenę niezależnie**
   Dzięki izolacji logiki biznesowej możesz pisać testy jednostkowe bez konieczności uruchamiania zewnętrznych komponentów.

## Podsumowanie

Hexagonal architecture to wzorzec, który pomaga tworzyć elastyczne, testowalne i łatwe w utrzymaniu aplikacje. Dzięki wyraźnemu rozdzieleniu domeny od zewnętrznych zależności, aplikacje oparte na hexagonal architecture są bardziej odporne na zmiany technologiczne i łatwiejsze w rozwoju.

Praktyczne przykłady pokazują, jak ten wzorzec może być stosowany w różnych typach aplikacji – od e-commerce, przez CMS, aż po aplikacje mobilne. Jeśli chcesz, aby Twoje projekty były bardziej modularne i łatwiejsze w utrzymaniu, warto rozważyć wdrożenie hexagonal architecture.

Masz pytania dotyczące implementacji hexagonal architecture lub chcesz poznać narzędzia, które ułatwią Ci pracę z tym wzorcem? Napisz do nas.

Architektura heksagonalna (ang. hexagonal architecture) – co to jest?

W ostatnich latach coraz częściej słyszymy o gamifikacji, zwanej także grywalizacją. Terminy te są często używane zamiennie, ale oba odnoszą się do jednej idei – wykorzystania elementów gier w kontekstach niezwiązanych bezpośrednio z rozrywką. W artykule wyjaśnimy, czym dokładnie jest gamifikacja, jakie są jej kluczowe założenia oraz dlaczego zdobywa tak dużą popularność w biznesie, edukacji i marketingu.

## Gamifikacja co to? Definicja i podstawy

Gamifikacja (z ang. *gamification,* lub jej bardziej Polski odpowiednik, czyli grywalizacja) to proces implementacji mechanizmów znanych z gier, takich jak punkty, rankingi, pasek progresu, wyzwania czy odznaki, do procesów takich jak marketing, edukacja, szkolenia czy sprzedaż. Celem jest zwiększenie zaangażowania użytkowników, motywowanie ich do określonych działań oraz budowanie pozytywnych nawyków poprzez zabawę i rywalizację.

W praktyce gamifikacja polega na tym, że codzienne zadania, które mogą wydawać się nudne lub monotonne, stają się bardziej atrakcyjne i satysfakcjonujące. Dzięki temu użytkownicy chętniej angażują się w procesy edukacyjne, marketingowe czy biznesowe.

## Kluczowe założenia gamifikacji

1. **Mechanizmy znane z gier**
   W gamifikacji wykorzystywane są elementy takie jak punkty, poziomy, rankingi, odznaki, paski postępu, wyzwania i nagrody. To one tworzą strukturę gry i zachęcają do działania.
2. **Motywacja i zaangażowanie**
   Poprzez rywalizację, współpracę i system nagród gamifikacja zwiększa motywację użytkowników do wykonywania określonych zadań. Dzięki temu procesy stają się bardziej angażujące.
3. **Celowość i mierzalność**
   Gamifikacja nie jest celem samym w sobie – ma konkretne cele biznesowe lub edukacyjne, takie jak zwiększenie sprzedaży, poprawa efektywności nauki czy budowanie lojalności klientów. Efekty można mierzyć poprzez analizę wyników i zachowań użytkowników.
4. **Dostosowanie do odbiorcy**
   Aby gamifikacja była skuteczna, musi być odpowiednio dopasowana do grupy docelowej. Gra powinna być ani zbyt łatwa, ani zbyt trudna, aby użytkownicy czuli satysfakcję i chęć dalszego uczestnictwa.

## Zastosowania gamifikacji – gdzie sprawdza się najlepiej?

Gamifikacja znajduje zastosowanie w wielu dziedzinach, a jej popularność stale rośnie. Oto najważniejsze obszary, w których jest wykorzystywana:

* **Marketing i sprzedaż**
  Programy lojalnościowe oparte na punktach, konkursy, quizy i wyzwania angażują klientów, zwiększając ich lojalność i zachęcając do częstszych zakupów w sklepach internetowych.
* **Edukacja i szkolenia**
  Gamifikacja pomaga uczniom i pracownikom lepiej przyswajać wiedzę, poprzez interaktywne zadania, quizy i systemy nagród, które motywują do nauki.
* **Rekrutacja i motywacja pracowników**
  Grywalizacja w HR wspiera procesy rekrutacyjne, onboarding oraz rozwój kompetencji, zwiększając zaangażowanie i efektywność zespołu.
* **Kampanie społeczne i zdrowotne**
  Promowanie zdrowego stylu życia, aktywności fizycznej czy działań proekologicznych z wykorzystaniem wyzwań i nagród motywuje do pozytywnych zmian.

## Dlaczego gamifikacja działa?

Sekret skuteczności gamifikacji tkwi w naturalnej ludzkiej potrzebie rywalizacji, osiągania celów i otrzymywania nagród. Elementy gry sprawiają, że nawet trudne lub nudne zadania stają się przyjemne i angażujące. Dzięki temu użytkownicy chętniej wykonują działania, które w tradycyjnych warunkach mogłyby być dla nich zbyt wymagające lub mało atrakcyjne.

Dodatkowo gamifikacja pozwala na budowanie pozytywnych nawyków i wzmacnianie relacji między marką a klientem, co przekłada się na długoterminowe korzyści biznesowe.

## Podsumowanie

Gamifikacja, czyli grywalizacja, to nowoczesne narzędzie, które zmienia sposób, w jaki angażujemy się w różne aktywności – od nauki, przez pracę, aż po zakupy e-commerce. Dzięki zastosowaniu mechanizmów znanych z gier, takich jak punkty, rankingi czy odznaki, codzienne zadania stają się bardziej atrakcyjne i motywujące. Jeśli zastanawiasz się „gamifikacja co to?” lub „grywalizacja co to?”, teraz masz pełniejszy obraz tego, jak ta technika działa i dlaczego warto ją stosować.

Jeśli chcesz wprowadzić gamifikację w swojej firmie lub projekcie, warto zacząć od określenia celów i dobrania odpowiednich mechanizmów, które najlepiej zmotywują Twoją grupę docelową. To inwestycja, która może przynieść wymierne korzyści zarówno w sferze biznesowej, jak i edukacyjnej.

Gamifikacja, co to jest? 

##

Tagi NFC (Near Field Communication) zmieniają sposób, w jaki wchodzimy w interakcje ze światem, umożliwiając płynną, bezpieczną i natychmiastową wymianę danych między urządzeniami. Niezależnie od tego, czy stukasz telefonem, aby zapłacić za kawę, czy odblokowujesz pokój hotelowy za pomocą inteligentnego klucza, tagi NFC są niewidzialną siłą napędzającą te codzienne udogodnienia.

## Czym są tagi NFC?

Tagi NFC to małe, bezprzewodowe chipy danych, które komunikują się z kompatybilnymi urządzeniami, takimi jak smartfony, po zbliżeniu ich do siebie na odległość kilku centymetrów. W przeciwieństwie do swojego poprzednika, RFID, który umożliwia tylko jednokierunkową komunikację, NFC umożliwia zarówno jednokierunkową, jak i dwukierunkową wymianę danych, dzięki czemu idealnie nadaje się do interaktywnych zastosowań, takich jak płatności mobilne i bezpieczna kontrola dostępu.

## Jak działają tagi NFC?

Tagi NFC działają na krótkich dystansach (zazwyczaj do 4 cali), wykorzystując fale radiowe do przesyłania danych. Nie wymagają baterii; zamiast tego pobierają energię z urządzenia, które je odczytuje, takiego jak smartfon. Dzięki temu są opłacalne i łatwe do wdrożenia w różnych środowiskach. Każda interakcja NFC jest bezpiecznym, szyfrowanym procesem, minimalizującym ryzyko kradzieży danych lub przypadkowych transakcji.

## Rodzaje tagów NFC

Tagi NFC występują w kilku typach, z których każdy nadaje się do różnych zastosowań:

* **Typ 1:** Podstawowy, tani, idealny do prostych zadań, takich jak udostępnianie adresów URL.
* **Typ 2:** Nieco bardziej zaawansowany, używany do biletów na wydarzenia i transakcji o niskiej wartości.
* **Typ 3:** Większa pamięć i szybkość, idealny do pieniądza elektronicznego i cyfrowych dokumentów tożsamości.
* **Typ 4:** Wszechstronny, z dużą pamięcią i szybkością, powszechnie używany do płatności i biletów elektronicznych.
* **Typ 5:** wyspecjalizowany dla sektorów takich jak opieka zdrowotna i zarządzanie zapasami.

## Kluczowe komponenty tagów NFC

Tagi NFC to genialnie proste, ale potężne urządzenia, zbudowane z trzech podstawowych komponentów, które współpracują ze sobą, aby umożliwić płynną komunikację bezprzewodową:

* **Mikroprocesor NFC (IC):** Mikroprocesor jest mózgiem tagu NFC, odpowiedzialnym za przechowywanie danych i zarządzanie protokołami komunikacyjnymi. Przechowuje informacje takie jak adresy URL, dane kontaktowe lub kody uwierzytelniające. Chip jest zaprojektowany tak, aby był energooszczędny i jest zwykle umieszczany w środku tagu, aby chronić go przed fizycznymi uszkodzeniami.
* **Antena:** Owinięta wokół mikrochipa lub osadzona w strukturze tagu, antena jest zwykle wykonana z miedzi lub aluminium. Jej zadaniem jest nadawanie i odbieranie fal radiowych, umożliwiając tagowi komunikację z urządzeniami obsługującymi technologię NFC. Konstrukcja i rozmiar anteny wpływają na zasięg i wydajność tagu.
* **Podłoże:** Jest to fizyczna podstawa, która obsługuje zarówno mikroprocesor, jak i antenę. Podłoża mogą być wykonane z różnych materiałów, takich jak plastik, metal, a nawet papier, w zależności od przeznaczenia. Na przykład, elastyczne podłoża są używane do naklejek, podczas gdy sztywne znajdują się w kartach lub breloczkach. Wybór podłoża decyduje o trwałości, elastyczności i możliwościach zastosowania tagu NFC.

Razem te komponenty tworzą kompaktowe, bezbateryjne urządzenie, które może być wbudowane w przedmioty codziennego użytku - od wizytówek i plakatów po towary luksusowe i sprzęt biurowy.

## Dlaczego tagi NFC są tak popularne?

Tagi NFC zyskały na popularności w różnych branżach dzięki unikalnemu połączeniu wygody, wszechstronności i bezpieczeństwa. Oto dlaczego stały się one niezbędne:

* **Bezproblemowe interakcje:** Tagi NFC umożliwiają natychmiastową, bezkontaktową wymianę danych. Użytkownicy po prostu dotykają swoich smartfonów lub urządzeń, aby wejść w interakcję. Nie ma potrzeby ręcznego wprowadzania danych lub skomplikowanych konfiguracji. Dzięki temu zadania takie jak płatności, sprzedaż biletów i udostępnianie informacji są niezwykle szybkie i przyjazne dla użytkownika.
* **Szerokie zastosowanie:** Tagi NFC są wykorzystywane w handlu detalicznym do płatności zbliżeniowych i interaktywnego marketingu, w transporcie do sprzedaży biletów oraz w służbie zdrowia do śledzenia pacjentów i zarządzania lekami. Obsługują również automatyzację inteligentnego domu i odprawy wydarzeń, dzięki czemu są elastycznym rozwiązaniem dla niezliczonych scenariuszy.
* **Zwiększone bezpieczeństwo:** Technologia NFC wykorzystuje szyfrowaną komunikację i wymaga bliskiej fizycznej bliskości do działania, zmniejszając ryzyko przechwycenia lub nieautoryzowanego dostępu. To sprawia, że jest to zaufany wybór dla bezpiecznych transakcji i kontroli dostępu.
* **Zrównoważony rozwój:** Dzięki cyfryzacji procesów, które tradycyjnie opierały się na papierze - takich jak wizytówki, bilety i broszury - tagi NFC pomagają zmniejszyć ilość odpadów i wspierają inicjatywy przyjazne dla środowiska. Można je również zintegrować z łańcuchami dostaw, aby zoptymalizować wykorzystanie zasobów i zminimalizować nadprodukcję.
* **Zaangażowanie klientów:** Marki wykorzystują tagi NFC do dostarczania spersonalizowanych treści, weryfikowania autentyczności produktów i budowania bezpośrednich cyfrowych relacji z konsumentami. Zwiększa to lojalność wobec marki i poprawia ogólne wrażenia klientów.

Połączenie tych czynników sprawiło, że tagi NFC stały się technologią dla firm i konsumentów poszukujących szybkości, bezpieczeństwa i innowacji w codziennych interakcjach.

## Podsumowanie

Technologia NFC po cichu rewolucjonizuje nasze cyfrowe interakcje. Wraz ze wzrostem jej popularności należy spodziewać się jeszcze bardziej innowacyjnych zastosowań w codziennym życiu. Korzystasz z technologii NFC, płacąc za towary za pomocą telefonu lub smartwatcha, odblokowując drzwi lub meldując się na siłowni, uruchamiając inteligentne procedury domowe lub łącząc się z drukarką bezprzewodową. Zastanawiasz się, jakie korzyści NFC może przynieść Twojej firmie? Skontaktuj się z nami i porozmawiajmy o tym!

Czym są tagi NFC? Jak działa technologia zbliżeniowa

## Gotowe sklepy internetowe: świetny start, ale czy nie staną się blokadą rozwoju?

**Dlaczego gotowe sklepy są dobrym wyborem na początek?**

Na starcie działalności e-commerce gotowe platformy sklepowe (np. Shopify, Shoper, WooCommerce) wydają się idealnym rozwiązaniem. Pozwalają szybko uruchomić sprzedaż online bez konieczności inwestowania w kosztowne wdrożenia czy zatrudniania programistów. Ich zalety to:

* Szybka konfiguracja i prostota obsługi
* Niskie koszty początkowe
* Gotowe szablony i integracje z popularnymi płatnościami oraz kurierami
* Brak konieczności posiadania wiedzy technicznej

Dla firm z niewielką liczbą produktów i ograniczonym budżetem to często najlepszy sposób, by przetestować pomysł na biznes i zacząć zdobywać pierwszych klientów.

**Kiedy gotowy sklep staje się pułapką?**

Wraz z rozwojem firmy i wzrostem liczby zamówień pojawiają się nowe potrzeby. Gotowe platformy, które na początku były atutem, mogą zacząć ograniczać rozwój. Najczęstsze problemy to:

* Ograniczona możliwość personalizacji sklepu i procesu zakupowego
* Brak wsparcia dla niestandardowych integracji (np. z systemami ERP, magazynowymi, programami lojalnościowymi)
* Trudności z optymalizacją wydajności przy dużym ruchu
* Ograniczenia w rozbudowie funkcjonalności (np. nietypowe promocje, specyficzne warianty produktów)
* Wysokie koszty prowizji lub abonamentu przy dużej sprzedaży

W efekcie sklep, który miał ułatwiać rozwój, zaczyna go blokować. Firma traci elastyczność, a wdrożenie nowych pomysłów wymaga kosztownych obejść lub migracji na bardziej zaawansowane rozwiązanie.

**Przykład: Migracja sklepu magicznyrynek.pl ze Sky-Shop na Deenruv**

Dobrym przykładem ilustrującym potrzebę migracji ze Sky-Shop na Deenruv jest sklep magicznyrynek.pl. Dla jego właścicieli kluczowym wyzwaniem okazały się ograniczenia Sky-Shop w zakresie integracji z zewnętrznym magazynem, gdzie przechowywana była część zapasów. Brak możliwości płynnej synchronizacji stanów magazynowych oraz automatycznej aktualizacji dostępności produktów uniemożliwiał dalszy rozwój sklepu i skuteczne zarządzanie zamówieniami.

Migracja na platformę Deenruv pozwoliła wdrożyć pełną integrację z zewnętrznym magazynem, zapewniając automatyczną aktualizację stanów magazynowych i eliminując ryzyko błędów przy realizacji zamówień. Dzięki temu [magicznyrynek.pl](https://magicznyrynek.pl "magicznyrynek.pl") mógł sprawnie skalować działalność, oferując klientom aktualne informacje o dostępności produktów i znacząco podnosząc jakość obsługi. Więcej szczegółów dotyczących tej migracji znajdziesz w naszym case study: [magicznyrynek.pl – case study](https://aexol.com/pl/casestudies/magicznyrynek/).

**Znaczenie SEO i integracji z Google Merchant Center**

Wraz z migracją na bardziej elastyczną platformę, jak Deenruv, otworzyły się nowe możliwości w zakresie skutecznego pozycjonowania sklepu oraz integracji z narzędziami Google. Jednym z kluczowych elementów okazała się poprawna integracja z Google Merchant Center za pomocą Merchant API. Dzięki temu rozwiązaniu możliwa jest automatyczna i bieżąca aktualizacja oferty produktowej, co przekłada się na wyższą jakość prezentowanych danych oraz lepszą widoczność produktów w Zakupach Google i innych usługach Google.

Zastosowanie najlepszych praktyk SEO – takich jak optymalizacja opisów produktów, wdrożenie danych strukturalnych czy regularna analiza indeksacji – pozwoliło zwiększyć widoczność sklepu w wynikach wyszukiwania oraz dotrzeć do nowych klientów. Integracja z Merchant Center i konsekwentne działania SEO przyczyniły się do wzrostu ruchu na stronie oraz wyższej konwersji, co potwierdza, jak ważne jest kompleksowe podejście do rozwoju e-commerce na dedykowanej platformie.

### **Podsumowanie**

Gotowe sklepy internetowe to świetny wybór na początek – pozwalają szybko wejść na rynek i przetestować biznes. Jednak wraz z rozwojem firmy warto regularnie analizować, czy platforma nie staje się ograniczeniem. W pewnym momencie inwestycja w bardziej elastyczne, dedykowane rozwiązanie może okazać się niezbędna, by utrzymać tempo wzrostu i przewagę konkurencyjną.&#x20;

Planujesz otowrzyć sklep online lub potrzbujesz wsparcia w modernizacji starego sklepu, aby w końcu zaczął sprzedawac? Dowiedzieć się więcej o naszych rozwiązaniach, skutecznej integracji z Google Merchant oraz najlepszych praktykach SEO -  skontaktuj się z nami.

Gotowe sklepy sprawdzają się, gdy masz mało produktów lub dopiero zaczynasz, ale szybko stają sie blokerem wzrostu

Case Study: Przejście ze Sky Shop na bardziej elastyczny silnik e-Commerce

# Zustand: Proste i skalowalne rozwiązanie do zarządzania stanem w React

Zarządzanie stanem to od zawsze gorący temat w ekosystemie React. Dostępnych jest wiele opcji—Redux, Context API, MobX, Recoil i inne—co sprawia, że wybór odpowiedniej może być przytłaczający. Wśród nich **Zustand** zyskał popularność dzięki swojej prostocie i minimalnemu API, będąc jednocześnie wystarczająco potężnym rozwiązaniem do dużych aplikacji.

## Czym jest Zustand?

Zustand to małe, szybkie i skalowalne rozwiązanie do zarządzania stanem dla React. Stworzone przez Poimandres, wykorzystuje hooks, oferując przejrzyste API bez zbędnego boilerplate'u znanego z Redux oraz bez problemów wydajnościowych związanych z Context API.

### Kluczowe cechy

- **Minimalne API**: Nie potrzebujesz akcji, reduktorów ani funkcji dispatch.
- **Skalowalność**: Sprawdza się zarówno w małych, jak i dużych aplikacjach.
- **Brak potrzeby providerów**: W odróżnieniu od Context API, store Zustand działa poza React.
- **Współpraca z React DevTools**: Bezproblemowa integracja do debugowania.

## Dlaczego Zustand?

### Prostota

Redux jest potężny, ale wiąże się z dużą ilością boilerplate'u. Potrzebujesz akcji, reduktorów, dispatcherów i middleware tylko po to, by zarządzać stanem. Zustand upraszcza to, pozwalając na stworzenie store'a przy użyciu pojedynczej funkcji.

### Wydajność

Context API doskonale sprawdza się przy prostych przypadkach użycia, jednak przy częstych zmianach stanu może powodować niepotrzebne renderowanie całego drzewa komponentów. Zustand tego unika, pozwalając komponentom subskrybować tylko te fragmenty stanu, których faktycznie potrzebują.

### Doświadczenie deweloperskie

API Zustand zostało zaprojektowane tak, aby było intuicyjne. Nie musisz uczyć się nowego paradygmatu—wystarczy, że utworzysz store i po prostu z niego korzystasz.

l })
  }),
  { name: 'user-storage' }
));
```

### 3.2. Wybiórcze rerendery

W przeciwieństwie do **useContext**, które powoduje rerendery przy każdej zmianie stanu, Zustand pozwala na subskrybowanie wybranych części stanu, co poprawia wydajność:
const count = useCounterStore((state) => state.count);
To sprawia, że komponent rerenderuje się tylko wtedy, gdy zmienia się **count**, unikając niepotrzebnych aktualizacji.

### 3.3. Asynchroniczne aktualizacje stanu

Zustand świetnie radzi sobie z asynchronicznymi aktualizacjami stanu, dzięki czemu idealnie nadaje się do zapytań API czy innych operacji asynchronicznych:

```ts
const useDataStore = create((set) => ({
  data: [],
  fetchData: async () => {
    const response = await fetch('https://jsonplaceholder.typicode.com/posts');
    const jsonData = await response.json();
    set({ data: jsonData });
  }
}));
```

### 3.4. Łączenie wielu store'ów

W większych aplikacjach Zustand pozwala na modularizację stanu w osobnych store'ach:

```ts
const useAuthStore = create((set) => ({
  isAuthenticated: false,
  login: () => set({ isAuthenticated: true }),
  logout: () => set({ isAuthenticated: false })
}));

const useProfileStore = create((set) => ({
  name: '',
  setName: (newName) => set({ name: newName })
}));
```

Te store'y mogą być używane niezależnie lub łączone w zależności od potrzeb.

### 4. Kiedy używać Zustand

Zustand świetnie sprawdzi się w aplikacjach wymagających prostego, ale zaawansowanego zarządzania stanem, bez złożoności Redux. Jest szczególnie przydatny, gdy:

* Potrzebujesz globalnego stanu bez przekazywania propsów w dół drzewa komponentów.
* Liczy się wydajność i chcesz uniknąć zbędnych rerenderów.
* Wolisz niewielkie rozwiązanie do zarządzania stanem, wolne od zależności.
* Ceniona jest łatwa konserwacja i modularność.
* Szukasz rozwiązania, które dobrze działa z SSR i React Server Components.

|    **Funkcja**    | **Zustand** | **Redux** | **Recoil** | **Jotai** |
| :---------------: | :---------: | :-------: | :--------: | :-------: |
|  **Boilerplate**  |     Mało    |   Dużo    |   Średnio  |    Mało   |
|  **Wydajność**    |    Wysoka   |  Średnia  |   Wysoka   |   Wysoka  |
|   **Middleware**  |     Tak     |    Tak    |  Ograniczone |   Nie     |
| **Wsparcie async**|     Tak     |    Tak    |     Tak    |    Tak    |
|  **Trwałość**     |     Tak     |    Tak    |     Nie    |    Nie    |

## **6. Podsumowanie**

Zustand stanowi atrakcyjną alternatywę dla Redux, oferując minimalistyczne API, wysoką wydajność i łatwość użycia. Niezależnie od tego, czy pracujesz nad małym projektem pobocznym, czy dużą aplikacją, Zustand może uprościć zarządzanie stanem, eliminując zbędny boilerplate i poprawiając efektywność.

Czy używasz Zustand w swoich projektach? Jeśli nie, może warto spróbować!

Zustand to niewielka, lecz potężna biblioteka do zarządzania stanem, która oferuje minimalistyczne API przy zachowaniu wysokiej skalowalności.

Zustand: Proste i skalowalne zarządzanie stanem w React

Podczas uzyskiwania dostępu do danych tablicy w TypeScript, a nawet JavaScript, najczęściej używaną metodą jest notacja nawiasowa: `[]`. Choć to oczywiście działa, istnieje lepsze rozwiązanie, zwłaszcza gdy zależy nam na bezpieczeństwie typów: metoda `.at()`. Może być mniej znana, ponieważ została wprowadzona stosunkowo niedawno w ECMAScript 2022, jednak w rzeczywistości jest bezpieczniejsza i bardziej intuicyjna. Zanurzmy się w szczegóły i sprawdźmy, jakie oferuje korzyści.

## Różnica typów

Kluczowa różnica polega na tym, jak każda z metod obsługuje typy:

* notacja nawiasowa `[]`: Zawsze zwraca typ `string`
* metoda tablicy `.at()`: Zawsze zwraca typ `string | undefined`

Spójrzmy na przykład:

```ts
   const pkmn = ["Pikachu", "Charizard", "Mew"];
   const pika = pkmn[0]
   const pikaAt = pkmn.at(0)
```

Tutaj nie zobaczysz jeszcze różnicy, ponieważ obie metody zwrócą „Pikachu”. Jednak wszystko zmienia się, gdy użyjesz indeksu spoza zakresu lub pustej tablicy. Spróbujmy zamienić na wielkie litery wartość z nieprawidłowego indeksu:

```ts
  const pkmn = ["Pikachu", "Charizard", "Mew"];
  const outsideArray = pkmn[4]
  const outsideArrayAt = pkmn.at(4)
  console.log("brackets test", outsideArray.toUpperCase()) // Rzuca TypeError
  console.log("array at test", outsideArrayAt?.toUpperCase()) // Bezpiecznie zwraca undefined
```

Podczas gdy metoda `.at()` bezpiecznie zwraca undefined, gdy odwołasz się do nieprawidłowego indeksu, notacja nawiasowa skutkuje TypeError: Cannot read properties of undefined (reading 'toUpperCase'). Może to prowadzić do awarii aplikacji w trakcie działania lub błędów podczas budowania, szczególnie gdy aplikacja korzysta z dynamicznych danych.

Ta sama zasada dotyczy pustej tablicy. Na przykład:

```ts
const emptyArray: string[] = [];
const firstValue = emptyArray[0]; // TypeError
const firstValueAt = emptyArray.at(0); // undefined
```

## Czytelniejsze indeksowanie ujemne

Dostęp do elementów od końca tablicy to coś, co często spotyka się przy obsłudze takich rzeczy, jak paginacja czy logowanie. To właśnie tutaj metoda `.at()` okazuje się przydatna — pozwala na indeksowanie ujemne w czystszy i bardziej przejrzysty sposób:

```ts
   const pkmn = ["Pikachu", "Charizard", "Mew"];
   const lastTwo = [pkmn[pkmn.length - 1], pkmn[pkmn.length - 2]];
   const lastTwoAt = [pkmn.at(-1), pkmn.at(-2)];
```

## `.at()` jest po prostu lepsze

Choć `.at()` wydaje się niewielkim dodatkiem do JavaScript, w rzeczywistości jest bardziej intuicyjnym sposobem dostępu do elementów tablicy. Poprawia bezpieczeństwo typów, zwracając undefined dla nieprawidłowych indeksów, zmniejszając ilość błędów w czasie działania i upraszczając indeksowanie ujemne. Notacja nawiasowa `[]` wciąż działa, jednak `.at()` to nowoczesna alternatywa, zgodna z najlepszymi praktykami w TypeScript i pozwalająca unikać częstych błędów. To nie jest obowiązkowy wybór, ale po prostu lepsza opcja dla czystszego i bezpieczniejszego kodu.

TypeScript skupia się na bezpieczeństwie typów — sprawdźmy, jak wygląda to podczas pracy z danymi w tablicy.

Dlaczego .at() jest lepsze od [] do dostępu do tablic w TypeScript

W ostatni weekend przydarzyła mi się dziwna sytuacja. Wszystko zaczęło się, gdy zauważyłem na GitLabie, że jeden z moich folderów w repozytorium jest tak naprawdę submodulem. Było już późno, więc wszedłem na Stack Overflow, żeby znaleźć wątek dotyczący odłączania modułu od repozytorium :)

## Przywracanie plików usuniętych przez git rm za pomocą VSCode

Po skopiowaniu kilku komend spojrzałem na to, co zrobiłem i pomyślałem „o mój Boże” – usunąłem cały folder bez commitowania jakichkolwiek zmian. Co gorsza, dowiedziałem się, że podczas wymuszonego odłączania submodułu Git używa komendy rm -rf. Więc co teraz? Próbowałem szukać opcji w Gicie, ale uświadomiłem sobie, że żaden reset nie pomoże, bo te pliki po prostu nie istnieją w moim repo – to był tylko submodule z lokalnymi niezatwierdzonymi zmianami. Mógłbym opisywać wszystkie metody, które próbowałem, ale przejdźmy do sedna – uratował mnie VS Code Local History.

## VS Code Local History

Okazuje się, że praktycznie każdy plik, który edytujesz, ma w VSCode własną lokalną historię, która śledzi zdarzenia zapisywania pliku. Przywrócenie pliku jest naprawdę proste, wystarczy:

1. Nacisnąć Ctrl/CMD + Shift + P
2. Wybrać `Local History: Find Entry To Restore`
3. Przefiltrować wyniki, np. po nazwie folderu
4. Otworzyć plik
5. Kliknąć ikonę haczyka, by go przywrócić

Plik po pliku, właśnie w ten sposób udało mi się odzyskać całą skasowaną zawartość!

P.S. Nie robiłem tego tekstu zbyt długiego, bo jeśli jesteś w podobnej sytuacji, prawdopodobnie szukasz rozwiązania jak najszybciej i googlujesz ‘recover git rm files’ albo przeglądasz stack overflow. Bez obaw – VS Code Cię uratuje.

Czy zdarzyło Ci się kiedyś przypadkowo usunąć kilka dni pracy? Mnie tak, ale udało mi się wszystko odzyskać!

Jak odzyskać pliki usunięte przez git rm oraz niezcommitowany submoduł w VSCode

W miniony weekend w krakowskiej Tauron Arenie odbył się największy hackathon w Europie - Hackyeah 2023. Zawody zgromadziły utalentowane umysły z Polski i całej Europy i posłużyły jako pole bitwy dla ekspertów IT. Oczywiście udział w takim wydarzeniu to nie tylko praca i rywalizacja, ale także szansa na poznanie wielu różnych ludzi z branży IT oraz wymianę pomysłów, myśli i doświadczeń. Niemniej jednak wszyscy byli tam, aby zobaczyć główne wydarzenie - stawianie czoła wyzwaniom technologicznym w ciągu 24 godzin. Kategoria, w której brał udział zespół AEXOL, wymagała stworzenia rozwiązania modernizującego sektor edukacji przy użyciu technologii.

![Hackyeah](https://aexol-cms.fra1.cdn.digitaloceanspaces.com/aexolcom/media/hackyeah2-1730907339244.webp)

Nasz zespół wykorzystał sztuczną inteligencję do stworzenia kompletnego MVP (Minimum Viable Product) dla zadania GovTech, łącząc różne narzędzia, umiejętności i technologie. Dzięki temu zajęli trzecie miejsce w kategorii "Edukacja w innowacjach", a ich projekt przyciągnął uwagę zarówno uczestników, jak i sędziów konkursu ze względu na innowacyjne podejście do wyzwań edukacyjnych. Z dumą mogę powiedzieć, że nasz zespół stworzył jeden z najbardziej rozpoznawalnych projektów, które pojawiły się na tym wyjątkowym wydarzeniu.

## Zespół

Nagrodzony zespół składa się z Aleksandra Bondara (frontend developer), Arkadiusza Kuryło (backend developer), Adama Michałowskiego (frontend developer), Jakuba Sowy (grafik 3D - zewnętrzny dla AEXOL), Adrianny Gregorczuk (lider) i Moniki Szypurskiej (grafik - zewnętrzny dla AEXOL). Ich stack składał się z React, Next.js, TypeScript, GraphQL, Stucco.js, mongoDB, Figma i Blender. Służył on połączeniu różnych umiejętności członków zespołu i był kluczem do osiągnięcia celu wyzwania. Osiągnięcie to jest wynikiem połączonego wysiłku, który wymagał wielu godzin ciężkiej pracy i poświęcenia całego zespołu.
![Hackyeah](https://aexol-cms.fra1.cdn.digitaloceanspaces.com/aexolcom/media/hackyeah3-1730907356215.webp)
Projekt polegał na wdrożeniu sztucznej inteligencji, aby pomóc studentom w wyborze kierunku studiów. Skuteczne narzędzie pomagające w podejmowaniu kluczowych decyzji życiowych może być bardzo pomocne w dzisiejszym świecie, zwłaszcza jeśli chodzi o decyzje tak ważne, jak wybór odpowiedniej instytucji edukacyjnej lub kierunku studiów. Nasz zespół podjął wyzwanie, wykorzystując nasz przeszkolony model chatGPT i projektując aplikację wokół niego - umożliwiając użytkownikom łatwe i dokładne wyszukiwanie szkół, instytucji edukacyjnych lub programów studiów, które najlepiej odpowiadają ich indywidualnym potrzebom. Ich rozwiązanie może stać się częścią Portalu Edukacji i Nauki - edukacja.gov.pl!

## Badania - Pokolenia Z i Alpha

Znamy poruszane kwestie i cele projektu, ale tak naprawdę nie rozmawialiśmy o pierwszym kroku. Jak zespół wpadł na pomysł aplikacji, skąd się wziął i jakie badania na ten temat przeprowadził?

Znaczenie demograficzne pokolenia Z jest nie do przecenienia. Pokolenie to, stanowiące 15,4% populacji Polski, stoi przed wieloma wyjątkowymi wyzwaniami. Badania sugerują, że niezadowolenie doświadczane przez młode osoby może mieć daleko idące konsekwencje, co sprawia, że konieczne jest zajęcie się ich obawami w odpowiednim czasie.
![Hackyeah](https://aexol-cms.fra1.cdn.digitaloceanspaces.com/aexolcom/media/hackyeah4-1730907380398.webp)
Liczne badania psychologiczne dotyczyły wpływu niezrealizowanych aspiracji na samopoczucie psychiczne. Ciężar niespełnionych marzeń może prowadzić do poczucia frustracji i rozczarowania, podkreślając znaczenie zapewnienia młodym ludziom możliwości realizacji ich ambicji. Badania z zakresu psychologii społecznej konsekwentnie podkreślają znaczenie solidnego systemu wsparcia. Młode osoby, którym brakuje odpowiedniego wsparcia ze strony najbliższego otoczenia, mogą napotykać przeszkody w rozwoju osobistym i zawodowym. Inicjatywy mające na celu oferowanie mentoringu i wskazówek podczas przejścia do dorosłości są niezbędne dla ich rozwoju.

Patrząc na pokolenie Alpha, często określane jako "Always on", wczesne prognozy ekonomiczne i społeczno-naukowe wskazują na preferowanie wysoce spersonalizowanych doświadczeń, wzmocnienia pozycji i innowacji. Zrozumienie tych zmieniających się preferencji jest niezbędne do kształtowania przyszłego krajobrazu. Pojawiająca się jako potencjalne remedium na wieloaspektowe wyzwania stojące zarówno przed Pokoleniem Z, jak i Pokoleniem Alpha, kompetentna administracja AI oferuje wskazówki i wsparcie w podejmowaniu złożonych decyzji życiowych i zawodowych. Wykorzystanie mocy sztucznej inteligencji może być przełomem w zaspokajaniu potrzeb tych zaawansowanych technologicznie pokoleń.
![Hackyeah](https://aexol-cms.fra1.cdn.digitaloceanspaces.com/aexolcom/media/hackyeah5-1730907405673.webp)
Tworząc swoje rozwiązanie, zespół czerpał inspirację z wciągających cech obserwowanych na popularnych platformach do gier, takich jak Roblox i Minecraft. Te wirtualne środowiska były szeroko badane w kontekście zaangażowania i doświadczenia użytkowników. Łącząc elementy immersji i CAVE, starali się stworzyć produkt, który nie tylko przyciąga uwagę, ale także ewoluuje w wielu kierunkach, zachowując przy tym oryginalną koncepcję MVP.

## Dopracowanie

Teraz, gdy dowiedzieliśmy się o problemach, z którymi borykali się nasi przyjaciele, możemy przejść do kwestii technicznych. Jak wiemy, zespół zwrócił swoje umysły i możliwości w kierunku tak zwanego dostrajania. W stale ewoluującym krajobrazie sztucznej inteligencji, dostrajanie pojawiło się jako kluczowa technika zwiększania możliwości wstępnie wytrenowanych modeli. Dostrajanie to proces, który pozwala nam dostosować te modele do wykonywania określonych zadań z większą dokładnością i trafnością.
![Hackyeah](https://aexol-cms.fra1.cdn.digitaloceanspaces.com/aexolcom/media/hackyeah5-1730907405673.webp)
Zanim zagłębimy się w zawiłości dostrajania, konieczne jest zrozumienie koncepcji wstępnie wytrenowanych modeli. Modele te to systemy sztucznej inteligencji, które zostały przeszkolone na ogromnych ilościach danych, zazwyczaj z Internetu, w celu poznania wzorców i struktur języka naturalnego lub obrazów. Dobrze znanym przykładem wstępnie wytrenowanego modelu jest seria GPT (Generative Pre-trained Transformer) firmy OpenAI do przetwarzania języka naturalnego, która obejmuje GPT-3.5, podstawę tej sztucznej inteligencji.

Wstępnie wytrenowane modele są przeznaczone do wykonywania szerokiego zakresu zadań, od generowania tekstu po tłumaczenie językowe, analizę nastrojów i nie tylko. Mogą one jednak nie być optymalne dla konkretnych, specyficznych dla domeny lub drobnoziarnistych zadań. W tym miejscu do gry wkracza dostrajanie.

Dostrajanie jest podobne do procesu "specjalizacji" wstępnie wytrenowanych modeli. Jest to proces przyjmowania ogólnego przeznaczenia, wstępnie wytrenowanego modelu i dostosowywania go tak, aby wyróżniał się w określonym zadaniu lub domenie. Można to porównać do nadania uniwersalnemu narzędziu zaostrzonej krawędzi do konkretnego zadania. Zamiast zaczynać od zera i trenować zupełnie nowy model, dostrajanie wykorzystuje istniejącą wiedzę wstępnie wytrenowanego modelu, oszczędzając czas, zasoby obliczeniowe i dane. W świecie sztucznej inteligencji dostrajanie stało się krytyczną techniką zwiększania możliwości wstępnie wytrenowanych modeli. Wypełnia ona lukę między ogólną sztuczną inteligencją a sztuczną inteligencją specyficzną dla zadania, oferując wydajny i skuteczny sposób dostosowywania modeli do konkretnych potrzeb. Ponieważ sztuczna inteligencja nadal odgrywa kluczową rolę w różnych dziedzinach, nie można przecenić znaczenia dostrajania, ponieważ pozwala nam uwolnić pełny potencjał tych potężnych systemów sztucznej inteligencji.![Hackyeah](https://aexol-cms.fra1.cdn.digitaloceanspaces.com/aexolcom/media/hackyeah6-1730907465865.webp)

## Gratulacje

Chciałbym serdecznie pogratulować naszemu zespołowi zdobycia prestiżowej nagrody i osiągnięcia powszechnego uznania dla ich wysiłków. Mam nadzieję, że ich projekt wniesie znaczący wkład w polski sektor edukacji poprzez wykorzystanie najnowszych technologii, w tym sztucznej inteligencji. Integracja sztucznej inteligencji z procesami edukacyjnymi ma ogromny potencjał, aby znacznie poprawić jakość i dostępność edukacji.

Dzięki waszym wysiłkom zobaczyliśmy, jak uczniowie mogą mieć możliwość korzystania ze sztucznej inteligencji w angażujący i skuteczny sposób, przygotowując się na przyszłość, w której technologia odgrywa coraz ważniejszą rolę. Zdobycie zasłużonego 3. miejsca w naszym pierwszym starcie w tak dużym wydarzeniu jest wyrazem uznania dla ciężkiej pracy i zaangażowania. Stanowi również zachętę do udziału w podobnych wydarzeniach w przyszłości dla wszystkich w Aexol. Więc jeszcze raz: gratulacje!

Nasz zespół zajął 3. miejsce, prezentując aplikację opartą na sztucznej inteligencji, której celem są innowacje edukacyjne i wzmocnienie pozycji przyszłych pokoleń.

Aexol błyszczy na największym hackathonie w Europie - HackYeah 2023!

Jeśli interesujesz się Drum and Bass lub UK Dance music, istnieje całkiem spora szansa, że słyszałeś o Dj Fresh albo przynajmniej słyszałeś jego hity na YouTube (gdzie ma prawie 240 milionów wyświetleń i niemal 400 tys. subskrybentów), w radiu czy w klubach. Jeśli zastanawiasz się, dlaczego o tym piszę tutaj (bo to przecież nie jest blog o muzyce), zdecydowanie powinieneś sprawdzić, nad czym ostatnio pracował autor przeboju Gold Dust.

2022 był przełomowym rokiem dla sztucznej inteligencji — AI-generowane obrazy z Midjourney czy Dall-E mini przez jakiś czas były prawdziwym hitem. Dzięki prostemu interfejsowi tekst-na-obraz, praktycznie każdy mógł się pobawić tą technologią. Choć przyznaję, że zabawa w generowanie obrazków z papieżem jadącym na dinozaurze była ciekawa, daleko większe możliwości otwierają się w profesjonalnych zastosowaniach. Jako copywriter, bardzo często potrzebuję zdjęć do blogpostów i treści na strony, i zwykle po prostu muszę czekać, aż grafik coś przygotuje. Słowo klucz: musiałem — bo tu właśnie na scenę wkracza FastQL.

## FastQL

Dzięki FastQL możesz błyskawicznie prototypować i publikować GraphQL API wokół modeli, takich jak AI-generowane obrazy z Midjourney, Stable Diffusion, RunwayML (albo czymś mniej kontrowersyjnym, jak Huggingface Mitsua Diffusion, uczonym jedynie na publicznych i wolnych od praw autorskich danych). Brzmi świetnie już dla kogoś, kto nie programuje, ale zgodnie z nazwą — tu liczy się szybkość. Kluczowe są tutaj silnie typowane języki podnoszące wydajność:

* **GraphQL**: umożliwia pobieranie danych jednym wywołaniem API, eliminuje over-fetching i zapewnia bezpieczeństwo typów.
* **Rust**: to język niskopoziomowy skupiony na wydajności. Dlatego właśnie, pod maską, FastQL używa bardzo szybkiego serwera ActiX napisanego w Rust, co pozwala na czas odpowiedzi rzędu 20ms.

## Przykład użycia

Jeszcze bardziej imponujące jest to, jak to faktycznie działa. Jedna linijka kodu opisująca schemat graphql prowadzi do automatycznego wygenerowania wydajnego API w Rust, do którego możesz zadawać zapytania poprzez przyjazny interfejs GraphQL Playground API albo przez bezpośrednie zapytanie GraphQL — bez konieczności pisania ani linijki kodu API. Wszystko, co musisz zrobić, to wywołać API prostym zapytaniem zawierającym opis tego, co chcesz uzyskać.

```gql
{
  Model(prompt: "blog post header image with a DJ") {
    images
  }
}
```

Po tym dostaniesz odpowiedź z linkiem do wygenerowanego obrazu, którego możesz użyć (w tym przypadku jako grafikę nagłówka do bloga). Oczywiście kod to tu sprawa drugorzędna — równie łatwo można zintegrować to API z wybranym cms (np. edytorem markdown) i umożliwić użytkownikom generowanie obrazów AI na poczekaniu.

## Fine-tuning

Losowe obrazy AI są świetne w wielu przypadkach, ale z FastQL możesz je również spersonalizować za pomocą DreamBooth. W ten sposób możesz uzyskać na przykład swój własny portret na tle Tadż Mahal, na szczycie Mount Everest czy absolutnie dowolną wizję. Choć brzmi skomplikowanie, cały proces jest banalnie prosty. Najpierw przesyłasz 10-12 zdjęć (np. swoich) do folderu na Google Drive. Ustawiasz udostępnianie wszystkim posiadającym link i konfigurujesz narzędzie, podając mu ten link — wszystko przez proste zapytanie:

```gql
{
  Model(
    fine_tune_photo_description: "photos of michal"
    gdrive_folder_of_images_link: "https://drive.google.com/drive/folders/example"
  ) {
    images
  }
}
```

Po około pięciu minutach narzędzie jest gotowe generować spersonalizowane obrazy na podstawie tego samego typu opisu jak poprzednio:

```gql
{
  Model(prompt: "michal on top of Mount Everest") {
    images
  }
}
```

Jak widać, FastQL to świetne narzędzie upraszczające tworzenie API wokół modeli AI. Można je połączyć z dowolną aplikacją czy cms, umożliwiając korzystanie tam, gdzie najbardziej tego potrzebujesz — szybko i wydajnie (bez konieczności znajomości programowania). Wracając jeszcze do autora: DJ Fresh wciąż wypuszcza „hity” w 2023, choć tego rodzaju zupełnie odmienne, więc koniecznie go zaobserwuj na GitHubie i na YouTube.

Sprawdź repozytorium na [GitHub](https://github.com/happy-machine/FastQL) lub przeczytaj o tym w artykule Dana na [medium](https://medium.com/@thisisdjfresh/introducing-fastql-the-python-package-for-rapid-prototyping-and-sharing-of-machine-learning-models-54863236dbaf).

Przedstawiamy wyjątkowo szybką i niezwykle prostą w obsłudze API do pozyskiwania obrazów generowanych przez AI.

DJ Fresh prezentuje FastQL – prototypuj i publikuj API GraphQL

Podobnie jak wielu innych, przez lata pilnie śledziliśmy wyniki ankiet State of JavaScript, dlatego z ogromnym entuzjazmem przyjęliśmy ogłoszenie pierwszej w historii ankiety [State of GraphQL](https://2022.stateofgraphql.com/en-US/) w tym roku. Chociaż nasi deweloperzy świetnie znają JS, to jednak GraphQL jest naszym głównym obszarem zainteresowań, dlatego bardzo chcieliśmy zobaczyć, jakie trendy pojawiają się w jego ekosystemie. Wyniki bardzo nas zaskoczyły — nie spodziewaliśmy się, że nasz [GraphQL Editor](https://graphqleditor.com/) i [Zeus](https://github.com/graphql-editor/graphql-zeus) znajdą się w zestawieniu!

## Wysoka retencja

Ogólne zestawienie bibliotek już na początku ukazało bardzo obiecujące dane. GraphQL Editor znalazł się w czołowej dziesiątce wszystkich bibliotek pod względem retencji użytkowników. Chociaż poziom użycia był niższy, bardzo dobrze wypadł w pierwszym kwadrancie, który autorzy opisali jako technologie o niskim użyciu i wysokiej retencji, na które warto zwrócić uwagę. Oczywiście chcielibyśmy zobaczyć nasz edytor również w drugim kwadrancie (wysoka retencja i wysokie użycie), ale ten był zarezerwowany wyłącznie dla Apollo, więc traktujemy to jako doskonałą szansę na rozwój.

![user retention graph](https://aexol-cms.fra1.cdn.digitaloceanspaces.com/aexolcom/media/retention-all-1730916031561.png)

Sekcja poświęcona API Builders przyniosła jeszcze więcej optymizmu — GraphQL Editor zajął w niej 1. miejsce pod względem retencji! Jesteśmy ogromnie wdzięczni naszym użytkownikom i liczymy, że dzięki ich opiniom uda nam się utrzymać ten wynik w kolejnych edycjach ankiety.

![retention builders](https://aexol-cms.fra1.cdn.digitaloceanspaces.com/aexolcom/media/retention-builders-1730916050511.png)

## Bardzo duże zainteresowanie

Zainteresowanie również było bardzo wysokie — GraphQL Editor uplasował się w ścisłej czołówce, tuż za Hasura. To dla nas bardzo ważne, bo mimo niższej popularności i świadomości naszej marki, mamy nadzieję, że uda się zachęcić wszystkich zainteresowanych użytkowników do wypróbowania naszego narzędzia (zwłaszcza biorąc pod uwagę tak dobrą retencję).

![interest builders](https://aexol-cms.fra1.cdn.digitaloceanspaces.com/aexolcom/media/interest-builders-1730916185741.png)

## Zeus również został zauważony!

GraphQL Zeus to nasz poboczny projekt realizowany po godzinach, więc jego obecność w zestawieniu była dla nas miłą niespodzianką. Nic dziwnego, że świadomość i użycie tego narzędzia były niskie — do tej pory go nie promowaliśmy. Widzimy jednak zainteresowanie i potencjał, który w nim drzemie, więc możecie spodziewać się naprawdę ciekawych rzeczy!

![interest GraphQL Zeus](https://aexol-cms.fra1.cdn.digitaloceanspaces.com/aexolcom/media/interest-zeus-1730916203583.png)

## Wszystko dzięki Wam

Na koniec chcemy tylko podziękować całej społeczności za uznanie i zainteresowanie. Możemy obiecać, że będziemy dalej rozwijać oba te narzędzia, by uczynić je jeszcze lepszymi dla obecnych użytkowników i przyciągnąć jak najwięcej nowych, wzbudzając w pełni uzasadnione zainteresowanie. Wyniki ankiety mocno podniosły nasze morale 💪 i dały jasny kierunek działania. Chcemy naprawdę zaskoczyć społeczność GraphQL w kolejnej edycji! 🚀

Pełne wyniki ankiety znajdziecie [tutaj](https://2022.stateofgraphql.com/en-US/)

Zarówno GraphQL Editor, jak i GraphQL Zeus otrzymały entuzjastyczne opinie w ankiecie State of GraphQL.

GraphQL Editor doceniony w ankiecie State of GraphQL

Jedną z rzeczy, których większość programistów nie lubi robić, jest pisanie dokumentacji. Jest to na ogół postrzegane jako monotonne zadanie, do którego jesteśmy zmuszani, taki rodzaj obowiązku w procesie tworzenia oprogramowania. Często wydaje się to stratą czasu, który mógłby zostać przeznaczony na kodowanie czegoś nowego dla Twojej aplikacji webowej lub innego projektu. Zamiast tego trzeba wykorzystać ten czas, żeby wyjaśnić kod innym. Jednak mimo wszystko wszyscy to robią, bo to w zasadzie brama do Twojego projektu dla innych osób. Zazwyczaj warto więc poświęcić trochę czasu na stworzenie dokumentacji, aby ułatwić pracę tym, którzy mogą być zainteresowani tym, nad czym pracujesz.

## To nie strata czasu

Dobrze napisana i szczegółowa dokumentacja może być naprawdę dużym atutem, dlatego technologiczni giganci tacy jak Google czy Facebook dbają o nią w projektach, którymi się opiekują. Jeśli szukasz inspiracji, możesz sprawdzić dokumentację Django jako przykład szczególnie dobrze zrobionej dokumentacji. Nawet jeśli teraz nie przepadasz za pisaniem dokumentacji, może ona oszczędzić Ci wielu problemów w przyszłości, gdy będziesz chciał zainteresować innych swoją aplikacją webową, biblioteką, frameworkiem czy czymkolwiek, nad czym aktualnie pracujesz. Choć niektórzy uważają dokumentację za nieistotną, w rzeczywistości odgrywa ona dużą rolę, zwłaszcza w przypadku rzeczy o wysokim progu wejścia albo dużej złożoności. W przypadku różnych narzędzi dokumentacja może decydować o ich sukcesie lub porażce, bo w rozwoju aplikacji większość devów woli zaczynać z jasnym obrazem sytuacji, zamiast wszystko rozpracowywać na własną rękę. Najlepiej też zacząć pisać dokumentację stopniowo, tak aby rosła wraz z Twoim projektem. W przeciwnym razie możesz skończyć z ogromem pracy do zrobienia w przyszłości, dokumentując wszystko od zera dla projektu, który już znacząco się rozrósł.

## Magidoc

Na szczęście są narzędzia, które mogą pomóc w tworzeniu dokumentacji. Oczywiście nie zrobią za Ciebie dosłownie wszystkiego (przynajmniej jeszcze nie), ale jeśli priorytetem jest wykonanie pracy jak najszybciej, każde narzędzie przyspieszające ten proces to ogromne ułatwienie. Jednym z takich narzędzi jest Magidoc — statyczny generator dokumentacji stworzony do GraphQL API, napisany w Svelte. Jako że zależy nam na jak najszybszym uporaniu się z dokumentacją, przejdźmy po prostu do funkcji:

* **szybko i prosto**: Magidoc działa od razu po instalacji i potrafi wygenerować dokumentację dla każdego zapytania, typu, subskrypcji i mutacji w Twoim GraphQL API, wykorzystując Twój schemat lub żywy endpoint przez zapytanie introspekcyjne.
* **łatwo konfigurowalny**: Magidoc korzysta z prostego pliku konfiguracyjnego w JavaScript, dzięki czemu możesz dostosowywać go wedle uznania.
* **wsparcie dla markdown**: Magidoc obsługuje markdown, więc formatowanie dokumentacji jest tak łatwe, jak pisanie posta na forum. Obsługuje też zaawansowane funkcje markdown — jeśli potrzebujesz tabel czy osadzonego HTML, również dasz radę.
* **przydatne wtyczki**: Magidoc oferuje wrapper Svelte dla PrismJS oraz parser markdown, który renderuje komponenty Svelte i wspiera [GitHub Flavored Markdown](https://github.github.com/gfm/) dla osób chcących nieco urozmaicić swoją dokumentację.

## Doceniaj pomoc

Jak widać, podejście jest szybkie i konkretne — używasz domyślnych ustawień i otrzymujesz podstawową dokumentację, która przedstawia, czym jest Twoje API, a następnie możesz pracować nad konfiguracją i markdownem, by dodać więcej szczegółów i poprawić wygląd całości. Ile czasu na to poświęcisz — to już zależy od Ciebie. Jedni będą w zupełności zadowoleni z podstawowej dokumentacji i cieszyć się, że już mają to z głowy; inni będą chcieli jeszcze trochę podłubać. Kluczowa sprawa to sprawić, by pisanie dokumentacji było mniej uciążliwym zadaniem — co Magidoc zdecydowanie ułatwia. To zresztą narzędzie mające zaledwie kilka miesięcy i ciągle się rozwija, więc można spodziewać się nowych funkcji w przyszłości. Jeśli jednak nie interesują Cię rozbudowane opcje, już teraz Magidoc zapewnia sporo rzeczy od razu po instalacji, więc jeśli po prostu chcesz szybko zakończyć temat dokumentacji, to narzędzie pomoże Ci wystartować ekspresowo.

Nikt nie lubi pisać dokumentacji. Na szczęście Magidoc to nowe narzędzie, które ułatwia tworzenie statycznej dokumentacji dla Twojego API GraphQL.

Magidoc: szybkie i proste generowanie dokumentacji dla Twojego API GraphQL

Rozwój oprogramowania staje się coraz bardziej popularny w ostatnich latach i jeśli szukasz developerów, prędzej czy później najprawdopodobniej zaczniesz rozglądać się poza granicami swojego kraju. Szczególnie dotyczy to takich technologii jak React, które są powszechnie używane i znalezienie developerów nie stanowi problemu. Zanim zdecydujesz się na outsourcing projektu, warto jednak przemyśleć, z jakiego regionu ma pochodzić taka firma. Oczywiste aspekty, takie jak koszty czy strefa czasowa, są zwykle brane pod uwagę, ale naprawdę warto bardziej zgłębić temat i poznać lepiej rynek, na który zamierzasz wejść. Jednym z takich rynków, którym możemy przyjrzeć się bliżej, jest środkowa Europa, a dokładniej Polska.

## Taniej = gorzej?

Jeśli nie wiesz nic o Polsce albo o tym, jak wygląda rozwój oprogramowania w tym kraju – w porządku. Być może słyszałeś o CD Projekt albo 11 bit studios, jeśli interesujesz się grami, ale prawdopodobnie na tym kończy się Twoja wiedza o polskim IT. Częsty stereotyp głosi, że polskie software house’y liczą sobie mniej, bo mają niższe kompetencje od firm z innych krajów. Jeśli jednak zagłębisz się w temat, przekonasz się, że to nieprawda. HackerRank sprawdził umiejętności developerów z 50 krajów i Polska zajęła mocne, trzecie miejsce, szczególnie wyróżniając się w zadaniach z Java. Raporty Pentalog pokazują podobny obraz – Polska uplasowała się na 4. miejscu w 2019 roku i na 7. w tym roku, będąc jedynym krajem, który utrzymał się w pierwszej dziesiątce w obu rankingach. Raporty podkreślają również, że każdy kraj powyżej 30. miejsca w HackerRank albo powyżej 20. w Pentalog można uznać za znakomity. Z drugiej strony, nie oszukujmy się – cena jest dużą zaletą, a fakt, że będzie znacznie niższa niż w Europie Zachodniej czy USA, mocno kusi.

## Spóźniony start?

Może to brzmieć zaskakująco, bo Polska i inne kraje Europy Środkowo-Wschodniej były dość spóźnione, jeśli chodzi o IT oraz programowanie. Wydawać by się mogło, że państwa Europy Zachodniej powinny być wyżej w rankingach. Raporty Pentalog wskazują jednak na kilka powodów, dlaczego tak nie jest. Developerzy z „starych krajów IT”, takich jak Europa Zachodnia, często wywodzą się ze starszych technologii i pracują według dawnych metod. Developerzy z krajów bez dużej historii IT zaczynali „od zera”, ucząc się wyłącznie najnowszych narzędzi, technologii i praktyk. To duży atut, bo każdy w IT wie, że developerzy niechętnie adaptują się do nowych trendów i najczęściej wolą pozostać przy tym, co działało do tej pory. Nic więc dziwnego, że osoby zaczynające od nowoczesnych technologii mają przewagę nad tymi, którzy z czasem dopiero musieli się przestawić na nowe narzędzia i praktyki.

## Czy ktoś tutaj mówi po angielsku?

Organizacja spotkań także nie powinna być problemem – Warszawa jest w tej samej strefie czasowej co Paryż, Madryt czy Berlin, a dziewięciogodzinna różnica między zachodnim wybrzeżem USA a Europą faktycznie wymaga czasem „dogadania się”, ale to jest do ogarnięcia. Większym nieporozumieniem jest bariera językowa, bo wiele osób kojarzy Polskę ze słabą albo żadną znajomością angielskiego. O ile 20 lat temu mogło być w tym trochę prawdy, to sytuacja zmieniła się radykalnie, bo angielski jest obowiązkowy w szkołach od 1989 roku. EF English Proficiency Index od lat plasuje Polskę wśród około 15 krajów na świecie z najwyższymi kompetencjami językowymi, zaliczając ją do grupy „wysoka biegłość”. Oczywiście Polska to nie kraj ekspertów od języka angielskiego, ale pod względem komunikacji biznesowej możesz być spokojny – wszystko będzie w porządku.

## Więcej za mniej

Podsumowując, Polska bardzo dynamicznie rozwija się w sektorze software development, a zarobki developerów już wyprzedzają większość krajów regionu – poza Czechami i oczywiście Niemcami. Ceny wciąż są znacznie niższe niż w USA czy Europie Zachodniej, przy umiejętnościach developerów na tym samym poziomie, a bywa, że nawet wyższym. Jeśli więc szukasz odpowiedniej równowagi między jakością a opłacalnością, Polska to „sweet spot”: nie jest drogo, ale nie idzie to w parze z niższą jakością. Ostatecznie cena to tylko jeden z czynników, a choć naturalnie chcesz wydać jak najmniej, to najważniejsze, by dokładnie dostać to, czego oczekujesz.

Przyjrzymy się rozwojowi oprogramowania w Polsce oraz kilku powszechnym mitom na ten temat.

Wszystko, co warto wiedzieć o tworzeniu oprogramowania w Polsce

Zarządzanie stanem w React, mimo że jest kluczowym aspektem tworzenia aplikacji i istnieje mnóstwo przydatnych narzędzi i bibliotek, wciąż nie zostało rozwiązane, ani nawet się do tego nie zbliżyło. Przez lata większość deweloperów pozostała przy Reduxie, ale stale rosnąca liczba nowych bibliotek do zarządzania stanem sugeruje, że jest tu jeszcze sporo miejsca na ulepszenia. React sam w sobie wprowadził dużo wsparcia, jak Context API czy Hooks. Choć początkowo wielu uznało to za „koniec” Reduxa, rzeczywistość okazała się zupełnie inna – Redux nadal pozostaje najpowszechniej używanym narzędziem do zarządzania stanem.

## Wszyscy używają Redux

Redux był wielokrotnie krytykowany, a mimo to pozostaje najczęściej wykorzystywanym narzędziem do zarządzania stanem od czasu, gdy wyszedł zwycięsko z tzw. wojen fluxowych – okresu, kiedy różne biblioteki oparte na architekturze Flux Facebooka rywalizowały o miano najlepszego rozwiązania do zarządzania stanem w React. To właśnie Redux przyćmił inne biblioteki. Z biegiem lat jednak pojawiło się wiele skarg, głównie dotyczących ilości boilerplate’u i problemów z wydajnością – Redux nie był tworzony z myślą o szybkości czy prostocie, lecz o przewidywalności, czyli ułatwieniu śledzenia aktualizacji stanu.

W rzeczywistości wiele zarzutów wynika z jego powszechnego zastosowania, prowadzącego do nadużyć. Ponieważ Redux skupia się na łatwym śledzeniu zmian stanu, nie każda aplikacja go potrzebuje (a czasami lepszym wyborem byłaby inna biblioteka). Dodatkowo, przez podejście „single source of truth”, często wszystko trafia do Reduxa, co wcale nie jest optymalnym rozwiązaniem. Jako że Redux stał się domyślną opcją dla zarządzania stanem, jesteśmy niejako zmuszeni z niego korzystać, a to wiąże się z krzywą uczenia się i pewnymi problemami, które nie każdemu odpowiadają, zwłaszcza osobom przyzwyczajonym do programowania obiektowego.

## Jak Unstated Next wypada lepiej?

Niektóre nowsze biblioteki postanowiły w pełni wykorzystać nowe możliwości oferowane przez React. Jedną z nich jest Unstated Next, stworzona praktycznie na bazie React Context API. To duchowy następca Unstated, skupiający się przede wszystkim na zachowaniu maksymalnej prostoty i lekkości. Jak to osiąga? Po prostu wykorzystuje React i dostępne w nim narzędzia (Hooks, Context) do maksimum, dodając jednocześnie przydatne Containery. Są one jak komponenty, ale służą tylko do przechowywania stanu. Wystarczy umieścić kawałek stanu w Containerze, inne komponenty mogą subskrybować jego zmiany, a każda modyfikacja stanu powoduje rerender komponentów korzystających z tego Container'a. Porównajmy to z Reduxem:

* **mniejszy i szybszy**: Unstated Next w zasadzie opiera się na wbudowanych funkcjonalnościach Reacta i komponentyzacji wszystkiego, co sprawia, że jest wielokrotnie mniejszy i znacząco szybszy niż Redux.
* **o wiele prostszy**: Prawie nie ma tu krzywej uczenia – jeśli znasz `useState`, `useContext` i własne Hooki (a jeśli używasz React, to raczej umiesz ich używać), opanowanie Unstated Next zajmie ci najwyżej 5 minut. Dodatkowo Containery jeszcze bardziej wszystko upraszczają.
* **napisany w Typescript**: wsparcie dla TypeScript out-of-the-box oznacza sprawdzanie typów i mniej potrzeby testowania
* **oparty na containerach**: To oznacza mniej boilerplate’u i po prostu poleganie na Context API pod spodem. Pozwala też dowolnie łączyć się z każdą biblioteką reactową po jednym komponencie na raz.

## Nadużycie nie jest dobrym pomysłem

Wielu spodziewało się, że dodatki w postaci Hooków sprawią, że Redux stanie się przestarzały (albo po prostu z niecierpliwością czekało, by się go pozbyć). Pomysł był taki, że Hooki `useContext` i `useReducer` zostaną wykorzystane do zarządzania stanem zamiast globalnego kontenera stanu, jakim jest Redux. Tak się jednak nie stało i Redux pozostaje głównym graczem w zarządzaniu stanem. Co więcej, doczekał się teraz własnego Hook API, korzystając z tego, co wprowadził React. Mimo licznych krytyk wymienionych wyżej, Redux nie jest zły, jest po prostu nadużywany i zbyt mocno na nim polegamy z powodu jego długotrwałej dominacji. Zamiast narzekać na konieczność korzystania z Reduxa, powinniśmy raczej skupić się na tym, kiedy warto sięgnąć po alternatywy, jak Unstated Next, które mogą lepiej pasować do danego projektu. Ekosystem zarządzania stanem w React stale się zmienia, więc nie musimy porzucać jednego rozwiązania na rzecz drugiego. Możemy dalej opierać się na Reduxie, gdy jest to potrzebne, a w innych przypadkach próbować nowszych narzędzi, które mogą być lepsze w konkretnych sytuacjach. Dodatkowo, choć Hooki nie uczyniły Reduxa przestarzałym, zawsze może pojawić się coś nowego, więc warto mieć na to oko!

Przyjrzymy się, dlaczego ciągłe korzystanie z Redux nie zawsze jest najlepszym rozwiązaniem.

Unstated Next czy Redux – co lepsze do zarządzania stanem w React?

Zarządzanie stanem to trochę czarny charakter, jeśli chodzi o Reacta — zapytaj tych, którzy nie chcą się w to zagłębiać, a prawdopodobnie właśnie to Ci powiedzą. Zarządzanie stanem rzeczywiście staje się coraz bardziej pracochłonne wraz z rozwojem aplikacji i często potrzebujesz do tego specjalnych bibliotek. To właśnie odstrasza wielu ludzi, bo większość deweloperów, którzy mieli styczność z Reactem, ma swoją top 5 bibliotek do zarządzania stanem, jeśli nie top 10. Albo po prostu zostali przy Reduxie i nigdy nie szukali innych opcji.

Redux to najpopularniejsza biblioteka do zarządzania stanem, ale z pewnością nie jedyna, a część z nich bazuje jedna na drugiej, jak Rematch na Reduxie, co sprawia, że trudno się dziwić, iż wszystko to jest sporym zniechęceniem dla osób chcących zacząć pracę z Reactem. Cały temat wydaje się skomplikowany, wymagający sporo nauki, żeby znaleźć właściwe rozwiązanie, a nawet wtedy możesz mieć do czynienia z dużą ilością kodu powtarzalnego lub musisz sięgać po jeszcze bardziej zaawansowaną bibliotekę, zbudowaną na tej, której używałeś. To powoduje często spotykane przekonanie, że zarządzanie stanem w React jest uciążliwe — albo trzymasz się najczęściej używanego narzędzia (które i tak jest szeroko krytykowane w społeczności), albo wchodzisz w niekończący się cykl szukania najświeższej biblioteki z dodatkowymi funkcjami i możliwościami. Jeśli brzmi to jak kłopot, na szczęście istnieje znacznie prostsza biblioteka, która może być właśnie tym, czego szukasz.

![Unstated](https://aexol-cms.fra1.cdn.digitaloceanspaces.com/aexolcom/media/unstated-logo-1730917901466.png)

## Unstated

W React stan domyślnie żyje w komponentach, co czyni go przewidywalnym, przejrzystym i łatwym do obsługi lub testowania. Nawet jeśli nie znasz Reacta, krótki rzut oka na te komponenty zazwyczaj wystarczy, by zrozumieć, do czego służą. Kontynuując tę ideę wszystko, w tym stan, jest przekazywane przez Context — przekazujesz stan do komponentu Provider, a komponent Consumer go odbiera. To proste i efektywne rozwiązanie, bo stan nie musi przechodzić przez całe drzewo komponentów i trafia dokładnie tam, gdzie chcesz. Brzmi świetnie, ale co jeśli chcesz dzielić stan między wieloma komponentami? Właśnie tutaj z pomocą przychodzi Unstated — chodzi o połączenie Component State i Context, jednocześnie zachowując prostotę. To naprawdę mała biblioteka składająca się z trzech rzeczy:

* **Containers**: to klasa, która jest właściwie jak komponenty, ale służy wyłącznie do przechowywania stanu. Wystarczy przekleić swój stan do Container i komponenty mogą się do niego subskrybować.
* **Subscribers**: komponenty, które służą do przekazywania stanu do tych komponentów, które go potrzebują. Każda zmiana stanu w Container automatycznie wywołuje ponowne renderowanie komponentów subskrybujących.
* **Providers**: komponenty, które przechowują wszystkie instancje Twoich Containerów i pozwalają dzieciom na subskrypcję. Umieszczasz je na najwyższym poziomie wokół komponentów, które mają subskrybować dany Container.

## Unstated-next

Jak widać, Unstated był świetnym narzędziem, które pozwalało szybko i prosto dzielić logikę i stan — coś, czego React długo nie miał. Tymczasem React wprowadził później Hooks, które praktycznie wypełniły niszę, jaką zajmował Unstated, i szczerze mówiąc, sprawiły, że stał się trochę zbędny. Twórca Unstated, Jamie Kyle, zdał sobie z tego sprawę, ale zauważył też inną niszę — tak narodził się pomysł na Unstated-next. Problem polegał na tym, że wielu deweloperów nie wiedziało, jak używać Hooks do dzielenia stanu i logiki, więc celem było stworzenie duchowego następcy Unstated, który pomoże zrozumieć współdzielenie stanu i logiki w React, bazując na tej samej koncepcji.

* **keep it simple**: Unstated-next zachęca do pełnego wykorzystania React Hooks i Context, stosując ten sam system containerów co Unstated
* **keep it small**: około 200 bajtów i tylko kilka minut, by zrozumieć bibliotekę — to naprawdę miniatura w świecie bibliotek
* **componentize everything**: zamknięcie wszystkiego w komponentach znakomicie wpływa na wydajność i testowanie, a integracja z dowolną inną biblioteką React będzie płynna, bo możesz to robić komponent po komponencie

## Wszystko kręci się wokół React

Kluczową sprawą w Unstated jest to, że motywuje do korzystania po prostu z Reacta, a jednocześnie oferuje sprytne rozwiązania jak Container do użycia wtedy, gdy zajdzie taka potrzeba. Odpowiednie użycie razem z Hooks i Context, które same w sobie są potężnymi narzędziami, zdecydowanie ułatwia zarzadzanie stanem bez konieczności uczenia się bardziej skomplikowanych bibliotek lub zmagania się z dużą ilością boilerplate'u. Oczywiście są sytuacje, kiedy potrzebny jest bardziej rozbudowany tool i minimalistyczne podejście Unstated-next nie wystarczy, ale jeśli dopiero zaczynasz z Reactem albo po prostu chcesz, aby zarządzanie stanem było proste i przyjemne — zdecydowanie warto po niego sięgnąć.

Przyjrzymy się, jak Unstated-next może ułatwić zarządzanie stanem w React.

Unstated: lekka i prosta biblioteka do zarządzania stanem w React

Modularność i możliwość ponownego wykorzystania to jedne z głównych zasad Reacta. Komponenty React to niezależne i wielokrotnego użytku fragmenty kodu, odpowiedzialne za jedno, konkretne zadanie. Dzięki temu podejściu kod pozostaje przejrzysty i elegancki. **Rerousel** to najprostszy i najlżejszy pakiet komponentu nieskończonej karuzeli stworzony dla Reacta, mający na celu pokazanie, że Twoja aplikacja przestrzega tych właśnie zasad:

* **Prosty** – Konfiguracja karuzeli jest bardzo łatwa: wystarczy zainstalować pakiet, zaimportować Rerousel i ustawienie komponentu jest bezwysiłkowe,
* **Lekki** – Rerousel to najlżejsza działająca karuzela React JS typu infinite dostępna do pobrania z NPM. Korzysta tylko z niezbędnych pakietów, więc nie musisz się martwić o tysiące zbędnych zależności, które zaśmiecą Twoją aplikację,
* **Wszechstronny** – Nie ma znaczenia, czy tworzysz aplikację eCommerce dla firm i chcesz zaprezentować swoje produkty, czy to Twój prywatny projekt do pokazywania zdjęć z wakacji – Rerousel jest dla Ciebie. Obsługuje wszystkie typy elementów JSX, więc nie musisz martwić się o kompatybilność.

## Jak tego używać

Zainstaluj pakiet przy pomocy npm:

```bash
    npm install rerousel
```

Następnie zaimportuj Rerousel do swojego projektu React:

```ts
import { Rerousel } from "rerousel";
```

Umieść go w swojej aplikacji i wypełnij elementami, które chcesz zaprezentować, utwórz ref wskazujący na najzewnętrzniejszy element i przekaż go do **Rerousel** jako prop itemRef.

```ts
export const Component: React.FC<CustomersProps> = ({ customers }) => {
  const customerLogo = useRef(null);

  return (
    <Container>
      <Rerousel itemRef={customerLogo}>
        {customers.map((c) => {
          return <Img key={c.image} image={c.image} ref={customerLogo} />;
        })}
      </Rerousel>
    </Container>
  );
};
```

Voilà! Ciesz się najprostszą, najlżejszą i najbardziej niezawodną karuzelą stworzoną dla Reacta. Jeśli chcesz dowiedzieć się więcej, koniecznie zajrzyj do [repozytorium Rerousel na GitHubie](https://github.com/aexol-studio/rerousel).

Karuzele lub slidery obrazów od zawsze poprawiają atrakcyjność stron internetowych, prezentując produkty, klientów czy opinie. Przyjrzyjmy się Rerousel – najprostszej nieskończonej karuzeli dla Reacta.

Wypróbuj Rerousel – najprostszą karuzelę dla Reacta

Wkrótce minie 7 lat, odkąd Facebook wypuścił React Native w marcu 2015 roku – przez ten czas framework stał się niezwykle popularny na wszystkich platformach. Dziś to wciąż jeden z najczęściej używanych frameworków mobilnych, a jak podaje Statista, zaledwie niedawno oddał pierwsze miejsce Flutterowi. Choć więc nie jest obecnie „najgorętszą” technologią, React Native wciąż rośnie w siłę i na pewno warto zobaczyć, co nowego szykuje się w 2022 roku, zwłaszcza że obiecałem to już we wcześniejszym wpisie na blogu.

## Execute order 0.66

W sierpniu zespół stojący za React Native opublikował wpis na blogu, w którym nakreślił roadmapę na drugą połowę 2021 roku i przekazał wiele zachęcających wieści. Nie tylko zespół się powiększał, ale również aktualizacje miały być bardziej stabilne i znacznie częstsze dzięki zmianie podejścia do rozwoju React Native. Niedługo później, bo już w październiku, zobaczyliśmy premierę długo oczekiwanej dużej wersji 0.66. Oprócz typowych poprawek i aktualizacji kompatybilności do najnowszych wersji systemów operacyjnych (Android 12 i iOS 15 odpowiednio), przyniosła ona także kilka ciekawych nowości. Podsumowując najważniejsze z nich:

* **wsparcie dla children renderowanych poza granicami widoku rodzica** — długo wyczekiwana funkcja poprawiająca wygodę, która przybliża React Native do standardów web dev,
* **wsparcie nowych uprawnień Bluetooth wprowadzonych w Android 12** — m.in. daje możliwość wyszukiwania innych urządzeń Bluetooth, umożliwia uczynienie obecnego urządzenia widocznym dla innych oraz komunikację pomiędzy sparowanymi urządzeniami,
* **lepsze wsparcie dla Apple Silicon** — razem z lepszą integracją z Xcode 13 i iOS 15, skupienie na nowych paskach QuickTime i nawigacyjnych w iOS oraz aktualizacje uprawnień i efekt overscroll w Android 12,
* **Hermes 0.9.0** — open-source’owy silnik zoptymalizowany pod React Native, skoncentrowany na wydajności (lepszy czas uruchamiania, mniejsze zużycie pamięci, mniejszy rozmiar aplikacji). Około 400 commitów, a celem tej aktualizacji było zniwelowanie różnic między wersją Hermes a React Native 0.66 oraz zapewnienie ich bezproblemowej współpracy,
* **wsparcie dla React 17** — wystarczy rzut oka na [changelog](https://reactjs.org/blog/2020/10/20/react-v17.html#changelog), by przekonać się, że to spora sprawa i spokojnie mogłaby być tematem oddzielnego wpisu!

## Dotrzymane obietnice

Aktualizacje pojawiają się coraz częściej, a 0.66 to już trzecia wersja wydana w 2021 roku. Dla potwierdzenia tego faktu: wersja 0.67 wyszła właśnie w trakcie pisania tego artykułu. Mimo że to mniejsza aktualizacja, to miała niemal 400 commitów oraz kilka kluczowych nowości: usunięcia Lean-core i aktualizacje wsparcia dla Kotlin 1.5.31 i Gradle 7.2. Można więc śmiało powiedzieć, że zespół stojący za React Native dotrzymuje swoich obietnic. W 2022 roku powinniśmy doczekać się kolejnych aktualizacji — już na horyzoncie są zmiany w Native Modules i projekt Facebooka Fabric.

## Zdrowa konkurencja

Czasy dla React Native zapowiadają się naprawdę ciekawie. Wygląda na to, że zespół zauważył, iż inne frameworki – jak Flutter – doganiają ich i postanowił podkręcić tempo. Bez wątpienia to jeden z największych frameworków i zapewne pozostanie nim przez długi czas, ale jak widać po tempie aktualizacji, zmiana podejścia do rozwoju była naprawdę potrzebna. Chociaż te aktualizacje nie sprawią, że wszyscy nagle porzucą pozostałe frameworki, to z pewnością są one ogromnym plusem dla społeczności React Native i można stwierdzić, że przyszłość rysuje się obiecująco.

Przegląd najważniejszych aktualizacji z października i stycznia.

Co nowego w React Native – najważniejsze zmiany w wersjach 0.66 i 0.67

## Wstęp

Jestem full-stack developerem TypeScript i ostatnio dużo uczę się języka Elm. Czy zamierzam przejść na Elm? Zdecydowanie nie. Jednak proces nauki pomógł mi zrozumieć i wymagać więcej rzeczy od Reacta.

Dziś pokażę Ci antywzorzec w React, który pozwoli Ci **dzielić stan poza komponentami**. Dlaczego miałbyś to robić? Dlaczego nie użyć hooka? itd. itd. Pokażę to na przykładzie małego formularza.

**Uwaga:** To nie jest przykład „produkcyjny”. W środowisku produkcyjnym używam tego hooka do tworzenia zsynchronizowanej przeglądarki plików S3, ale na potrzeby tego artykułu byłoby to zbyt rozbudowane.

## Hook

Ta kombinacja State i Callback pozwala nam połączyć funkcję ref później i nasłuchiwać, kiedy ref się zmienia:

```ts
import { useState, useCallback } from "react";

export const useImperativeRef = <T,>() => {
  const [refState, setRefState] = useState<T>();
  const ref = useCallback((n: T | null) => {
    if (n) {
      setRefState(n);
    }
  }, []);
  return [refState, ref] as const;
};
```

## Formularz

Do tego przykładu nie potrzebujemy niczego wyszukanego, więc użyjemy prostego formularza z 2 polami:

```ts
import React, { useImperativeHandle, useState } from "react";

interface FormValues {
  username: string;
  password: string;
}

export interface MyFormHandle {
  values: FormValues;
}

export const MyForm = React.forwardRef(
  ({}, ref: React.ForwardedRef<MyFormHandle>) => {
    const [values, setValues] = useState<FormValues>({
      username: "",
      password: "",
    });
    useImperativeHandle(ref, () => ({
      values,
    }));
    return (
      <div>
        <input
          type="text"
          value={values.username}
          onChange={(e) =>
            setValues({
              ...values,
              username: e.target.value,
            })
          }
        />
        <input
          type="password"
          value={values.password}
          onChange={(e) =>
            setValues({
              ...values,
              password: e.target.value,
            })
          }
        />
      </div>
    );
  },
);
```

## Użycie formularza

Voilà! Możemy nasłuchiwać na zmiany stanu komponentów niższego poziomu:

```ts
export default () => {
  const [values, setRef] = useImperativeRef<MyFormHandle>();
  useEffect(() => {
    console.log(`Values changed!, Values: ${JSON.stringify(values, null, 4)}`);
  }, [values]);
  return (
    <div>
      <MyForm ref={setRef} />
    </div>
  );
};
```

Oczywiście możemy przekazywać funkcje zmieniające i wartości, ale bądźmy szczerzy — to jest Yuck! Moim zdaniem ten sposób jest w wielu przypadkach dużo bardziej elegancki i pozbawiony zbędnego kodu.

Jak useImperativeHandle, useCallback i useState współpracują ze sobą w React.

Magia `useImperativeHandle` w React oczami fullstack developera

Blogposty

GraphQL Best Practices: Gain hands-on experience with schema design, security, and error handling

E-booki

Open Source

Axolotl is a framework overlord/wrapper thats lets you forget about type-casting and looking into schemas. When there is no drama, only efficiency remains

Axolotl

Translate i18 JSON files automatically with best translating engine in the world without losing format.

DevTranslate

Tree is a simple, yet highly efficient tool for visualizing node-based systems, with only one dependency.

Tree

Based on your graphql schema Zeus generates TypeScript types and strongly-typed clients, maximizing the power, efficiency, productivity, and safety of TypeScript in your GraphQL requests.

Newsy ze świata technologii, narzędzia dla deweloperów i wiele więcej

Usługi

AEXOL™ Stack

Branże

Zasoby