Posts on Gyuri Horák

Meshtastic

Thu, 26 Mar 2026 00:00:00 +0000

A Meshtastic egy nyílt forrású project, amely LoRa (Long Range radio) technológiát használva lehetővé teszi autonóm mesh hálózatok létrehozását. Ez azt jelenti, hogy a Meshtastic eszközök képesek kommunikálni egymással anélkül, hogy szükség lenne egy központi szerverre vagy internetkapcsolatra. Ez különösen hasznos lehet olyan helyeken, ahol nincs megbízható mobilhálózat vagy internet.

Vagy olyankor, amikor ezeket szándékosan lekapcsolják.

Mi az a LoRa?

A LoRa egy vezeték nélküli kommunikációs technológia, amely nagy hatótávolságot ígér alacsony energiafogyasztás mellett. Az eszközök több kilométeres távolságra is kommunikálhatnak egymással, miközben minimális energiát használnak. A LoRa technológia különösen alkalmas olyan alkalmazásokhoz, ahol fontos a hosszú távú kommunikáció és az alacsony fogyasztás, például mezőgazdasági szenzorok, városi infrastruktúra vagy vészhelyzeti kommunikáció.

Szabadon használható frekvenciatartományokat használ (433 MHz, 868 MHz Európa, 915 MHz USA), így nem igényel licencet a használata, viszont az adó teljesítmény és a kommunikációs sebesség korlátozott lehet a helyi szabályozásoktól függően (tipikusan jóval 1W alatt).

Maga a LoRa csak a fizikai réteget jelenti, amely meghatározza, hogyan történik a rádiókommunikáció, a hálózati réteg és a protokollok azonban különbözőek lehetnek, felhasználástól függően.

A LoRaWAN (LoRa Wide Area Network) például főként IoT (Internet of Things) alkalmazásokban használatos - mezőgazdaságban, iparban, távoli szenzorok leolvasására -, ahol egy központi hálózati szerver kezeli a kommunikációt az eszközök között. Ezzel szemben a Meshtastic vagy a MeshCore egy peer-to-peer mesh hálózatot hoz létre, ahol az eszközök közvetlenül kommunikálnak egymással, anélkül, hogy egy központi szerverre lenne szükség.

Az áramfelhasználás nyilván szintén függ a felhasználás módjától, de például “buta” talajnedvességmérő szenzorok akár évekig képesek egy 1.5 Voltos AA elemmel elműködni.

Meshtastic

Magyarországon jelenleg a két népszerűbb LoRa alapú mesh hálózatból a Meshtastic van jobban elterjedve - a MeshCore-ral szemben, amely egy újabb projekt, nem akkora a közösség, és “techibb” -, ezért első körben azt akartam kipróbálni.

A Meshtastic alapjai

Teljesen decentralizált
Titkosított kommunikáció
Szöveges üzenetek, helymeghatározás, és egyéb adatátvitel (hőmérséklet, páratartalom, stb.)

Eszközök

A Meshtastic eszközök általában egy LoRa modulból, egy mikrokontrollerből (például ESP32), és egy akkumulátorból állnak. Sokféle létezik, vannak úgy nevezett “companion” eszközök, amelyek egy okostelefonhoz csatlakoznak Bluetooth-on keresztül, van, amelyiken van kijelző, van, amin nincs, vannak “buta” eszközök is pl. GPS trackelésre, és vannak szinte telefonnak kinéző, billentyűzetes eszközök is, ezekkel önmagában is lehet üzeneteket írni és fogadni.

Működés

Flooding

A hálózatban minden eszköz (ami úgy van konfigurálva) megpróbálja továbbítani az üzeneteket a többi eszköznek, amíg el nem érik a célt.

a küldő eszköz elküldi az üzenetet, amin beállít egy hop limitet (maximum 7)
a fogadó eszköz megkapja az üzenetet, és ha nem ő a címzett, még nem látta azt a csomagot (ID alapján, amit egy csúszóablakos cache-ben eltárol), és az újraküldések száma nem érte még el a hop limitet, akkor továbbítja a többi eszköznek

Titkosítás

Első használatkor minden eszköz generál egy kulcspárt, és a nyilvános kulcsot megosztja a többi eszközzel (rendszeres “nodeinfo” üzenetekkel). A direkt üzeneteket a küldő eszköz a címzett nyilvános kulcsával titkosítja, így csak a címzett tudja visszafejteni az üzenetet a saját privát kulcsával. A továbbított üzeneteket azonban minden eszköz megkapja, de nem tudják visszafejteni, így nem látják a tartalmát.

A közös csatornákon is titkosított üzeneteket továbbítanak, így a hálózat biztonságos marad, még akkor is, ha valaki megpróbálja lehallgatni a kommunikációt. (A csatornákhoz meg kell adni a titkosítási kulcsot, ami a publikus csatornáknál mindenki által ismert, de ettől függetlenül az ezekre küldött üzenetek is titkosítottak, csak mindenki visszafejtheti őket.)

MQTT bridge

Bár teljesen opcionális a használata, de lehetőség van egy MQTT bridge-et is beállítani, ami egy központi szerverre továbbítja az üzeneteket, így azok elérhetővé válnak egy webes felületen keresztül is. Ez különösen hasznos lehet olyan helyeken, ahol van internetkapcsolat, és szeretnénk a hálózatot egy központi helyről monitorozni vagy irányítani.

A bridge elvileg arra is használható, hogy két, egymástól fizikailag távolabb lévő hálózatot összekössön, de ez nem túl gyakori használati mód (és nyilván ezzel sérül az “autonómia”).

Saját setup

Először egy Seeed Studio T1000E-t és egy Heltec T114-et szereztem be, amiket tudok magammal hordani - nRF52840-es mikrokontroller van mindkettőben, ami sokkal kevesebbet fogyaszt, mint az ESP32-es változatok. Eredeti tervem az volt, hogy valamelyiket viszem magammal futni, így olyan helyeken is tudnak mások engem követni, ahol nincs mobilhálózat.

Az első nagyobb teszten a Pilisben ez jól vizsgázott, az Apátkúti-völgyben is kiment tőlem több pozíció report - de a Pilis különösen jól le van fedve, és akkor még “LongFast” preset beállítást használt a magyar közösség, ami ilyen szempontból jobb volt, mint a jelenleg használt “MediumFast” (amire azért váltott a társaság, mert Budapesten már kezdett túltelítődni a hálózat).

A preset egy előre definiált beállításkészlet, ami meghatározza a LoRa kommunikáció paramétereit, például a sebességet, a kódolási sebességet, a sávszélességet, stb. Ezek a paraméterek befolyásolják a hatótávolságot és az energiafogyasztást. A “LongFast” preset például hosszabb hatótávolságot biztosít alacsonyabb adatátviteli sebességgel, míg a “MediumFast” gyorsabb adatátvitelt tesz lehetővé rövidebb hatótávolság mellett.

