Smart Home & IoT w przestrzeniach: Jak skonfigurować zestaw do słuchania muzyki z adapteru na pasywnych głośnikach?

Chciałem słuchać muzyki z adapteru i gramofonu na normalnych, pasywnych głośnikach. Sam adapter miał własne niewielkie głośniki, ale ich jakość oraz głośność były dalekie od tego, czego oczekiwałem.

Miałem już Raspberry Pi z systemem Volumio, nakładkę HiFiBerry Amp2 oraz parę pasywnych głośników. Początkowo wydawało się więc, że wystarczy podłączyć adapter do Raspberry Pi, a następnie skierować dźwięk do HiFiBerry.

Problem polegał na tym, że HiFiBerry Amp2 jest wyłącznie urządzeniem wyjściowym. Odbiera cyfrowy dźwięk z Raspberry Pi, wzmacnia go i wysyła do głośników, ale nie ma analogowego wejścia RCA, do którego można bezpośrednio podłączyć adapter lub gramofon.

Rozwiązaniem okazał się zewnętrzny interfejs audio USB Behringer UCA202.

Finalnie powstał zestaw, który może działać w dwóch trybach: jako streamer Volumio oraz jako cyfrowy most pomiędzy adapterem, gramofonem i pasywnymi głośnikami.

Co chciałem osiągnąć?

Docelowy system miał umożliwiać:

• słuchanie muzyki z gramofonu na pasywnych głośnikach,
• wykorzystanie HiFiBerry Amp2 jako wzmacniacza,
• zachowanie Volumio jako odtwarzacza radia internetowego, Spotify i AirPlay,
• przełączanie źródła bez każdorazowego logowania przez SSH,
• sterowanie całością z prostego panelu WWW.

Architektura rozwiązania

Finalny tor sygnału wygląda następująco:

Adapter / gramofon
wyjście LINE OUT RCA
        │
        ▼
Behringer UCA202
wejście INPUT L/R
        │
        │ USB
        ▼
Raspberry Pi z Volumio
        │
        │ I2S
        ▼
HiFiBerry Amp / Amp2
        │
        │ przewody głośnikowe
        ▼
Pasywne głośniki

Raspberry Pi pełni tutaj rolę cyfrowego routera audio.

Analogowy sygnał z adapteru trafia do Behringera UCA202. Interfejs zamienia go na cyfrowe audio przesyłane przez USB. Raspberry Pi odbiera strumień za pomocą ALSA, a następnie wysyła go do HiFiBerry. HiFiBerry wzmacnia sygnał i napędza pasywne głośniki.

Najważniejszy jest podział odpowiedzialności pomiędzy urządzeniami:

• Behringer UCA202 pełni rolę wejścia audio,
• Raspberry Pi przekazuje i kontroluje strumień,
• HiFiBerry Amp2 jest wyjściem audio i wzmacniaczem.

Zaciski głośnikowe HiFiBerry nie są wejściem audio. Nie wolno podłączać do nich wyjścia RCA adapteru ani gramofonu.

Potrzebny sprzęt

Element	Rola
Adapter lub gramofon z LINE OUT	Analogowe źródło dźwięku
Behringer UCA202	Konwersja analogowego sygnału RCA na cyfrowe audio USB
Raspberry Pi	Uruchomienie Volumio, ALSA, usług systemowych i panelu sterującego
HiFiBerry Amp lub Amp2	Wyjście audio oraz wzmacniacz dla głośników pasywnych
Pasywne głośniki	Docelowe odtwarzanie dźwięku
Kabel 2 × RCA	Połączenie wyjścia LINE OUT adapteru z wejściem Behringera
Przewody głośnikowe	Połączenie HiFiBerry z lewym i prawym głośnikiem

Podłączenie sprzętu

Adapter lub gramofon do Behringera

Wyjście LINE OUT urządzenia podłączamy do wejść Behringera UCA202:

• biały RCA do kanału lewego L,
• czerwony RCA do kanału prawego R,
• przewody muszą trafić do złączy oznaczonych jako INPUT.

Następnie Behringera podłączamy przewodem USB do Raspberry Pi.

HiFiBerry do głośników

Pasywne głośniki podłączamy przewodami głośnikowymi bezpośrednio do zacisków HiFiBerry. Należy zachować poprawne przypisanie kanałów oraz polaryzację przewodów.

Przed pierwszym testem warto ustawić niski poziom głośności, a dopiero później stopniowo go zwiększać.

Konfiguracja Volumio i HiFiBerry

Po uruchomieniu Raspberry Pi panel Volumio powinien być dostępny pod adresem:

http://volumio.local

Jeżeli nazwa lokalna nie działa, należy użyć adresu IP Raspberry Pi:

http://192.z.y.z

Ten sam adres wykorzystujemy do połączenia SSH:

ssh volumio@192.z.y.z

Jeżeli SSH jest wyłączone, można je aktywować na stronie developerskiej:

http://ADRES_IP_VOLUMIO/dev

W panelu Volumio przechodzimy do:

Settings → Playback Options

Następnie ustawiamy:

• I2S DAC: ON,
• DAC Model: HiFiBerry Amp/Amp2 lub zgodny model,
• Mixer Type: Hardware, jeżeli jest dostępny,
• niski początkowy poziom głośności.

Po zapisaniu ustawień restartujemy system.

Sprawdzenie urządzeń ALSA

Przed uruchomieniem przekazywania dźwięku trzeba sprawdzić, czy system widzi wejście Behringera i wyjście HiFiBerry.

Urządzenia nagrywające wyświetlamy poleceniem:

arecord -l

Urządzenia odtwarzające:

aplay -l

W opisywanej konfiguracji urządzenia zostały wykryte jako:

Behringer UCA202:
card 5, device 0
plughw:5,0

HiFiBerry:
card 2, device 0
plughw:2,0

Składnia plughw:<card>,<device> określa numer karty i urządzenia ALSA.

Numery kart mogą zmienić się po restarcie systemu albo przepięciu urządzenia USB. Przed modyfikacją konfiguracji zawsze warto ponownie wykonać arecord -l i aplay -l.

Test HiFiBerry i głośników

Najpierw sprawdzamy sam tor wyjściowy:

amixer -c 2 sset 'Digital' 90% unmute
volumio volume 80
speaker-test -D plughw:2,0 -c 2 -t sine -f 440