A paraméterek részletesebb magyarázata megtalálható a Meshtastic dokumentációjában.

Itthon viszont semmi nem látszódott (Budakeszi elégge takarásban van, pláne Budapest és a Pilis felől), de futás közben a környéken is sokszor kaptam üzeneteket, úgyhogy úgy döntöttem, hogy kiteszek egy node-ot a ház tetejére is, hátha azzal jobb lesz a lefedettség. Ez egy Heltec V3 lett (ESP32 alapú, de hálózatról kap áramot). Ez sem volt még azonban elég, hiába kapott nagyobb (4dBi-s) antennát, néhány kósza betévedő csomagon kívül (amit gondolom a környéken közlekedők osztottak tovább) nem láttam semmit.

Az áttörés most kedden jött el, amikor megérkezett az aliról rendelt AB-IOT erősítő, ezzel már látok és látszódom :) Egyetlen node-dal stabil a kapcsolat, ami pedig a kb. 40km-re lévő Gerecse csúcsán van, szóval a hatótávolság tényleg durva. A kapcsolat meglepően stabil, pedig a jel erőssége -100dBm körül van, az SNR (jel/zaj viszony) pedig -10dB körül, amik nem tűnnek soknak. A Normafáról (~2.5km) indított traceroute 100km-nél többet utazott, mire hazajutott :)

Tesztként indítottam néhány traceroute-ot távolabbi node-ok felé is, és kiderült, hogy a 38km-es távolság egyátalán nem nagy, jó antennával, erősítővel és szűrővel rendelkező node-ok sokkal többre is képesek.

Sokat segítene a helyzeten egy napelemes node a Csergezán Pál kilátóra, de azt sajnos tavaly év végén lezárták, így egyelőre el se kezdtem kérdezősködni, hogy hogy lehetne oda hivatalosan felszerelni valamit.

Magyar közösség

A magyar mesh közösség bár nem nagy, de mindenképp nagyobb, mint elsőre gondoltam :) Egyelőre Budapest környéke, az Észak-Dunántúl, és pár nagyobb város van lefedve valamennyire, de napról napra jelennek meg újabb node-ok, úgyhogy ez a helyzet gyorsan változhat.

Az aktuális beállítások megtalálhatóak a Magyar Meshtastic közösség oldalán, itt egy térképen is meg lehet nézni, hogy hol vannak node-ok és mekkora eséllyel tudsz velük kapcsolatot teremteni.

Szintén érdekes az MQTT adatokat gyűjtő weboldal, ahol a hálózat forgalmát lehet monitorozni, és látható, hogy melyik node-ok kommunikálnak egymással.

Mivel a mesh még messze nem teljes, és a max 7 hop limit miatt úgyse feltétlen látna mindenki minden üzenetet, ezért a kommunikáció Discordon (hmm, hát igen) is zajlik, ahol mindig akad valaki, aki tud segíteni, ha elakadnál a beállításokkal.

Oké, de mire jó ez az egész?

Off-grid kommunikáció a semmi közepén, például túrázás közben, vagy olyan helyeken, ahol nincs mobilhálózat (vagy “túlélőturák”, ahova nem szabad mobiltelefont vinni)
Autó, motor, esetleg szökni szerető kutyák GPS trackelése mindenféle előfizetés nélkül
Vészhelyzeti kommunikáció, például árvíz, földrengés
Közösségi hálózatok létrehozása olyan helyeken, ahol nincs megbízható internetkapcsolat
Kísérletezés, tanulás, és a technológia megismerése
De komolyan, egy off-grid, autonóm, titkosított kommunikációs csatorna, amit a kis adóteljesítmény miatt még detektálni is nehéz, ha nem tudod pontosan mit keresel… egyszóval preppereknek :)

Agentic Coding - az AI, mint programozó

Tue, 26 Aug 2025 00:00:00 +0000

Az AI (pontosabban az LLM-ek) igen gyorsan fejlődnek az utóbbi időben, már elkerülni is nehéz őket a mindennapokban - a Google keresőjében, a levelezőnkben, a böngészőnkben, a mobilunkon, a közösségi médiában, mindenhova beintegrálták, és szembe jön, ha szeretnénk, ha nem. Egy ideje már azt is nagyon mondogatják, hogy a programozókat is ki fogja váltani, és megjelent a vibe coding kifejezés is, ami arra utal, hogy a fejlesztők már csak a hangulatot (vibe) adják meg, az AI pedig megírja a kódot.

Én kb. a kezdetektől (amikor megkaptam a béta Copilot-ot, eléggé az elején) használom, főként, mint okos(abb) kódkiegészítőt, illetve újabban néha meg-megkérdeztem olyan témákban, amikhez ritkán kell nyúlnom, és nem pontosan emlékszem a részletekre, de komplett programokat, vagy nagyobb kódrészleteket soha nem generáltam vele. Kb. idén év elejéig a vibe codingot is főként egy játéknak tekintettem, és hát a legtöbb történet, amivel a közösségi médiában találkoztam, az is inkább vicces, vagy érdekes volt, mint komoly - pl. hogy valaki mindenféle programozási ismeret nélkül, csak úgy “vibe”-olva, az AI segítségével csinált egy komplett szolgáltatást, és máris pénzt keres vele, aztán pár nap múlva jelentkezett, hogy feltörték a szolgáltatását, és fogalma sincs, mit csináljon, hiszen ügyfelei is vannak, honnan kaphatna segítséget, …

Aztán úgy idén év eleje óta olyan olyan szakemberek is pozitívan nyilatkoztak a témáról, akiknek adok a véleményére (pl. Armin Ronacher), és a redditen is előkerültek számomra is hihető történetek, úgyhogy tavasz végén úgy gondoltam, hogy belevágok egy kísérletbe, és vájb kódolok egy egyszerűbb webalkalmazást. Amit csak lehet, az AI agentekre bízok, én csak akkor nyúlok a kódhoz, ha valamiért nagyon muszáj.

TL;DR: Az elején szkeptikus voltam, de mostanra lett egy új barátom, Klód, aki esténként, amíg a kertben mókolunk, vagy hosszú unalmas meetingek alatt szépen fejlesztgeti nekem a live-tracker projektemet.

A projekt

Valami értelmes projektet szerettem volna csinálni, nem egy újabb TODO appot, és mivel sokat futok terepen, akár egyedül is hosszabbakat, szeretem, ha tudják az ismerősök, hogy épp merre járok. Ehhez eddig Garmin livetrack linkeket küldözgettem, de az picit körülményes, és amint vége a futásnak, már nem is elérhető, úgyhogy gondoltam, jó lenne valami ilyen live-tracker, amit később ki is lehet bővíteni, pl. egész csapat követésével - a hosszú váltók (pl. UB) során ez jó lehet olyanoknak is, akik az egész csapatot szeretnék egyben követni.

Az MVP egy sima egy felhasználós weboldal lett volna, ami engem tud követni, de aztán ennél jóval messzebbre jutottunk:

több felhasználó (de regisztráció nincs), profil szerkesztés
valós idejű helymegosztás
livetrack session-ök elnevezése, visszanézhetősége
felhasználók utolsó publikus helyeinek térképes megjelenítése a főoldalon
mobil barát felület
dark mode

Hogy tudjam is trekkelni a helyzetemet, az egyik Garmin adatmezőmet kiegészítettem ilyen képességgel. Ehhez is próbáltam AI segítségét kérni, de akkor még csak Geminit használtam, ami nem boldogult jól az - egyébként valóban egzotikus, és keveset használt - Garmin Monkey-C nyelvvel, úgyhogy azt inkább magam írtam meg. Az azóta szerzett tapasztalatokkal majd újra nekiveselkedek, úgyis kell egy általánosabb verzió is.

(itt elérhető, de egyelőre elég kísérleti, és csak drágább órákon működik)

A tech stack

Az internetes beszélgetések alapján arra jutottam, hogy valami egyszerűbb (kezdőbarátabb) nyelvet válasszak, és minél kevesebb külső függőséggel induljak neki. A redditen a Python és (sima) JavaScript mellett a Go is többször felmerült, mint jó választás, mert relatíve egyszerű, de mégis rendesen típusos, így a backendhez azt választottam. Illetve nem akartam 0-ról indulni, így a PocketBase lett a backend, ami egy egyszerű, REST API-t is kínáló backend megoldás, és van hozzá egy elég jó admin felület is.

A frontendhez a sima HTML/CSS/JS mellett döntöttem (webkomponensekkel), és bár a typescript lenne az egyértelmű választás, ha én magam írnám a kódot, azt olvastam, hogy a komplexebb típusokba bele tudnak zavarodni az AI-k, úgyhogy maradtam a sima JavaScriptnél, ráadásul ezzel mindenféle build system nélkül is elindulhattam.

Backend: PocketBase (Go)

Frontend: HTML/CSS/JS (webkomponensek)

Agentic coding kísérlet

25+ éve terminált használok mindenre, ezért adta magát, hogy terminálban futó megoldást válasszak - hiába van már évek óta Github Copilot előfizetésem, ami be tud épülni több IDE-be is, ezt nem használom ki teljesen. Amikor elkezdtem gondolkodni a kísérleten, akkor az internet népe épp migrált át a Cursor-ról Claude-ra, és már épp fizettem volna elő a Pro változatra, ahol elérhető a Claude Code terminálos agent, amikor a Google ingyenesen elérhetővé tette a Gemini CLI agentjét, úgyhogy inkább azt kezdtem el használni.

Első tapasztalatok

Június 25-én jelentették be a Gemini CLI-t, estére kész volt az MVP.

Oké, a feladat nem volt azért szuper bonyolult, de tapasztalatom is szinte nulla volt az AI agentek ilyen jellegű használatában, és tényleg vállalható volt, amit csinált, pláne egy tech demónak.

✅ gyors demók összerakása proof-of-concept jelleggel

Lépjünk tovább

A cél a technológia határait feszegetni, szóval nem állhattam meg itt, jött a több felhasználó támogatása.

És az első probléma. A tervet látszólag nagyon ügyesen lehozta Gemini, de a kivitelezés során bizony előjöttek problémák. A PocketBase nem egy nagyon elterjedt megoldás (de azért van 50k+ csillagja githubon), valószínűleg kevés kapcsolódó példakódon lett tanítva a modell, illetve a dokumentációt is hiába olvasgatta, elkezdett nem létező metódusokat hallucinálni, illetve ezek kitörlésével, majd újra visszaírásával loopba is került, kénytelen voltam segíteni neki. Ekkor még túl lelkes voltam, inkább megírtam a kérdéses két sort én, és mentünk tovább, de kb. ekkor nyúltam a kódhoz először és utoljára.

❌ kevésbé ismert technológiák esetén a modell hajlamos lehet hallucinálni, és loopba kerülni

A Garminos adatmezőm kibővítésénél lényegében Java (jellegű) kódot akart írni, ami ott nyilván nem működött, úgyhogy ott nem is erőltettem, inkább magam írtam meg.

Docker

Mindenesetre kész lett valami használható, ki akartam rakni kvázi élesbe, hogy kipróbálhassam rendesen. A NAS-omon minden hasonló szolgáltatás dockerben fut, úgyhogy a következő lépés a dockerizáció lett.

És itt mutatkozott meg egy újabb előnye az AI agenteknek: kb. fél évente egyszer írok 0-ról dockerfile-t, és mindig elfelejtem a szintaxist, tehát keresgéléssel és dokumentáció olvasgatással kezdem a dolgot. Most ez kimaradt, Gemini fél pillanat alatt megírta nekem a dockerfile-t, lebuilde-elte, kipróbálta, megkért, hogy lépjek be (docker login), és fel is töltötte a DockerHub-ra.

✅ ritkán használt, de egyébkent egyszerű, jól dokumentált feladatoknál gyorsan tud segíteni

GPX upload mini tool

Kész volt az API, a webes felület, és végül is az órámon is ott volt a trackelésre alkalmas adatmező, de épp nem volt kedvem elmenni futni, hogy legyen éles adat, és kellett valami, amivel fel tudok nagyobb útvonalat tölteni, hogy kipróbáljam a működést. Percek alatt született meg a gpxup nevű kis programocska, ami egy GPX fájlt feltölt az API-n keresztül.

✅ kis toolok, script-ek gyors összedobása

Claude

Mivel közben mindenhol azt olvastam, hogy hát lehet próbálkozni a többi agenttel is, megfelelően promptolva azok is egész jó eredményt tudnak elérni, DE pariban sincsenek Claude-dal, ezért úgy döntöttem, hogy csak befektetek egy Pro előfizetésbe, és kipróbálom azt is.

Mindenhol azt javasolják, hogy hiába olcsóbb az éves előfizetés, annyira gyorsan változnak a dolgok, hogy inkább havi díjasat vegyél, és ha kell, bármikor le tudod mondani és váltani az aktuális legjobb megoldásra.

Azt kell, hogy mondjam, hogy - az én workflow-mban - Claude teljesen más ligában játszik, mint minden más, amit eddig (a blogpost megírásáig) próbáltam. Jelenleg, ha programozásra szeretnél AI-t használni, akkor Claude Code. (A Pro előfizetés csak a Sonnet-4 modellt tartalmazza, a fejlettebb Opus-t nem, de még így is nagy különbséget éreztem a többi megoldáshoz képest.)

Elszabadultak a feature-ök, belépés, profil oldal, session oldal, dark mode, …

MCP szerverek