Jeżeli z głośników słychać sygnał testowy, oznacza to, że:

• HiFiBerry zostało poprawnie wykryte,
• wzmacniacz działa,
• głośniki są właściwie podłączone,
• możemy przejść do testowania wejścia Behringera.

Test nagrania z adapteru lub gramofonu

Nagrywamy dziesięciosekundową próbkę:

arecord \
  -D plughw:5,0 \
  -f S16_LE \
  -r 44100 \
  -c 2 \
  -V stereo \
  -d 10 \
  /tmp/adapter.wav

Następnie odtwarzamy ją przez HiFiBerry:

aplay -D plughw:2,0 /tmp/adapter.wav

Parametr -V stereo pokazuje poziom odbieranego sygnału. Jeżeli wskaźnik reaguje podczas odtwarzania muzyki, Behringer poprawnie odbiera dźwięk.

W przypadku UCA202 program alsamixer może wyświetlić komunikat:

This sound device does not have any capture controls

Jest to normalne. Komunikat oznacza jedynie, że urządzenie nie udostępnia programowego suwaka poziomu wejścia.

Odsłuch na żywo

Po potwierdzeniu działania wejścia i wyjścia łączymy oba urządzenia prostym potokiem:

arecord \
  -D plughw:5,0 \
  -f S16_LE \
  -r 44100 \
  -c 2 \
  --buffer-time=500000 \
| aplay \
  -D plughw:2,0 \
  -f S16_LE \
  -r 44100 \
  -c 2 \
  --buffer-time=500000

arecord odbiera dźwięk z Behringera, a aplay przekazuje go do HiFiBerry.

W tym momencie muzyka z adapteru powinna być słyszalna na pasywnych głośnikach.

Usługa systemd dla wejścia audio

Ręczna komenda działa tylko do chwili zamknięcia terminala. Dlatego tworzymy usługę systemową:

sudo nano /etc/systemd/system/turntable.service

Zawartość pliku:

[Unit]
Description=Turntable line-in from Behringer UCA202 to HiFiBerry
After=sound.target
Wants=sound.target

[Service]
Type=simple
User=volumio
Group=audio
ExecStart=/bin/bash -c 'arecord -D plughw:5,0 -f S16_LE -r 44100 -c 2 --buffer-time=500000 | aplay -D plughw:2,0 -f S16_LE -r 44100 -c 2 --buffer-time=500000'
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

Przeładowujemy konfigurację:

sudo systemctl daemon-reload

Usługę uruchamiamy poleceniem:

sudo systemctl start turntable.service

Status sprawdzamy przez:

sudo systemctl status turntable.service

Konflikt pomiędzy adapterem a Volumio

Podczas działania potoku arecord | aplay proces aplay zajmuje urządzenie HiFiBerry.

Volumio próbuje korzystać z tej samej karty dźwiękowej. Może więc pojawić się błąd:

device busy

Dlatego zestaw działa w dwóch rozłącznych trybach:

Tryb	Aktywne źródło	Zatrzymane procesy
Adapter ON	Behringer → Raspberry Pi → HiFiBerry	Volumio i MPD
Volumio ON	Radio, Spotify lub AirPlay	turntable.service, arecord i aplay

Usługa wejścia audio nie powinna uruchamiać się automatycznie przy starcie:

sudo systemctl disable turntable.service

Skrypt uruchamiający adapter

sudo nano /usr/local/bin/gramofon-on

#!/bin/bash

volumio stop 2>/dev/null || true
systemctl stop mpd 2>/dev/null || true
systemctl stop turntable.service 2>/dev/null || true

pkill arecord 2>/dev/null || true
pkill aplay 2>/dev/null || true

amixer -c 2 sset 'Digital' 90% unmute 2>/dev/null || true
volumio volume 80 2>/dev/null || true

systemctl start turntable.service

exit 0

Skrypt przywracający Volumio

sudo nano /usr/local/bin/gramofon-off

#!/bin/bash

systemctl stop turntable.service 2>/dev/null || true

pkill arecord 2>/dev/null || true
pkill aplay 2>/dev/null || true

sleep 1

systemctl restart mpd 2>/dev/null || true

sleep 2

volumio vrestart 2>/dev/null \
  || systemctl restart volumio.service 2>/dev/null \
  || true

sleep 5

volumio volume 80 2>/dev/null || true

exit 0

Skrypt sprawdzający status

sudo nano /usr/local/bin/gramofon-status

#!/bin/bash

echo "=== turntable.service ==="
systemctl status turntable.service --no-pager -l || true

echo ""
echo "=== arecord / aplay ==="
ps -ef | egrep 'arecord|aplay' | grep -v grep || true