Az MCP (Model Context Protocol) egy új szabvány, amellyel az AI modellek használni tudnak külső szolgáltatásokat (adatbázisokat, programokat, …). Eléggé egyszerű (lehet, hogy túlzottan is, majd az idő eldönti), és kb. minden támogatja. Pl. ennek a segítségével az agentek valódi böngészőt is tudnak használni, és meg tudják nézni, illetve debuggolni az általuk készített weboldalakat. ( playwright-mcp )

Amikor Claude a felhasználó avatárját az útvonala végére illesztette, akkor nem tetszett a marker alakja - hiába mondogattam neki, hogy fejre állított csepp alakot szeretnék, valami béna oválist használt (bár esés közben valóban inkább olyan alakúak a cseppek, de na). Már majdnem hozzányúltam én a kódhoz, amikor eszembe jutott, hogy kipróbálhatnám a Playwright MCP-t, és a segítségével sikerült emberi beavatkozás nélkül túljutni a problémán.

Durva refaktor

Ezen a ponton volt egy használható webalkalmazásom, aminek lényegében a backendje egy darab main.go volt, a frontendje pedig néhány HTML és JS file. Hosszú távon ez nem fenntartható - pláne, ha később én is bele kell, hogy nyúljak - ezért úgy döntöttem, hogy megkérem Claude-ot, hogy refaktorálja a kódot.

Mivel sejtettem, hogy ez nagy falat lesz, először részletes tervet csináltattam Claude-dal (sonnet-4), azt átnézettem Gemini-jal (2.5-pro) és Copilottal (GPT-5) - akik hozzá is írtak ezt-azt -, majd a tervet Claude részletesen lebontotta kisebb feladatokra, és úgy indítottam neki, hogy minden nagyobb lépés után álljon meg, és várja meg, amíg átnézem, amit csinált. Ez a módszer nagyon szépen működött, a tervdokumentumokban (backend terv, frontend terv) szépen vezette, hogy hol jár, így másnap - vagy amikor kifogytam az 5 órás limitből - mindig ott tudtuk folytatni, ahol abbahagytuk.

A backend refactor 3 napig tartott, a frontend 2 napig (nem teljes napok, napi 3-4 óra aktív munka), minden lépés után átfutottam, amit csinált, kértem tőle módosításokat, ahol kellett, de összességében nagyon szépen dolgozott, és a végeredmény egy sokkal jobban strukturált, modulárisabb kód lett. A két PR rettenetes méretű lett, de a lelkesebbek átnézhetik, ha van kedvük:

backend refactor PR ~15ezer+ sor
frontend refactor PR ~28ezer+ sor

(A backend PR azért failelt el, mert gitguardian megtalálta a Claude-nak létrehozott tesztaccount jelszavát a commitok között. :D Ez természetesen csak az én fejlesztői környezetemben működik, úgyhogy nem kezdtem el miatta a git historyval mókolni.)

✅ komolyabb refactorálás, szigorú felügyelet és tesztelés mellett

Egyelőre itt jár a project, most gondoltam úgy, hogy megírom ezt a blogpostot, és egy kis szünetet tartok, aztán majd meglátom, merre tovább. Lassan lehet eléri azt a méretet is, amit már nehezebben kezel egyben Claude a 200k tokenes limitjével, de egyelőre ennek még nincs jele.

vibe tracker a githubon

Toolok, modellek

Ahogy fentebb írtam, az, hogy éppen melyik modell vagy tool a legjobb, az függ attól is, hogy hogyan használod, milyen feladatot szeretnél megoldani, illetve mire kipostolom ezt a cikket valószínűleg kijött 10 új.

Modellek

Napi szinten jelennek meg újak, a képességeik/áruk/elérhetőségük eléggé változatos, itt lehet nézelődni.

Van, amelyiket csak saját felületen keresztül lehet használni, van, amit tudsz saját magad futtatni (ha van hozzá megfelelő vasad). Ráadásul rengeteg szempont alapján lehet őket értékelni, pl. mennyire jó terveket készít, mennyire generál jó kódot, tud-e toolokat használni (tesztelés, hibakeresés), mennyire követi, amit mondtál neki, mennyire tudja kezelni a hosszabb kontextust, és hát mennyibe kerül. Amelyik modell az egyik szempontból jó, az lehet, hogy egy másikból megbukik, nagyon számít, hogy mire és hogyan használod.

Saját tapasztalatok:

Gemini 2.5 pro és flash (Google)

Gemini CLI-on keresztül használtam ingyenesen, a pro napi limitje egy idő után elfogy, de automatikusan vált a flash-re. Ismerkedni tökéletes, egyszerűbb programozási feladatokhoz se rossz, de azért sikerült loopba vinni, illetve hallucinált is. A cli-os változat előnye, hogy ha látom, hogy tévúton jár, akkor gyorsan meg tudom állítani, és irányba tudom terelni.

GPT-4.1 és GPT-5 (OpenAI)

A Github Copiloton keresztül próbáltam ki őket (a GPT-5 igen friss, a projekt futása közben jelent meg), és opencode segítségével tudtam őket terminálban használni. A ChatGPT felületéről sokaknak ismerős lehet, de nekem vegyesek a tapasztalataim velük, plána a GPT-5 volt hajlamos elkalandozni, és olyan dolgokat csinálni, amiket senki nem kért tőle. A GPT-4.1-nél ez kevésbé tűnt fel, de túl sokat egyikkel sem próbálkoztam, mert a Claude sokkal jobbnak tűnt.

Claude Sonnet-4 (Anthropic)

A legjobb, amit próbáltam, fentebb olvashatóak a tapasztalataim. Mind a tervezésben, mind a kódolásban, mind a refaktorálásban nagyon jól teljesített, sőt, ha belefutott olyan dologba, amit ott hirtelen nem tudott megoldani - vagy úgy érezte, hogy nagyobb effort lenne, mint amire én a kérésem alapján számítok - akkor jelezte, és javasolt alternatív megoldásokat. Ez utóbbit más modelleknél nem tapasztaltam.

A refactor közben volt egy pont, ahol kifutottam a Claude limitéből, és úgy gondoltam, hogy akkor az elkészült részhez csináltatok a friss GPT-5-tel unit teszteket. Szinte sikerült, két függvény rendes teszteléséhez a pocketbase is kellett volna, kimockolni az egészet értelmetlen lett volna, úgyhogy ő úgy oldotta meg, hogy kitörölt dolgokat az implementációból, és a tesztelhető részeket meghagyta. :D

Claude ezzel szemben csak közölte, hogy ahhoz a két függvényhez nem ír unit tesztet, hanem majd érdemes integrációs teszteket írni hozzájuk.

Agentek

Agentekből is rengeteg féle van, a weboldalakat, ahol beszélgetni lehet az LLM-ekkel kb. mindenki ismeri, de vannak kifejezetten programozásra kihegyezett megoldások is:

parancssoros (CLI/TUI) toolok
- a modelleket kiadó cégek sajátjai (Gemini CLI, Claude code, OpenAI codex, …)
- függetlenek, de viszonteladók (Cursor cli)
- teljesen függetlenek (opencode, crush, …)
IDE kiegészítők (Github Copilot, Amazon CodeWhisperer, Tabnine, …)
komplett IDE-k (Cursor, Replit, …)
Copilot a Githubon (PR-ok generálása, kód review, issue-k kezelése, …)
…

Az én workflowm

Először is, mielőtt bármit csinálnék, létrehozok egy git/jj repót, és minden lépes után commitolok és pusholok. Az agentek is képesek git-et használni, de egy laza mozdulattal tudják megsemmisíteni az egész repository-t, és ha még push joguk is van, akkor egy apró hiba, és minden elveszik.

A legtöbb eszközben lehet külön programozó és tervező agentet konfigurálni (sőt, ezek általában alapból vannak is, és lehet még másokat is létrehozni), ezek az agentek akár különböző modelleket is használhatnak - pl. a Claude Max előfizetésében elérhető Opus modellt a tervező agent használja, a Sonnet-4-et pedig a programozó, állítólag így a leghatékonyabb a munka.

Én általában plan módban kezdek, és igyekszem úgy megfogalmazni a kérést, mintha egy ticketet fejtenék ki munkában, azaz hogy bármely kolléga el tudjon vele kezdeni foglalkozni mindenféle kérdés nélkül. Megkérem az agentet, hogy készítsen egy részletes tervet, hogyan oldaná meg a problémát. Ha úgy ítélem meg, a tervet még tovább finomítom (esetleg finomíttatom), és csak akkor indítom el az implementációs szakaszt, ha én magam is értem, hogy mit fog csinálni.

Egyelőre (?) nem bízok benne annyira, hogy review nélkül elfogadjam, amit csinál, úgyhogy minden nagyobb lépés után átnézem, amit csinált, ha kell, akkor kérek tőle módosításokat, futtattatok vele teszteket, és csak akkor lépek tovább, ha minden rendben van.

Összegzés

Szkeptikus voltam, amikor kezdtem a kísérletet, de pozitívan csalódtam.

Az LLM alapú AI-kból nem hiszem, hogy valaha AGI lesz, és lehet, hogy lassan el is érik a technológia határait, de a jelenlegi képességeik is elég jók ahhoz, hogy a programozók hatékonyabbak legyenek, és gyorsabban tudjanak haladni a munkájukkal. A kódolás egy része (pl. boilerplate kódok, egyszerűbb funkciók) teljesen automatizálható, és a fejlesztők inkább a tervezésre, az összetettebb problémák megoldására koncentrálhatnak, amikben szintén tud segítséget nyújtani egy okosabb agent.

Elveszik-e a programozók munkáját? Nem hiszem, hiszen a szoftverfejlesztés egy komplex feladat, ahol a kódolás csak egy része a munkának. Kell melléjük a felügyelet, ráadásul a valódi árukat sem ismerjük még, egyelőre szerintem csak a beetetési időszak zajlik, és minden AI cég veszteséges.

Le tudnak-e cserélni egy junior programozót? Az adott pillanatban lehet, de amíg egy juniorban megvan a potenciál, hogy egyszer senior legyen, addig egy AI agent sosem lesz okosabb annál, mint amilyenre be van tanítva, és nem fog tudni fejlődni, tapasztalatot szerezni.

Le tudnak-e cserélni egy olyan programozót, aki kvázi ész (és visszakérdezés) nélkül implementálja a kiadott ticketeket? Igen, de nekik szerintem egyébként sem nagy a hozzáadott értékük. Aztán persze nyilván ők is meg fogják találni (esetleg már meg is találták) a helyüket, és bőszen másolják a ChatGPT böngészőablakba a ticket szövegét, illetve másolják vissza a generált kódot úgy, hogy fogalmuk nincs, mit írnak le. Sajnos napi szinten látok ilyet.

Egy biztos, az LLM-ek remek eszközök lehetnek a szoftverfejlesztők kezében, és még ha nem is fejlődnek tovább ebbe az irányba, akkor is meg fognak maradni. Amire számitok, azok a kisebb, specializáltabb modellek, amiket akár helyben is (saját gépen, akár telefonon) futtathatunk. Kíváncsi vagyok, jövő ilyenkor hol tartunk majd.

Színek

Wed, 09 Oct 2024 00:00:00 +0000

Hogyan látunk színeket? Hogyan tudjuk őket általánosan “definiálni”? Hogyan tudjuk összehasonlítani őket?

Nos, ez nem egy egyszerű téma.

Színlátás

A legtöbb ember szemében 3 féle típusú csapsejt van, amelyek segítenek nekünk a színek észlelésében.

Egyszerűen belátható, miért használjuk a sárgászöldet a láthatósági ruhákhoz.

Az aktiválodasi “függvényeik” átfedésben vannak, az agyunknak egyszerűbb a csapok által mért értekének a különbségét kiértékelni, mint az abszolút értelemben vett “mért értéket”. Az ebből a technikából származó ellentétes színelmélet (opponent color theory, nem tudom mi magyarul) alapján egy 3D térben tudjuk elhelyezni az egyes színeket, ahol a dimenziók a következők:

sötét - világos (L)
vörös - zöld (a)
kék - sárga (b, a sárga lényegében a vörös és zöld csapok együttes aktiválódását jelenti)

Ez persze nem ennyire egyszerű, a kaukázusi emberek kb. 5%-ának színérzékelési problémája van (~színtévesztés), ami azt jelenti, hogy nem tudják megkülönböztetni a színeket az egyik színtengelyen (vagy mindkettőn, akkor színvakok). A vörös-zöld színtévesztés a leggyakoribb (99%-a a színtévesztőknek).

És ez csak a szemeink különbsége, az agyunknak is fontos szerepe van a színérzékelésben, néhányunk például képes látni a lehetetlen színeket is.

Állatok színérzékelése

És eddig csak az emberekről volt szó.

A legtöbb emlősnek csak két féle csapsejtje van, így a macskák, kutyák, tehenek, őzek, … színérzékelése nagyon hasonló a vörös-zöld színtévesztő emberekéhez.

Gondolkodtál már azon, miért narancssárga csíkos a tigris? A természetben a narancssárga bundát egyszerűbb előállítani, mint a zöldet, és a zsákmányállatok számára lényegében ugyanolyan színűnek látszik, így gyakorlatilag beleolvad az erdei környezetbe.

És így az is egyértelmű, miért használnak a vadászok narancssárga láthatósági ruházatot… (mi észrevesszük őket, de a vadak nem)

De, vannak azonban olyan állatok is, amelyek teljesen más vagy sokkal több színt látnak, mint mi (és egyébként nem is tudjuk elképzelni, hogy mit láthatnak). A méheknek például 3 féle csapja van - ahogy nekünk is -, de a zöld, kék és UV hullámhosszakra reagálnak. Némely madaraknak 4 csapja van, sárga, zöld, kék és UV.