echo ""
echo "=== audio users ==="
fuser -v /dev/snd/* 2>/dev/null || true

exit 0

Ustawiamy prawa:

sudo chown root:root \
  /usr/local/bin/gramofon-on \
  /usr/local/bin/gramofon-off \
  /usr/local/bin/gramofon-status

sudo chmod 755 \
  /usr/local/bin/gramofon-on \
  /usr/local/bin/gramofon-off \
  /usr/local/bin/gramofon-status

Panel WWW do przełączania trybów

Logowanie przez SSH za każdym razem byłoby niewygodne. Dlatego powstał prosty panel WWW działający na porcie 8090.

Panel udostępnia trzy akcje:

• Gramofon ON – uruchamia wejście z Behringera,
• Gramofon OFF / Volumio ON – przywraca streaming,
• Status – pokazuje procesy korzystające z urządzeń audio.

Panel jest dostępny pod adresem:

http://ADRES_IP_VOLUMIO:8090

Przykładowo:

http://192.168.1.250:8090

Panel powinien być dostępny wyłącznie w sieci domowej. Portu 8090 nie należy wystawiać bezpośrednio do internetu.

Minimalne uprawnienia sudo

Panel działa jako użytkownik volumio, ale skrypty sterujące usługami wymagają uprawnień administratora.

Zamiast uruchamiać cały serwer Node.js jako root, nadajemy użytkownikowi możliwość wykonywania tylko konkretnych skryptów.

sudo visudo -f /etc/sudoers.d/zz_turntable_web

Dodajemy:

Cmnd_Alias TURNTABLE_CMDS = /usr/local/bin/gramofon-on, /usr/local/bin/gramofon-off, /usr/local/bin/gramofon-status
volumio ALL=(root) NOPASSWD: TURNTABLE_CMDS

Następnie:

sudo chown root:root /etc/sudoers.d/zz_turntable_web
sudo chmod 440 /etc/sudoers.d/zz_turntable_web
sudo visudo -c

Reguły testujemy poleceniami:

sudo -k
sudo -n /usr/local/bin/gramofon-status

sudo -k
sudo -n /usr/local/bin/gramofon-on

sudo -k
sudo -n /usr/local/bin/gramofon-off

Najczęstsze problemy

Volumio nie działa przez volumio.local

Należy użyć adresu IP:

ssh volumio@192.168.1.250
http://192.168.1.250
http://192.168.1.250:8090

Brak capture controls w Behringerze

W przypadku UCA202 jest to normalne. Wejście testujemy przez arecord, a nie suwaki w alsamixer.

Volumio nie gra po wyłączeniu adapteru

sudo systemctl stop turntable.service
sudo pkill arecord 2>/dev/null
sudo pkill aplay 2>/dev/null
sudo systemctl restart mpd 2>/dev/null
volumio vrestart 2>/dev/null \
  || sudo systemctl restart volumio.service

Dźwięk z adapteru jest bardzo cichy

Należy sprawdzić:

• czy używane jest wyjście LINE OUT,
• czy RCA są podłączone do wejścia INPUT Behringera,
• czy poziom wejścia reaguje w arecord -V stereo,
• czy HiFiBerry poprawnie odtwarza sygnał testowy,
• czy regulator głośności adapteru wpływa na LINE OUT.

Procesy arecord lub aplay nadal działają

ps -ef | egrep 'arecord|aplay' | grep -v grep
sudo fuser -v /dev/snd/*
sudo pkill arecord 2>/dev/null
sudo pkill aplay 2>/dev/null

Czego nauczył mnie ten projekt?

Samo przekazanie dźwięku z Behringera do HiFiBerry można uruchomić jedną komendą. To jednak nie wystarczy, jeżeli zestaw ma być wygodny w codziennym użyciu.

Trzeba dodatkowo rozwiązać kilka typowo systemowych problemów:

• wykrywanie urządzeń audio,
• zarządzanie dostępem do współdzielonej karty dźwiękowej,
• kontrolowanie procesów,
• automatyzację za pomocą systemd,
• ograniczenie uprawnień administratora,
• udostępnienie prostego interfejsu użytkownika.

Mały domowy projekt audio okazał się więc dobrym przykładem integracji sprzętu, Linuksa, usług systemowych oraz prostej aplikacji webowej.

Podsumowanie

Finalnie powstał system pozwalający korzystać z tych samych pasywnych głośników zarówno podczas słuchania muzyki z adapteru lub gramofonu, jak i podczas streamowania przez Volumio.

Tor dla źródła analogowego wygląda następująco:

Adapter lub gramofon
→ Behringer UCA202
→ Raspberry Pi
→ HiFiBerry Amp2
→ pasywne głośniki

Volumio pozostaje natomiast źródłem radia internetowego, Spotify oraz AirPlay.

Przełączanie pomiędzy źródłami odbywa się z prostego panelu WWW, bez ręcznego logowania przez SSH.

Najważniejsza rekomendacja: w autostarcie powinien działać tylko panel WWW. Usługę przekazującą dźwięk z adapteru uruchamiamy dopiero w momencie wybrania trybu gramofonu.

Requirements Traceability Matrix (RTM) – jak nie zgubić sensu biznesowego w projekcie

Masz backlog pełen punktów, a mimo to wciąż czujesz, że “nie dowozimy wartości”? Albo dostajesz 3 oferty od dostawców i każda brzmi świetnie… dopóki nie zaczniesz pytać o pokrycie Must/Should? Właśnie w takich momentach RTM robi robotę.

RTM (Requirements Traceability Matrix) to narzędzie do mapowania wymagań na procesy, pain pointy i cele biznesowe. Dzięki temu każde wymaganie ma uzasadnienie, a projekt przestaje być “listą ficzerów”, tylko staje się kontrolowanym planem rozwiązywania realnych problemów.

Co daje RTM w praktyce?

• Przejrzystość – każdy pain point ma przypisane wymaganie, KPI i kryteria akceptacji.
• Kontrola zakresu – nic ważnego nie ginie, a każdy element projektu ma uzasadnienie biznesowe.
• Ocena dostawców – porównujesz, na ile ich rozwiązania pokrywają Twoje Must/Should (a nie tylko “ładny opis”).
• Lepsze decyzje – łatwiej odróżnić “fajnie mieć” od “musimy mieć, bo inaczej KPI się nie spina”.

Kiedy RTM jest szczególnie przydatne?

• RFP/RFI i wybór dostawcy (porównanie ofert na twardych kryteriach).
• Projekty transformacyjne (wiele procesów, wielu stakeholderów, duże ryzyko scope creep).
• Regulacje/compliance (łatwiej wykazać “dlaczego to wdrażamy” i “jak to weryfikujemy”).
• Duże programy (wiele zespołów + zależności, gdzie traceability ratuje spójność).

Jak zbudować RTM krok po kroku?

1) Zbierz pain pointy (źródło: ludzie i proces)

Najlepiej działają pain pointy opisane językiem skutku, np. “czas obsługi reklamacji jest zbyt długi”, “brak widoczności statusu”, “ręczne kopiowanie danych”.

2) Dopisz cele biznesowe i KPI

Każdy pain point powinien mieć “dlaczego” oraz miarę sukcesu, np. skrócenie czasu procesu, wzrost konwersji, spadek liczby błędów, poprawa SLA.

3) Podepnij proces / obszar (gdzie to boli)

To może być proces end-to-end (“Zwroty”), etap lejka sprzedażowego (“Kwalifikacja leadów”), albo capability (“Customer Service”).

4) Zdefiniuj wymagania (co trzeba zmienić)

Wymagania mogą być w formie user stories, wymagań systemowych albo punktów specyfikacji. Ważne, żeby były jednoznaczne i testowalne.

5) Ustal priorytety Must/Should (minimum do sensownego wdrożenia)

RTM świetnie współgra z podejściem MoSCoW: Must to warunek sukcesu, Should to mocny wpływ na wartość, ale do rozważenia etapami.

6) Dodaj kryteria akceptacji (jak sprawdzimy, że działa)

Kryteria akceptacji powinny być mierzalne i możliwe do potwierdzenia na demo/UAT. Jeśli nie da się tego zweryfikować – to sygnał, że wymaganie jest zbyt ogólne.

7) Utrzymuj RTM jako “żywy” artefakt

RTM nie jest dokumentem do szuflady. To narzędzie sterowania zakresem. Każda zmiana w wymaganiach powinna mieć aktualizację mapowania (pain point → cel → KPI → wymaganie → test).

Minimalny RTM – jakie kolumny wystarczą?

Na start polecam wersję “minimalną, ale skuteczną”:

• ID (stabilne, niezmienne)
• Pain point
• Cel biznesowy
• Proces / obszar
• Wymaganie
• Priorytet (Must/Should)
• KPI
• Kryteria akceptacji

Przykład RTM (fragment)

ID	Pain point	Cel biznesowy	Proces	Wymaganie	Priorytet	KPI	Kryteria akceptacji
RTM-001	Zgłoszenia “giną” w mailach, brak statusu	Skrócić czas reakcji i poprawić transparentność	Obsługa zgłoszeń	System musi rejestrować zgłoszenie i nadawać statusy (New/In Progress/Done)	Must	SLA first response < 4h	Użytkownik widzi status; każda zmiana statusu jest logowana
RTM-002	Brak priorytetyzacji – wszystko “na wczoraj”	Zredukować chaos i poprawić obsługę krytycznych spraw	Obsługa zgłoszeń	Wymagane pola: priorytet + automatyczna eskalacja dla “Wysoki”	Should	% eskalacji obsłużonych w SLA	Dla priorytetu “Wysoki” system wysyła powiadomienie i ustawia flagę Escalated

---

RTM do oceny dostawców – prosty mechanizm scoringu

Jeśli chcesz użyć RTM do porównania ofert, dodaj kolumny typu:

• Vendor A coverage, Vendor B coverage (np. skala 0–2)
• Uwagi / ryzyka (np. “wymaga customizacji”, “w roadmapie”, “brak”)

Przykładowa skala:

• 0 – brak pokrycia
• 1 – częściowe pokrycie / obejście / duża customizacja
• 2 – pełne pokrycie out-of-the-box

Pro tip: w selekcji dostawcy często ustawiam prostą zasadę: 100% pokrycia Must (albo jasno opisany plan domknięcia luk), a dopiero potem liczę wynik dla Should.

RTM jako “bezpiecznik” na scope creep

Każda nowa propozycja w projekcie powinna przejść szybki test:

• Jaki pain point rozwiązuje?
• Jaki cel biznesowy wspiera?
• Jaki KPI poprawi?
• Jakie ma kryteria akceptacji?

Jeśli nie umiesz tego wpisać do RTM w 2–3 zdaniach, to zwykle znak, że temat jest: (a) zbyt mglisty, (b) “nice to have”, albo (c) nie jest teraz priorytetem.

Najczęstsze błędy (i jak ich uniknąć)

• RTM jako Excel-cmentarz – jeśli nikt do niego nie zagląda na refinements/steeringach, to umrze. Wprowadź zasadę: decyzje o zakresie bazują na RTM.
• Za duża szczegółowość – RTM nie musi mapować każdego subtaska. Zaczynaj od poziomu “wymaganie/feature”, dopiero potem schodź niżej.
• Brak stabilnych ID – nie zmieniaj identyfikatorów. To one spinają dokumenty, testy i ustalenia.
• Brak właściciela – każda linia RTM powinna mieć ownera (biznes/produkt), inaczej nikt nie przypilnuje sensu.

Podsumowanie

RTM to prosty sposób, żeby utrzymać projekt “na torach”: od pain pointu, przez cel i KPI, aż po wymaganie i test. Daje przejrzystość, porządkuje rozmowy ze stakeholderami, ogranicza scope creep i pozwala porównywać dostawców na twardych kryteriach Must/Should.

dev{tools}: Hoppscotch – lekkie i otwarte narzędzie do testowania API

Testowanie i dokumentowanie API to codzienność w pracy programistów, testerów czy architektów systemów. Najczęściej wybierane narzędzia w tym obszarze to Postman oraz Insomnia. Od kilku lat na rynku rozwija się jednak ciekawa alternatywa – Hoppscotch. To narzędzie open-source, które wyróżnia się prostotą, wydajnością oraz możliwością uruchomienia zarówno w chmurze, jak i on-premise.

Licencja i otwartość

Hoppscotch jest projektem open-source dostępnym na licencji MIT. To oznacza, że możemy swobodnie korzystać z narzędzia, modyfikować je i wdrażać w swoich środowiskach – bez ograniczeń licencyjnych, które często pojawiają się w przypadku komercyjnych rozwiązań. Dla organizacji dbających o transparentność i możliwość pełnej kontroli kodu źródłowego jest to duży atut.

Instalacja on-premise

W przeciwieństwie do Postmana, który w pełni lokalnie działa tylko w aplikacji desktopowej, Hoppscotch można wdrożyć we własnej infrastrukturze. Projekt oferuje gotowe obrazy Dockera oraz szczegółową dokumentację instalacyjną. Dzięki temu firmy, które nie chcą przesyłać wrażliwych danych do chmury, mogą korzystać z Hoppscotcha całkowicie w trybie on-premise.

Dzielenie się projektami i współpraca

Hoppscotch pozwala na tworzenie i zapisywanie kolekcji zapytań API, a następnie współdzielenie ich w zespole. Istnieje możliwość integracji z GitHubem czy GitLabem, co ułatwia wersjonowanie i kontrolę zmian. To podejście jest bardziej elastyczne w porównaniu do Postmana, gdzie dzielenie się kolekcjami często wymaga płatnego planu.

Najważniejsze funkcjonalności Hoppscotch

• Obsługa wielu protokołów – REST, GraphQL, WebSocket, SSE. Dzięki temu narzędzie sprawdza się nie tylko przy klasycznych API RESTowych, ale także w architekturach event-driven.
• Autoryzacja i nagłówki – wbudowane wsparcie dla różnych metod autoryzacji (Bearer, Basic, JWT), konfigurowalnych nagłówków oraz tokenów.
• Testowanie w czasie rzeczywistym – możliwość podglądu odpowiedzi serwera dla WebSocketów i SSE w trybie live.
• Tryb offline – aplikacja webowa działa również jako PWA (Progressive Web App), co pozwala korzystać z niej offline.
• Szybkie skróty klawiaturowe – projekt od początku tworzony z myślą o wydajności, dzięki czemu wiele akcji można wykonywać bez użycia myszy.
• Eksport i import kolekcji – kompatybilność z Postman Collection Format ułatwia migrację z innych narzędzi.
• Tryb prywatny – brak konieczności logowania, możliwość lokalnego przechowywania kolekcji.

Funkcje, które wyróżniają Hoppscotch

Na tle konkurencji Hoppscotch prezentuje kilka unikalnych możliwości:

• Ekstremalna lekkość i szybkość – aplikacja działa w przeglądarce i waży niewiele w porównaniu do zasobożernego Postmana.
• Open-source bez ograniczeń – pełna funkcjonalność dostępna za darmo, podczas gdy Postman czy Insomnia stosują model freemium.
• Instalacja jako PWA – aplikację można „zainstalować” z poziomu przeglądarki bez konieczności pobierania klasycznego klienta.
• Integracja z repozytoriami Git – zamiast płatnych workspace’ów można wykorzystać naturalny workflow GitOps do współdzielenia kolekcji.
• Łatwe uruchomienie on-premise – prosta konfiguracja Dockera, idealna dla zespołów dbających o prywatność danych.

Porównanie z Postmanem i Insomnia

Cecha	Hoppscotch	Postman	Insomnia
Licencja	Open Source (MIT)	Komercyjna, darmowy plan z ograniczeniami	Open Source (częściowo), model freemium
On-premise	Tak, pełna instalacja Docker/Kubernetes	Nie w pełni (desktop + ograniczone wsparcie serwerowe)	Częściowe wsparcie, głównie aplikacja lokalna
Współdzielenie projektów	Integracja z Git, otwarta współpraca	Tylko w płatnych planach (workspace)	Eksport/Import, ograniczona współpraca
Interfejs	Lekki, webowy, szybki	Rozbudowany, czasem ociężały	Prosty, minimalistyczny
Funkcje dodatkowe	WebSocket, SSE, GraphQL, REST	Bardzo bogaty ekosystem (monitory, mocki, testy)	Plugins, wsparcie GraphQL i REST

Dlaczego warto spróbować Hoppscotch?

Dla zespołów szukających lekkiego, szybkiego i otwartego narzędzia, które można łatwo dostosować do własnych potrzeb, Hoppscotch jest atrakcyjną opcją. Szczególnie sprawdzi się tam, gdzie priorytetem jest:

• możliwość wdrożenia lokalnego (on-premise),
• brak ograniczeń licencyjnych,
• współpraca poprzez repozytoria Git,
• obsługa wielu protokołów – REST, GraphQL, WebSocket, SSE,
• działanie w przeglądarce i offline dzięki PWA.

Jeśli potrzebujesz bardzo rozbudowanego ekosystemu z gotowymi integracjami i monitoringiem – Postman nadal będzie naturalnym wyborem. Natomiast dla programistów i zespołów, które stawiają na prostotę, szybkość i elastyczność, Hoppscotch i Insomnia wydają się lepszym wyborem.

ChatGPT-5 – co nowego w najnowszym modelu OpenAI?

1. Nowy model w codziennej pracy

W sierpniu 2025 r. OpenAI udostępniło GPT-5 – najnowszy i najbardziej zaawansowany model językowy firmy, dostępny dla wszystkich użytkowników ChatGPT, także w wersji bezpłatnej (openai.com). To znaczący krok naprzód pod względem jakości odpowiedzi, precyzji i elastyczności w dopasowaniu do kontekstu.

2. Co nowego?

• Automatyczny wybór modelu – GPT-5 sam dobiera wewnętrzny wariant do konkretnego zadania, więc nie trzeba ręcznie przełączać wersji (businessinsider.com).
• Wyższy poziom inteligencji – według Sama Altmana to krok w stronę AGI, a użytkownicy zauważają lepsze efekty w kodowaniu, analizach i pisaniu (theatlantic.com).
• Większa precyzja – poprawione rozumienie kontekstu, mniej tzw. halucynacji, szybsze odpowiedzi (wired.com).
• Wersje do różnych zastosowań – standardowa, mini, nano, a także Pro i “Thinking” dla bardziej złożonych problemów.
• Nowe integracje – łączenie z Gmail i Google Calendar, personalizacja stylu rozmowy, lepszy tryb głosowy i wgląd w proces myślowy.

3. Empatyczne podejście

Jedną z ciekawszych zmian jest większa wrażliwość na ton i treść rozmowy. Model nie rzuca się od razu do realizacji każdej prośby, jeśli brzmi ona jak efekt chwili emocji.

Przykład:

Ty: „Mam dość wszystkiego. Chcę dziś sprzedać cały majątek i wyjechać na 10 lat.”
GPT-5: zamiast szukać biletów i ofert sprzedaży, odpowiada:
– „To brzmi jak poważna decyzja. Chcesz opowiedzieć, co się stało? Możemy rozważyć różne opcje.”

To celowy zabieg – OpenAI stawia na bezpieczniejsze i bardziej odpowiedzialne interakcje, które najpierw skłaniają do refleksji, a dopiero później do działania.

4. Niedoskonałości wciąż są

Nowy model nie jest wolny od błędów. Zdarzają się literówki i drobne wpadki faktograficzne („Nowe Jefst”, „Mitroinia”), a część użytkowników zgłasza problemy z routingiem zapytań (theguardian.com). Na forach pojawiają się też głosy, że brakuje możliwości korzystania ze starszych wersji, takich jak GPT-4o czy 4.1 (techradar.com).

5. Podsumowanie

GPT-5 to wszechstronny model, który łączy wyższą jakość odpowiedzi z nowymi możliwościami integracji i lepszym wyczuciem kontekstu. Dla użytkowników oznacza to narzędzie, które potrafi nie tylko generować treści i analizować dane, ale też reagować w sposób bardziej odpowiedzialny. Jeśli do tej pory korzystałeś z GPT-4, różnicę zauważysz szybko – szczególnie w dialogach wymagających refleksji i delikatnego podejścia.

---

Źródła:

• OpenAI's GPT-5 is live and free for all after years of hype by Sam Altman. Here's what it can do.
• OpenAI Finally Launched GPT-5. Here's Everything You Need to Know
• OpenAI unveils ChatGPT-5 and its hyped 'PhD level' intelligence struggled with basic spelling and geography

dev{tools}: Para – lekka platforma backendowa do tworzenia aplikacji i API

Jeśli potrzebujesz prostego sposobu na szybkie uruchomienie backendu dla swojej aplikacji — bez budowania wszystkiego od zera — Para może być dokładnie tym, czego szukasz.

To lekki framework backendowy typu open source, który pozwala w kilka minut zbudować REST API, zarządzać danymi i obsługiwać uwierzytelnianie — bez konieczności pisania setek linii kodu infrastrukturalnego.

Czym jest Para?

Para to backend oparty o Java i Spring Boot, który działa w duchu „backend-as-a-service”.
Umożliwia łatwe tworzenie i zarządzanie obiektami danych, integrację z aplikacjami frontendowymi oraz uruchamianie go lokalnie lub w chmurze.

Ciekawostka: choć niektóre źródła rozwijają nazwę jako Pluggable and Reusable Architecture, autor projektu wskazuje, że pochodzi ona od bułgarskiego słowa „pára” (para wodna) – symbolicznie „zasilająca” backend Twojej aplikacji.
➡️ Źródło – GitHub README

Najważniejsze cechy Para:

• przechowuje i zarządza obiektami (modelami) w stylu NoSQL,

• zapewnia gotowe mechanizmy uwierzytelniania i RBAC,

• wspiera relacje między obiektami,

• udostępnia RESTful API natychmiast po wdrożeniu,

• obsługuje tagowanie, wyszukiwanie i wersjonowanie danych.

📘 Oficjalna dokumentacja: https://paraio.org/docs/

Z czego się składa?

Komponent	Opis
para-core	Silnik backendu (Java) zarządzający danymi, API i logiką.
para-server	Samodzielna aplikacja REST oparta na Spring Boot.
para-client	Klient Java do komunikacji z API Para.
para-js	Klient JS/TS do integracji z aplikacjami frontendowymi (np. React).
para-admin-ui	Graficzny panel administracyjny oparty na Angular.

Architektura i komponenty

System Para składa się z kilku współpracujących warstw:

• Para Server – główny punkt wejścia (Spring Boot), udostępniający REST API.

• Para Core – logika obiektów, typów, zabezpieczeń i relacji.

• Storage Layer – przechowywanie danych (np. ElasticSearch, DynamoDB, H2).

• Client SDKs – integracja z frontendem lub backendem (JS/Java).

• Admin UI – panel do zarządzania modelami i konfiguracją.

Dzięki modułowości możesz wymienić lub rozszerzyć każdy z komponentów — np. podmienić bazę danych, system logowania, dodać middleware.

Do czego mogę użyć Para?

• budowa CMS-ów, katalogów, blogów, e-commerce i prostych aplikacji,

• szybkie tworzenie REST API dla aplikacji mobilnych i SPA,

• backend do MVP, proof-of-concept, hackathonów,

• mikroserwis z autoryzacją i relacjami obiektów,

• backend dla aplikacji JAMstack (React/Vue + Para + CDN).

Jak zacząć? (Quickstart)

1. Uruchomienie Para lokalnie (Docker)

docker run -p 8080:8080 --name para \
  -e PARA_ENV=dev \
  -e PARA_APP_NAME=app \
  -e PARA_SECRET_KEY=mysecret \
  erudika/para

Po uruchomieniu REST API będzie dostępne pod adresem:
📍 http://localhost:8080

---

2. Tworzenie obiektów

📌 Upewnij się, że posiadasz poprawny token JWT (np. po logowaniu).

curl -X POST http://localhost:8080/v1/app/object \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR-JWT-TOKEN" \
  -d '{
        "type": "person",
        "name": "Jan Kowalski",
        "email": "jan@example.com"
      }'

Otrzymasz obiekt z id, timestamp, metadanymi i możliwością dalszej edycji przez API.

---

3. Użycie z JavaScript (np. w React)

import { ParaClient } from '@erudika/para-client';

const para = new ParaClient('accessKey', 'secretKey');
para.getAll('person').then(results => {
    console.log(results);
});

📌 Domyślnie dane są paginowane — jeśli chcesz uzyskać więcej wyników, pamiętaj o ustawieniu limitu.

Wbudowane funkcje bezpieczeństwa

• uwierzytelnianie (OAuth2, Google, GitHub, Facebook),

• RBAC – role i uprawnienia,

• szyfrowanie haseł, tokeny JWT,

• full-text search (ElasticSearch / Lucene),

• tagowanie i relacje między obiektami,

• wsparcie dla middleware i hooków (Spring Boot).

Integracja z architekturą

Para działa jako mikroserwis REST – możesz zintegrować go z:

• frontendem (React, Vue, Angular),

• systemami auth (np. Keycloak, Auth0),

• CI/CD (np. GitHub Actions),

• backendami Node.js, Spring Boot lub .NET.

Wersja self-hosted działa na Dockerze, VPS lub w K8s — masz pełną kontrolę nad danymi i środowiskiem.

Podsumowanie

Para to backend idealny do szybkich wdrożeń, prototypów i lekkich aplikacji.
Daje Ci REST API, uwierzytelnianie, przechowywanie danych i relacje — bez konieczności budowania tego wszystkiego od zera.

✅ REST API w kilka minut
✅ Możliwość pełnej kontroli (self-hosting)
✅ Integracja z frontendem i CI/CD
✅ Bezpieczna architektura oparta o Java/Spring
✅ Gotowe do użycia jako komponent w mikroserwisach

EA - Wstęp do Behavior Driven Development (BDD)

 Współczesne metodyki tworzenia oprogramowania coraz częściej koncentrują się na współpracy między zespołami technicznymi a biznesowymi. Jednym z najskuteczniejszych podejść, które to umożliwiają, jest Behavior Driven Development (BDD). Dzięki BDD zespoły mogą efektywnie komunikować się i precyzyjnie definiować wymagania, co prowadzi do tworzenia bardziej użytecznych i spójnych systemów.

W tym artykule przedstawię, czym jest BDD, jak działają narzędzia takie jak Cucumber i język Gherkin, oraz jak za pomocą narzędzia CuPL można generować scenariusze BDD na podstawie diagramów aktywności generowanych w PlantUML.

Behavior Driven Development (BDD) – czym jest?

BDD to praktyka, która umożliwia zespołom programistycznym i biznesowym współpracę przy definiowaniu zachowania systemu. Podejście to opiera się na scenariuszach, które opisują, jak system powinien działać w różnych sytuacjach. Kluczowe cechy BDD:

1. Wspólny język: Wszystkie strony zaangażowane w projekt mogą zrozumieć scenariusze, ponieważ są pisane w prostym, naturalnym języku.
2. Testy jako dokumentacja: Scenariusze stają się żywą dokumentacją, która jest zawsze zgodna z implementacją.
3. Automatyzacja: Narzędzia takie jak Cucumber pozwalają na automatyczne uruchamianie scenariuszy jako testów.

---

Narzędzie Cucumber i język Gherkin

Cucumber

Cucumber to popularne narzędzie wspierające BDD. Pozwala na definiowanie zachowania systemu w formie scenariuszy testowych i automatyczne ich uruchamianie. Główne cechy:

• Obsługa wielu języków programowania, w tym Java, Python, Ruby i JavaScript.
• Integracja z frameworkami testowymi, takimi jak JUnit czy TestNG.
• Możliwość łączenia scenariuszy z kodem za pomocą tzw. step definitions.

Gherkin

Język Gherkin to rdzeń Cucumbera. Służy do pisania scenariuszy w sposób czytelny zarówno dla programistów, jak i interesariuszy biznesowych. Struktura scenariuszy opiera się na kilku kluczowych słowach kluczowych:

• Feature: Opis funkcjonalności, która ma być zaimplementowana.
• Scenario: Konkretna sytuacja testowa.
• Given: Warunki początkowe.
• When: Akcja wykonywana w systemie.
• Then: Oczekiwane rezultaty.

Przykład scenariusza w Gherkin

Feature: Logowanie użytkownika
  Scenario: Poprawne logowanie
    Given użytkownik jest na stronie logowania
    When wpisze poprawne dane logowania
    Then zostanie przekierowany na stronę główną

Scenariusze te są następnie mapowane na step definitions – fragmenty kodu, które wykonują konkretne akcje.

CuPL

Ciekawym narzędziem jest CuPL -  CLI do automatycznego generowania plików feature Cucumber Gherkin z diagramu aktywności PLantuml

CuPL pozwala nie tylko przekształcać diagramy PlantUML w scenariusze Gherkin, ale również dostosowywać scenariusze za pomocą pliku konfiguracyjnego .cupl.json. Dzięki temu proces tworzenia testów BDD staje się bardziej precyzyjny i dostosowany do potrzeb projektu. 

Generowanie wstępnego scenariusza Gherkin

Uruchom CuPL, aby wygenerować podstawowy plik .feature oraz plik konfiguracyjny .cupl.json:

npx cupl atm.puml

Po uruchomieniu otrzymasz:

• Plik atm.feature: Wstępny scenariusz Gherkin.
• Plik atm.cupl.json: Plik konfiguracyjny do dostosowania scenariuszy.

Dostosowanie scenariuszy za pomocą .cupl.json

Otwórz wygenerowany plik .cupl.json i dostosuj go do swoich potrzeb. Przykład konfiguracji:

{
  "$schema": "https://raw.githubusercontent.com/cinoss/cupl/master/src/config.schema.json",
  "global": {
    "alias": {
      "PIN is correct": "User enters the correct PIN",
      "PIN is incorrect": "User enters an incorrect PIN"
    },
    "dialect": "en"
  },
  "paths": {
    "PIN is correct|Balance is sufficient": {
      "name": "Successful transaction"
    },
    "PIN is correct|Insufficient balance": {
      "name": "Insufficient funds",
      "tags": ["important"]
    },
    "PIN is incorrect": {
      "alias": {
        "enter PIN": "User provides PIN <input>"
      },
      "examples": [
        ["input"],
        ["1234"],
        ["0000"]
      ]
    }
  }
}

Co możesz zrobić w .cupl.json?

• Zmiana nazw scenariuszy: Użyj pola name w sekcji paths, aby nadać sensowne nazwy.
• Aliasowanie kroków: Użyj alias, aby zmienić nazwy kroków.
• Dodawanie tagów: Dodaj tags, aby oznaczyć scenariusze specjalnymi etykietami.
• Dodawanie przykładów: Użyj examples, aby zdefiniować parametry w krokach scenariuszy.
• Zmiana języka: Pole dialect umożliwia ustawienie innego języka Gherkin.

Generowanie ostatecznego scenariusza Gherkin

Po wprowadzeniu zmian w .cupl.json, uruchom CuPL ponownie z flagą -w, aby wygenerować zaktualizowany plik .feature:

npx cupl -w atm.puml

Wygenerowany plik .feature będzie dostosowany zgodnie z ustawieniami w .cupl.json.

Przykład wygenerowanego scenariusza

Plik .feature po dostosowaniu

Feature: ATM Transactions

  Scenario: Successful transaction
    Given User enters the correct PIN
    When Balance is sufficient
    Then Dispense Cash

  Scenario: Insufficient funds @important
    Given User enters the correct PIN
    When Insufficient balance
    Then Show Error

  Scenario Outline: Invalid PIN
    Given User provides PIN <input>
    Then Retry

    Examples:
      | input  |
      | 1234   |
      | 0000   |

Podsumowanie

BDD to podejście, które łączy techniczne i biznesowe aspekty tworzenia oprogramowania. Dzięki narzędziom takim jak Cucumber, Gherkin i CuPL, zespoły mogą tworzyć czytelne scenariusze, które są jednocześnie testami, dokumentacją i mogą mieć swój początek z diagramów aktywności.

Jeśli chcesz usprawnić współpracę w zespole, poprawić jakość kodu i tworzyć bardziej zrozumiałe systemy, wypróbuj BDD w połączeniu z narzędziami do automatyzacji i wizualizacji. Behavior Driven Development to nie tylko metoda, ale i sposób myślenia o współczesnym tworzeniu oprogramowania.

EA - Czym jest Software Bill of Materials?

 SBOM (Software Bill of Materials), czyli "spis treści" oprogramowania, to dokument, który zawiera szczegółowy wykaz wszystkich komponentów używanych w danej aplikacji, w tym bibliotek open-source, frameworków i innych zależności. W kontekście narzędzia OWASP Dependency-Track, SBOM pełni kluczową rolę w zarządzaniu bezpieczeństwem i zgodnością oprogramowania.

Dlaczego SBOM jest ważne?

1. Przejrzystość: Dzięki SBOM zespół ma pełny obraz używanych zależności, co ułatwia identyfikację potencjalnych podatności.
2. Zgodność regulacyjna: SBOM staje się coraz bardziej wymagane przez przepisy prawa, takie jak Executive Order on Improving the Nation’s Cybersecurity w USA, które nakładają obowiązek dostarczania SBOM przez dostawców oprogramowania.
3. Monitorowanie ryzyk: SBOM pozwala szybko reagować na nowe podatności, ponieważ dokładnie wiadomo, które komponenty wymagają uwagi.

Dependency-Track i SBOM

Dependency-Track automatycznie generuje i zarządza SBOM dla każdego projektu. Narzędzie obsługuje formaty standardowe, takie jak:

• CycloneDX – rekomendowany format SBOM rozwijany przez OWASP.
• SPDX (Software Package Data Exchange) – szeroko stosowany w dużych projektach open-source.

Dzięki wbudowanej obsłudze SBOM, Dependency-Track:

• Analizuje wszystkie komponenty wymienione w SBOM pod kątem znanych podatności.
• Monitoruje zmiany w zależnościach na przestrzeni czasu.
• Pozwala na łatwe udostępnianie SBOM interesariuszom i partnerom w celu spełnienia wymagań zgodności.

Praktyczne zastosowanie SBOM

Przykład: Jeśli pojawi się nowa podatność w popularnej bibliotece open-source, Dependency-Track automatycznie porówna SBOM projektu z bazą danych podatności (np. CVE). Jeśli podatna wersja znajduje się w projekcie, zespół natychmiast otrzyma ostrzeżenie wraz z zaleceniem aktualizacji lub usunięcia podatnego komponentu.

Budowanie SBOM (Software Bill of Materials) jest kluczowe dla zarządzania bezpieczeństwem zależności w projektach programistycznych. W różnych językach programowania można wykorzystać różne narzędzia i techniki do automatycznego generowania SBOM. Poniżej przedstawiam najpopularniejsze rozwiązania dla języków Java, C#, PHP i JavaScript.

1. Java

Java wykorzystuje narzędzia zarządzania zależnościami, takie jak Maven czy Gradle, które są kompatybilne z formatami SBOM, takimi jak CycloneDX.

Budowanie SBOM w Maven:

1. Zainstaluj wtyczkę CycloneDX:

   <plugin>
       <groupId>org.cyclonedx</groupId>
       <artifactId>cyclonedx-maven-plugin</artifactId>
       <version>2.7.9</version>
   </plugin>
   

2. Uruchom wtyczkę:

   mvn cyclonedx:makeAggregateBom
   

3. Plik SBOM (bom.xml) zostanie wygenerowany w katalogu projektu.

Budowanie SBOM w Gradle:

1. Dodaj wtyczkę CycloneDX do build.gradle:

   plugins {
       id "org.cyclonedx.bom" version "1.7.4"
   }
   

2. Wygeneruj SBOM:

   gradle cyclonedxBom
   

3. Plik SBOM (bom.xml lub bom.json) znajdziesz w katalogu build/reports.

---

2. C#

W ekosystemie .NET generowanie SBOM można zrealizować za pomocą narzędzia dotnet CLI lub specjalnych bibliotek.

Budowanie SBOM za pomocą dotnet CLI:

1. Zainstaluj narzędzie dotnet-project-assets:

   dotnet tool install -g dotnet-project-assets
   

2. Wygeneruj SBOM:

   dotnet-project-assets
   

3. Plik sbom.json zawierający zależności projektu zostanie utworzony.

Inne narzędzia:

• Użycie platformy CycloneDX: istnieją gotowe wtyczki dla .NET pozwalające na generowanie SBOM w formacie CycloneDX.

---

3. PHP

W projektach PHP zależności są zarządzane przez Composer, który również wspiera generowanie SBOM.

Budowanie SBOM za pomocą Composer:

1. Dodaj wtyczkę Composer CycloneDX:

   composer require --dev cyclonedx/cyclonedx-php-composer
   

2. Wygeneruj SBOM:

   vendor/bin/cyclonedx-composer make-bom
   

3. Plik SBOM (bom.json) zostanie zapisany w katalogu projektu.

Dodatkowe rozwiązania:

• Narzędzia takie jak SCA (Software Composition Analysis) mogą również generować SBOM dla projektów PHP.

---

4. JavaScript (Node.js)

W projektach JavaScript i Node.js używa się narzędzi takich jak npm lub yarn do zarządzania zależnościami.

Budowanie SBOM za pomocą CycloneDX npm:

1. Zainstaluj CycloneDX CLI:

   npm install -g @cyclonedx/cyclonedx-npm
   

2. Wygeneruj SBOM:

   
   cyclonedx-npm --output bom.json
   

3. Plik bom.json zostanie zapisany w katalogu projektu.

Budowanie SBOM za pomocą yarn:

1. Zainstaluj wtyczkę CycloneDX:

   yarn global add @cyclonedx/cyclonedx-npm
   

2. Wygeneruj SBOM:

   cyclonedx-npm --output bom.json
   

Podsumowanie roli SBOM w Dependency-Track

SBOM jest fundamentem skutecznego zarządzania zależnościami. W kontekście Dependency-Track to nie tylko dokument, ale także narzędzie, które zapewnia bezpieczeństwo, przejrzystość i zgodność oprogramowania. Dzięki automatycznemu generowaniu i monitorowaniu SBOM, zespoły DevOps mogą zyskać pełną kontrolę nad komponentami swoich aplikacji i szybko reagować na pojawiające się zagrożenia.