… és még a madarak is gyakorlatilag színvakok bizonyos rákfajokhoz képest.

Színterek

A színek szervezési módját színtérnek hívjuk. A színterek fizikai eszközök színprofilozásával támogatják a reprodukálható színeket: falfesték, nyomtatott anyagok, színek egy monitoron vagy okostelefonon. Használhatnak például nevesített színeket (mint a Pantone vagy RAL) vagy matematikai koordinátákat (CIELAB, sRGB, …).

Színmodellek

A színmodellek absztrakt matematikai modellek a színek reprezentálására - általában 3 vagy 4 számkomponenssel. Ha a modellhez egy pontos leírás is társul, hogy hogyan értelmezzük a komponenseket, akkor használhatjuk a színmodellt egy adott színtér színeinek reprezentálására.

Példák színmodellekre:

RYB - szubtraktív, amit valószínűleg az általános iskolában használtál a vízfesték keverésére
RGB - additív, amit valószínűleg a szoftverfejlesztés során használsz (!)
CMY/CMYK - szubtraktív, nyomtatáshoz használt színmodell
HSL/HSV - “hengeres” alternatívák az RGB-hez, intuitívabb és felhasználóbarátabb, mint a sima “kocka alakú” modell

! Az RGB színmodellt használjuk pl. az sRGB, Adobe RGB vagy DCI-P3 színterekhez, de anélkül, hogy meghatároznánk a pontos színteret, ugyanazok az RGB értékek különböző színeket jelenthetnek különböző eszközökön (relatív RGB színtér)

sRGB és barátai

Semmi “különleges”, mivel szoftverfejlesztők vagyunk :)

Csak zárójelben jegyzem meg, hogy mivel ezt valami olyan eszközön nézed, ami nem tudja megjeleníteni az összes színt - sőt, valószínű csak sRGB-t, esetleg P3-at - ezért a kép nem fogja visszaadni a valóságot, csak az arányokat mutatja, hogy mennyire sok színt nem tudunk jelenleg okoseszközökön/monitorokon megjeleníteni.

CIE 1931 XYZ és RGB

Az 1920-as évek született meg a CIE RGB színtér, amely az emberi szem által érzékelhető összes színt lefedi (sőt, még többet is), és ebből származik a CIE XYZ színtér, amelyet előszeretettel használnak a színterek közötti konverziókor. (A színteret egyébként kísérleti módon állapították meg, emberi tesztalanyoknak kellett a szineket összehasonlítaniuk.)

Tuljdonságai:

eszközfüggetlen
számos más színtér a CIE XYZ alapján van definiálva
az összes koordinátája értelmes, de sok jelent (pl. [1, 0, 0], [0, 1, 0], [0, 0, 1] alapszínek) képzeletbeli színeket, melyek egyébként “nem láthatóak”
jól definiált színegyeztetési függvények
- pl. Y-t használják a kontrasztarány ellenőrzésére
- különböző színkülönbség függvények
Y - a világosság (megfigyelő által érzékelt)
Z - ~ a kék komponens a CIE RGB-ből
X - a három CIE RGB görbe keveréke

CIELAB

A CIELAB (vagy L*a*b*) színtér 1976-ban lett létrehozva. Az emberi színérzékelés működése alapján három értéket használ a színek kifejezésére:

L - világosság, észlelt fényesség (0 - 100)
a - vörös-zöld (nem korlátos, de tipikusan -128 - 127 között)
b - kék-sárga (nem korlátos, de tipikusan -128 - 127 között)

Az volt a cél, hogy perceptuálisan egyenletes legyen, ami azt jelenti, hogy egy adott numerikus változás hasonló észlelt színváltozást kell eredményezzen. Például a pozitív a érték megduplázásakor az új színnek kétszer annyira zöldnek kell lennie, mint az eredetinek.

Ezzel kb. matematikailag lehet értelmezni, hogy egy szín “zöldebb”, “kékebb” vagy csak simán “sötétebb” egy másiknál. Korábban ilyen nem volt.

CIELCh

A CIELCh egy CIELAB alapú hengeres színtér, amely polár koordinátákat használ, C (telítettség) és h (színárnyalat) formájában. (L változatlan)

A HSL/HSV színmodellekhez hasonló, de az LCh még mindig próbál perceptuálisan egyenletes lenni, mint a LAB. (!)

! Azonban az egyenletessége nem tökéletes, a kék árnyalatokat rosszul becsüli meg. A modernebb színterek - például az Oklab - orvosolják ezeket a problémákat.

Miért hasznos ez? Nagyon nehéz perceptuálisan egyenletes többszínű színátmeneteket létrehozni az RGB színmodell használatával, de a LAB/LCH (illetve Oklab/Oklch) használatával pofonegyszerű, lényegében lineáris interpoláció (felül RGB, alul LAB):

CSS

Az utóbbi években a CSS színkezelés is nagyott lépett előre, a lab() és lch() (illetve az oklab() és oklch() is) mind szerepelnek a CSS Color Module Level 4 specifikációban, és minden modern böngésző támogatja őket 🎉

Demo (CSS gradiens az oldal tetejéről, lab() használatával):

Gondolatok a futásról

Thu, 11 Jan 2024 00:00:00 +0000

Világ életemben utáltam futni. Aztán a sors közbeszólt, és mivel más mozgásformára nem nagyon volt lehetőségem, a kemó alatt elkezdtem kocogni az erdőben - egyik héten pihenés/túlélés, pihenő héten két-három alkalom, 3-4km. Aztán utána ez megmaradt - az erdőt előtte is szerettem, és úgy voltam vele, hogy ha kemó alatt ki tudtam menni, akkor holmi eső/sár/hideg már nem fog tudni visszatartani. És nem is tud. Következő évben még kb. csak ugyanezt a ritmust tartottam - heti két kis kör -, de aztán beütött a covid és a home office, én meg elkezdtem növelni a távokat és a tempót.

Érdekes visszanézni, hogy kezdetben a 3-4 km-es köreimet azzal a tempóval futottam, mint nemrég az 50+ km-es Vérmókus kört.

A futás

Én elsődlegesen terepen futok, és amit ide leírok, az főként saját tapasztalat, ha egy edző mást mond, akkor valószínűleg neki van igaza 😉

Mi kell a kezdéshez

Te

Nagyjából egészséges izületekkel/izomzattal - ha valami már elromlott, azon a futás tud rontani (de javítani is) - is érdemes kezdetben óvatosan nekivágni.

Az elején még valószínűleg az életbenmaradásra fogsz koncentrálni - kezdd nyugodtan sétával/lassú kocogással, ha még sosem mozogtál -, de ahogy haladsz, el kell kezdeni tudatosan odafigyelni a légzésre, a futótechnikára - többfélét is begyakorolni, hogy ha fáradnak a lábaid, ezeket tudd váltogatni -, meg úgy általában a testedre.

Egy cipő

Erre érdemes már az elején nagyon odafigyelni, két futócipőnek nevezett dolog között is ég és föld lehet a különbség. Az első cipő vásárlásakor mindenképp javasolt elmenni egy futóboltba, ahol tudnak tanácsot adni, illetve megmérni a lábad pronációját.

Szempontok:

terep / aszfalt?
lábfej pronáció? (pronáló/normál/szupináló)
- ezt futóboltokban több helyen is fel tudják mérni kamerával, érdemes!
- (nekem erős ludtalpam van, emiatt nagyon pronál a lábam)
mennyire vízálló/légáteresztő?
milyen a lábfejed alakja (pl. az én lábamra kb. tökéletes az Asics formája, ellenben a Salomon cipőket fel sem tudom venni, már az elején érdemes több márka több termékét felpróbálni, és helyben kicsit kocogni benne)

Kezdésnek tipikusan jó lehet egy - a pronációdnak megfelelő - aszfaltos cipő, ami kényelmes.

Extrák

Ruházat

Nem úgy értem, hogy azért extra a ruházat, mert lehet meztelenül is futni (lehet, a környéken is láttak már rá példát, de kérlek ne), hanem mert kb. bármi jó.

Amellett persze, hogy “bármi jó”, érdemes valami olyanban futni, amibe kevésbé izzadsz bele, jól elvezeti az izzadságot, és nem fázol. Végtelen pénzt el lehet sportruhákra költeni, de - főként az elején - a sportáruházak saját márkás termékei is elég jók tudnak lenni, és sokkal olcsóbbak, mint a csúcsmárkák hasonló cuccai. Főként te fogod tudni - idővel - megmondani, hogy mit érdemes az adott időjárásban felvenned, kezdésnek jó lehet az, ha ~10 fokkal melegebb időre öltözködsz.

Kulacs

Hosszabb távokon, pláne nyáron elengedhetetlen, hogy futás közben igyál. Érdemes beszerezni egy jól tárolható (összecsukható vagy összegyűrhető/szilikon) poharat, amiből egyszerűbben tudsz inni, mint trükkösen a kúton lógva, lábbal nyomni a kart, etc. Mostanában - nagyon helyesen - a legtöbb versenyen sem adnak poharat a frissítőhelyeken, a sajátodba kaphatsz innivalót.

Ha viszont az útvonalon nincs kút, akkor a folyadékot magaddal kell vinni. Teljesen valid megoldás a kiürült fél literes üdítőspalack is, de nem annyira drágák a szilikon kulacsok sem - én azért szeretem őket, mert nem lötyögnek -, illetve a hátizsákokba is kapható ivózsák.

Tracking/navigáció

Ha futsz kötelező egy strava account. Természetesen nem az, de ami nincs a neten, az meg sem történt, és jelenleg kb. a strava a futók/bringások instája. Vannak közösségek, lehet haverokat jelölgetni, illetve útvonalakat ellesni, merre érdemes futni.

A strava telefonos appja is képes a futásod rögzítésére, de van ezer másik, illetve, ha van okos-/sportórád, az ezt lehet jobban is tudja, mint a telefon. Ennek ellenére telefont - vagy valamit, amivel kapcsolatba tudsz lepni a hátramaradottakkal - mindig érdemes magaddal vinni, bármikor történhet bármi, nem utolsó sorban könnyebb megtalálni az erdőben, ha elvesznél.

Ha messzebbre merészkedsz a vadonba, akkor szintén hasznos, ha van nálad valami offline is használható térkép. Nincs mindenhol térerő, és egyébként is, a Google maps és barátai teljességgel haszontalanok terepen. Rengeteg ingyenesen is használható OpenStreetMap alapú térkép van mind Androidra, mind iOS-re, amik bizonyos funkciójáért lehet/kell fizetni, érdemes egy ilyet beszerezni, és ha sokszor használnád, meg is venni. Némelyik (pl. mapy.cz) a túristautakat is jelzi.

Aztán, ha tényleg nagyon sokat navigálsz ismeretlen terepen, és nem a telefonnal a kezedben akarsz futni, akkor szóba jöhetnek az offline navigációra képes órák - ám ezek tipikusan mocskos drágák.

Health tracking

Ha már szóba kerültek az okosórák/karkötők, a legtöbb ilyen képes a pulzusod mérésére futás közben. Ezek az adatok messze nem orvosdiagnosztikai szintűek, és másokkal sem érdemes őket összehasonlítani, de adhat egy képet arról, hogy éppen az adott napon mennyire tudsz teljesíteni, illetve figyelmeztetni is tud, hogy vegyél vissza, ha a track végere akarsz érni.

Azt érdemes megjegyezni, hogy az optikai pulzusmérés sosem lesz tökéletes, személyenként eltérő, hogy mennyire tudnak pontosak lenni még a legmodernebb órák is, ezért ha megbízhatóbb adatokra vágysz, akkor érdemes beszerezni egy pulzusmérő mellkaspántot, ami sokkal pontosabb.

Egyébként egyes órákból sok egyéb érdekes (hasznos?) dolog is kinyerhető, pl.:

lépéssűrűség
lépéshossz
becsült teljesítmény
függőleges elmozdulás
talajérintési idő (adott esetben lábak összehasonlítva, hogy mennyire szimmetrikusan használod őket)
…

Emellett - ha folyamatosan hordod az órát - képesek felmérni az alvásminőségedet, megmondják mennyit pihenj egy adott futás után, és még edzéstervet is ajánlanak.

Öv, hátizsák

Szintén személyes preferencia kérdése, hogy ki milyet szeret, és kézben a kulaccsal is lehet futni, de egy idő után nem fognak a dolgok a kezedbe férni, és a ruhádon is elfogynak a zsebek. Ezeket is érdemes felpróbálni, és itt is igaz, hogy a saját márkás sportáruházas verziók sem elvetendőek.

Fejlámpa

Ha éjszaka is futnál, akkor mindenképpen ajánlott, terepen meg pláne. Ha hosszabb útra mész, már csak azért is legyen a táskádban, hogy ha rádsötétedik, akkor ne legyen gond - esetleg legyen mit kölcsön adni az eltévedt túrázoknak, akik viszont nem vittek magukkal.

Hómacska

Akkor sem maradunk otthon, ha esett a hó. Amíg friss, addig nincs is nagy gond, de amikor már rendesen letaposta a nép, illetve megolvadt/újrafagyott, akkor megcsúszik rajta minden cipő. Ilyenkor jön jól a hómacska.

Túrabot

Itthon is van olyan terep, ahol megkönnyíti a haladást, de tanulni kell a használatát, az elején inkább akadályoz, mint segít.

“Életmentő” fólia

Jó, ez az elején remélhetőleg nem kell, de több versenyen is kötelező tartozék, és inkább legyen a táskában feleslegesen, mint ne legyen ott, de te átazva kuporogj valami üregben törött bokával fagypont körül.

Ragtapasz

Teljesen felesleges. Ha terepen futsz, el fogsz esni, pont. Ha kicsit leszel sebes, amire jó a ragtapasz, azzal nem baszakszol. Ha varrni kéne, vagy a fél oldaladról lejött a bőr, akkor meg úgyis mindegy. Persze azért nálam is van a táskában, de sosem használtam.

Kard, pisztoly, gépkarabély

A vaddisznó nem bánt, ha meglát téged, elszalad. Esetleg veled szalad. Ha feléd szalad, akkor meg mindegy, mi van nálad, ki kell térni az útjából. A vadaknál sokkal veszélyesebbek a hülyén nevelt kutyák, illetve maguk az emberek - ha nagyon úgy érzed, egy paprika-spray-t tarthatsz magadnál.

Frissítés

Hát ez egy elég komplex téma, személyfüggő, ki mit bír/szeret/igényel, illetve van tudományos háttere is, aminek érdemes utánanézni idővel. Kb. azt írom le, amit én csinálok.

Rövid - < 10 km/1 óra

Nemigazán kell semmi, nyáron esetleg egy kis víz.

Közepes - kb. félmaratonig

Fél óránként kb. 2 deci iso, óránként kb. 1 csokis műzliszelet, sótabi.

Hosszú - félmaraton fölött

Nekem itt válik érdekessé a dolog. Régebben ide is a műzliszeletes módszert alkalmaztam, esetleges szölöcukorral kiegészítve, de 30-35 km környékén ez (nekem) kevés kezd lenni, éhes leszek, érzem, hogy nincs elég cukor.

Úgyhogy elkezdtem energiazselét (sajátot, mert amúgy drága) fogyasztani - fél óránként 3-4 korty, ~2 deci isoval lekísérve, és eddig működik, a Vérmókuson (52km) pont elfogyasztottam a teljes adagot, ami belefért egy fél literes kulacsba, de egy pillanatig nem éreztem, hogy gond lenne. Aztán, hogy a rendes ultra távokon mi van, arról személyesen nem tudok nyilatkozni, de már ilyen távon látszik, hogy nem akkor kell enni/inni, amikor éhes vagy, és nem azt, ami eszedbe jut, hanem tudatosan, kiszámolva bevinni a szénhidrátot - nem túl keveset, mert elfogy, és nem túl sokat, mert korábban távozik, mint ahogy szeretnéd.

Versenyek, túrák

Egyedül sem rossz futni, de társaságban mégjobb! Vagy nem. Rengeteg verseny van, kb. minden hétvégére jut valami, rövidebb/hosszabb/ultra, városi/terep, egyéni/váltó, … Érdemes kipróbálni őket, mindenkinek más jön be.

Én pl. nagyon szeretem a hosszabb terepváltók hangulatát, ahol persze mindig jön valami váratlan, amit meg kell oldani, de magát a versenyzést pl. annyira nem, feleslegesen túlpörgöm, úgyhogy mostanában elkezdtem teljesítménytúrákra járni, amiken nincs megtiltva, hogy gyorsabban szedd a lábad, van idő megállni beszélgetni az ellenőrzőponton, vagy kicsit setálva együtt haladni másokkal, és közösen keresni az éjszakai erdőben esőben/ködben az ellenőrzőpontot.

Végszó

Amióta stravat használok (2020 ősze) összesen 7143 km-t futottam, 186 ezer méter szintemelkedéssel, főként erdőben, azon belül is a Budai-hegységben. Sok jó arcot ismertem meg, kb. minden futáson látok valami újat, érdekeset, találkozok vadakkal (aki egyre szelídebbek), és egyre tovább akarok futni. Mondjuk ez lehet csak az endokannabioidok hatása 😉

Saját készítésű energiazselé

Mon, 21 Aug 2023 00:00:00 +0000

Az energiazselék mocskos drágák, úgyhogy úgy döntöttem, hogy csinálok magamnak.

Íme a recept, amit használtam:

200g maltodextrin
50g fruktóz
10g citrullin-malát
1000mg ascorbinsav (vitamin C)
200mg koffein
2 összezúzott sótabletta
- 400mg Na
- 80mg K
- 30mg Mg
2 teáskanál kólás BCAA (már csak az íze miatt is 😉)

Bár elsőször nem gondoltam volna, de a fenti mennyiség simán feloldódik ~3-4 deci vízben - lassú melegítés mellett -, és megmarad annyira folyékony, hogy egy szilikon kulacsból könnyen fogyasztható, egy fél literesbe épp belefér.

A végeredmény kb. 200 kalóriát és 40 mg koffeint tartalmaz decinként. (Egy átlagos Red Bull energiaitalnál ez 46 kalória és 32 mg koffein.) Tehát átlagos hétköznapokon, üdítőként nem ajánlom.

A teszt

Tegnap egy 30km-es terepfutásra mentünk a Pilisbe, ilyenkor általában óránként egy csokis műzliszelettel szoktam működöképesen tartani magam, a felesben kevert iso mellett, de most ehelyett kb. fél óránként ittam egy rendesebb kortyot a lötyiből - a végére kb. a 2/3-a fogyott el.

Nem szoktam zseléket használni, de ez működni látszik, szinte azonnal éreztem a lökést, és a gyomromnak sem lett semmi baja közben. Persze nem futottunk gyorsan, de ahhoz képest, hogy mocskos meleg lett, és a pára miatt levegőt sem lehetett kapni nagyon, kb. el sem fáradtam a végere. Az ízén még lehet kicsit dolgozni - valami plusz savanyú kell bele, mert még túl édes -, de amugy frankó.

Pénzügyek

Hirtelen rákeresve, egy random 32g/100kcal-os gél 960Ft. Persze van olcsóbb, lehet egyszerre sokat venni, de most legyen ez a referencia.

A fenti mennyiség a saját cuccból kb. 1000kcal-nak felel meg (tehát ~10 adag), lássuk mibe került (netről, gyúrós webshopból rendelve):

maltodextrin: 1490/kg - 300 Ft
fruktóz: 1990/kg - 100 Ft
aszkorbinsav: 1890/150g - 13 Ft
koffein: 1790/60db - 30 Ft (ebből lehet duplázok legközelebb)
sótabletta (i:am, ez volt itthon, tuti van olcsóbban): 6000/120db - 100 Ft
BCAA: 5490/250g - (~5g) 110 Ft

Összesen: 65 Ft / adag - kb. 15-szörös az árkülönbség (BCAA-val, luxi sótabival, …), és a csomagolóanyagot sem hagyjuk el véletlenül az erdőben futás közben…

Persze lehet, hogy nem olyan jó, mint a bolti. De az is lehet, hogy jobb. 😉

Note

Mon, 10 Oct 2022 21:06:15 +0200

A legtöbb bejegyzésem a kollégáimnak tartott kiselőadások vázlatai, és lusta voltam lefordítani őket, szóval érdemes az angol részben nézelődni :)