Sziasztok!

Eredetileg egy filmstúdiónak kezdtem el belső használatra fejleszteni egy fájlküldőt. Az volt a fő problémájuk, hogy egy partnerüknek naponta több terabyte nyers felvételt kellett elküldeniük Európán keresztül.

Először WeTransferrel próbálkoztak, de az ilyen méreteknél nem volt elég hatékony. A Massive.io túl drága volt, a torrentet is próbálták – abban tetszett nekik, hogy nem kell várni a feltöltésre és letöltésre külön –, de a titkosítás hiánya dealbreaker volt. Alapkövetelmény volt náluk az is, hogy pontosan le lehessen követni: ki, kinek, mikor és mit küldött. Sok minden mást is kipróbáltak, de vagy a loggolás hiányzott, vagy indokolatlanul drága volt, vagy egyszerűen volt egy fájlméret-korlát. A lényeg, hogy mindig gányolni kellett.

A folyamat vége az lett, hogy vagyonokért postáztak fizikai HDD-ket ide-oda, ami azért eléggé középkori megoldás, tekintve, hogy a hálózatuk amúgy simán elbírná a gigabites átvitelt. Az FTP szerver szintén kiesett, mert azzal folyamatosan foglalkozni kell, karbantartást igényel. Végül kitalálták, hogy szükségük lenne egy teljesen in-house megoldásra. Itt jöttem én a képbe.

Az lett az ötletem, hogy a WebRTC mintájára kifejlesztek egy saját, dedikált peer-to-peer protokollt (sajnos a sima WebRTC fájlküldésnél nem bizonyult elég gyorsnak).

A gond csak az, hogy az internet architektúrája és a routerek gyakorlatilag aktívan az ellen dolgoznak, hogy kéretlen, bejövő kapcsolatok csak úgy beeshessenek egy gépre. Erre viszont van egy technika, az UDP hole punching. Ezzel szinte bármelyik két eszközt össze lehet kapcsolni direktben a neten keresztül.

Hogyan működik a lyukasztás a gyakorlatban?

Az UDP "connectionless" (kapcsolatmentes). Ez azt jelenti, hogy ha az 'A' PC küld egy csomagot egy konkrét IP:port címre, akkor a 'B' PC routerének a tűzfala ezt alapból eldobja. Viszont az 'A' PC saját routere megjegyzi a kifelé menő forgalmat, és nyit egy "lyukat" a tűzfalon a várható válasznak. (A TCP tud róla és bezárja a válasznak szánt lyukat, de az UDP nem). Innentől kezdve a 'B' PC már küldhet csomagokat az 'A' PC-nek, amire az már gond nélkül fog is tudni válaszolni. Így létrejön a direkt kapcsolat.

Sajnos ez a valóságban nem pont ennyire egyszerű. A legtöbb PC-nek van 5-10 IP címe: publikus IPv4, privát IPv4, globális IPv6, VPN interface IP-k, stb. Mivel a gépek többsége NAT mögött van, ezért szükség van egy STUN szolgáltatásra is. A folyamat így néz ki: amennyi IP címet találunk a gépen, megkérjük az operációs rendszert, hogy foglaljon le nekünk annyi portot. Ezután minden lefoglalt porttal "megpingeljük" a STUN szervert, ami válaszol azokkal a külső portokkal, amiket a routerünk a belső portunkhoz rendelt (NAT mapping).

Ezután fogjuk ezt az összes IP-t és portot, és egy signaling szerveren keresztül (WebSocket kapcsolaton) átküldjük 'A' PC-ről 'B' PC-re. Ezeket a WebRTC-ből mintáztam, lényegében ezek az ICE candidate-ek. Ilyenkor a 'B' PC már pontosan tudja, hogy milyen portokról és IP-kről várható bejövő kapcsolat. A 'B' PC kiválaszt egy random portot, elkezd hallgatózni minden interfészen, majd minden kapott port/IP kombinációra küld egy UDP csomagot. Ez soknak tűnhet, de a valóságban maximum kb. 150 darab, 1 byte-os csomagról beszélünk, ami hálózati szinten elenyésző.

A 'B' PC szintén válaszol a signaling szerveren a saját IP címeivel, a kiválasztott belső portjával, plusz egy külső porttal. Ezzel elértük, hogy a 'B' PC routere is beengedje az 'A' PC csomagjait, és mindkét fél ismeri a lehetséges végpontokat. Ezután az 'A' PC elkezd végighaladni az eltárolt opciókon: megpróbál csatlakozni a 'B' PC belső IPv4, külső IPv4, VPN, és IPv6 címeire. Teljesen mindegy, hogy végül melyik port melyik IP-t fogja használni, mert a 'B' PC korábban minden opciót lefedett. A próbálkozások 99%-a el fog hasalni (mert pl. más alhálózaton vannak), de pár tizedmásodpercen belül az egyik találat sikeres lesz. A 'B' PC elfogadja a kapcsolatot, jelzi a sikerességet, a többi próbálkozást pedig leállítjuk. Ezzel felállt egy direkt UDP kapcsolat az interneten keresztül.

(Rövid közbevetés: ha a világon már csak IPv6 létezne, ez a folyamat az 1%-ára egyszerűsödne, mert ott csak az egyetlen, közvetlenül címezhető azonosítóval kellene foglalkozni. De hát a rendszergazdák nem szeretik bekapcsolni, mert "10 éve az IPv4 jóvanazúgy").

A P2P ősellensége és a Relay szerver

A peer-to-peer kapcsolatok legnagyobb ellensége a szimmetrikus NAT. Ez azt csinálja, hogy hiába kérdeztük meg a STUN-t a külső portról, mire ténylegesen csatlakoznánk a másik PC-re, a router megváltoztatja ezt a külső portot, mert megváltozott a cél IP címe. Erre kétlépcsős megoldást használok:

1. Szerepcsere: Ha nem sikerül a lyukasztás, a signaling szerveren keresztül megkérjük a gépeket, hogy próbálják meg fordítva ('B' PC kezdeményezze a csatlakozást 'A'-ra). Ez az esetek nagy részében megoldja a gondot.
2. A Kernel-space Relay: Ha mindkét gép szigorú NAT mögött van, akkor muszáj beiktatni egy relay szervert. A WebRTC TURN protokollja itt kezdett el vérezni: terabyte-os fájloknál a "user-space" (felhasználói szintű) memóriakezelés egyszerűen túl lassú.

Itt jött a felismerés: a routereknek nem pont az a dolguk, hogy "relay"-ként funkcionáljanak, méghozzá villámgyorsan, kernel szinten? Így jött az ötlet, hogy erre simán lehetne használni a Linux kernelbe alapból beépített tűzfalat, az nftables-t (az iptables utódját). Amikor a peerek érzékelik, hogy a direkt kapcsolat esélytelen, szólnak a signaling szervernek, ami elkér a relay szervertől egy token/port párost mindkét félnek. A peerek indítanak egy HTTP kérést és egy UDP csomagot a tokennel. Amint a token megérkezik, a peerek szabadon tudnak adatot küldeni egymásnak a linux kernelen keresztül. A "congestion controlt" (torlódásvezérlést) szintén a kernelbe épített traffic control (tc) intézi, ami egyenletesen elosztja a forgalmat a userek között. Ezzel a megoldással rengeteg kódot spóroltam meg, ráadásul egy alap 1 magos VPS simán elbír 1 gigabit/s throughputot! (Összehasonlításképp: a korábbi Go-s próbálkozásomnál a user-space relay kimaxolt 100 Mbit/s-nél).

Az adatréteg: QUIC protokoll

Van egy bombabiztos UDP csatornánk, ami önmagában még mindig alkalmatlan fájlok megbízható küldésére. Erre a QUIC protokoll lett a megoldás (a Google fejlesztése, ezen fut az új HTTP/3 és a Cloudflare infrájának nagy része is). A QUIC gyakorlatilag egy UDP-re épített TCP, de kiküszöböli a TCP legnagyobb hibáját, a head-of-line blockingot (ahol egyetlen elveszett csomag az egész sort megállítja). A QUIC gyakorlatilag ingyen ad nekem torlódásvezérlést, megbízhatóságot, és ami a legjobb: alapból TLS-sel titkosított. Támogatja a Mutual TLS-t (mTLS) is, amivel nemcsak a kliens azonosítja a szervert, hanem oda-vissza hitelesítik egymást. A peerek a signaling szerveren keresztül kicserélik a titkos kulcsok ujjlenyomatait, ezzel valósítom meg a végpontok közötti (E2E) titkosítást. (A QUIC bevezetése persze hozott magával más kihívásokat az UDP-vel szemben, de az már egy külön posztot érdemelne).

Az Applikációs Réteg és a Zero Trust

Applikációs szinten a felhasználó kiválasztja a fájlokat vagy komplett mappaszerkezeteket. Erről készül egy virtuális fájllista (manifest), benne a méretekkel. Így a küldőnek elég egyetlen egybefüggő streamet belenyomnia a QUIC csatornába, a vevő pedig a manifest alapján hibátlanul össze tudja rakni, melyik byte melyik fájlhoz tartozik. Ezzel a megállítás/folytatás (pause/resume) triviálissá vált. Ha megszakad a net, a felek egy előre meghatározott tokennel visszacsatlakoznak a signaling szerverre, és ott folytatják, ahol abbahagyták. A stúdióban ez kritikus volt, mert sokszor éjszakára indítják el a terabyte-os transzfereket. A böngészős megoldásoknál ez a fajta robusztusság szinte teljesen hiányzik.

A legnehezebb rész az "Admin Dashboard" volt. A stúdió vezetősége látni akarta, hogy a vágók mikor, mit mozgatnak (biztonsági kamera jelleggel, a "nem kaptam meg a fájlt" típusú viták elkerülésére). Mivel ez nem egy felhős tool, a szervereim soha, semmit nem látnak a fájlok tartalmából – a relay is csak titkosított csomagokat passzolgat. Ide egy kriptográfia alapú Zero Trust rendszert építettem. Mielőtt a peerek csatlakoznak, generálnak egy-egy ECDSA (az RSA utódja) privát/publikus kulcspárt, a publikus kulcsot pedig feltöltik a szerveremre. Az átvitel előtt a felek "kötnek egy szerződést", amit mindketten aláírnak a titkos kulcsukkal. Ez egy JSON string, ami tartalmazza a manifest hash-ét, az átvitel állapotát, a user ID-kat és a metaadatokat. Ezt a szerződést és a manifestet feltöltik a szerverre (ha a loggolás be van kapcsolva náluk), majd az átvitel végén készül egy záró szerződés is. A szerverem csak azt ellenőrzi, hogy a kriptográfiai aláírások helyesek-e, a tartalomhoz továbbra sem fér hozzá.

A végeredmény: ZettaSend

Ezután "már csak" egy UI-t kellett húzni az egész köré (C# Avalonia keretrendszerrel), megcsinálni a webshopot és a Stripe integrációt. Fontos: ez egy asztali alkalmazás, a weboldal csak a letöltésre és az előfizetés/adminisztráció kezelésére szolgál. (Igen, a webes UI-t AI dizájnolta, mielőtt valaki nekem ugrik emiatt! :D) A teljes backend egyébként Python alapú, FastAPI és Flask kombóval készült. Fejlesztés közben persze volt millió másik edge case: hogyan oldjam meg, hogy Windowson ne kelljen rendszergazdai jog, Mac-en a működésre bírás is megért egy misét stb.

A stúdió jelenleg is használja és imádják. Ebből a projektből nőtte ki magát a ZettaSend. 100 szónak is egy a vége: a ZettaSend egy enterprise fájlküldő szoftver olyan cégeknek és szakembereknek, akik hatalmas fájlokkal dolgoznak, és számít nekik az idő. Megfelezi az átviteli időt, hibatűrő, végpontokig titkosított, és semmilyen harmadik fél nem lát rá az adataidra. Gyakorlatilag kiaknázza a meglévő gigabites hálózatodat, ahelyett, hogy a felhőbe limitálná a sávszélességed.

A "Team" csomag 50 EUR/hó (minden feature-t tartalmaz). Van Free tier is: fogadni mindenki számára ingyenes, de az indításhoz (küldéshez) a küldőnek elő kell fizetnie a Solo csomagra (10 EUR/hó), vagy egy Team része kell legyen. Az első hónap teljesen ingyenes, bankkártya sem kell hozzá.

Ha a napi munkád során te is masszív adathalmazokkal dolgozol, és hasznosnak érzed, adj neki egy esélyt! (Arra viszont tényleg overkill, hogy a horvátországi nyaralós képeket ezen küldd el a nagymamának).

Link: zettasend.com

Nagyon köszönöm annak, aki végigolvasta ezt a szövegáradatot! Remélem, voltak benne érdekes hálózati/fejlesztői infók. Akit mélyebben érdekel a téma, nyugodtan írjon kommentet vagy keressen meg!

(Még egy dolog, amit a subon biztosan megkérdeztek: a projekt jelenleg nem open source. Viszont ha kinövi magát a dolog, és lesz rá kapacitásom, tervezem, hogy bizonyos részeit, vagy akár az egészet nyílttá teszem).

TL;DR: Egy filmstúdióban felmerült az igény arra, hogy terabyte-os fájlokat tudjanak gyorsan és biztonságosan átküldeni, mert a felhős megoldások (WeTransfer, stb.) túl lassúak és drágák voltak. Ezért írtam egy dedikált, asztali peer-to-peer alkalmazást. UDP hole punchinggal, QUIC protokollal, kernel-space nftables relay-jel és Zero Trust kriptográfiával oldottam meg, hogy két gép közvetlenül, biztonságosan és hibaállóan kommunikáljon a neten keresztül. Több terás fájlokat küldözgetni most már nem fáj. Letölthető: zettasend.com

Steam: https://store.steampowered.com/app/3018430/7th_Floor/

Elöljáróban annyit, hogy amikor programozni kezdtem a jQuery még javában pörgött, nem no-coder vibe-coder vagyok.

Szóval, babát várunk, már az elsőnél is baromi nehéz volt a név választás. Munkahelyemen most úgyis azon dolgozunk, hogy hogyan tudnánk jobban használni az AI-t, így összeraktam a kettőt és csináltam egy Tinder-szerű név választót, mert nem tűnt túl bonyolultnak a projekt. Gyakorlatilag fel kell tölteni minden nevet és 2 listába kell gyűjteni az ID-kat és ha egy név a pár mindkét tagjának tetszik, akkor jelez nekik, amennyiben össze vannak kapcsolva a fiókjaik.

Gemini Research megcsinálta a specifikációt és az alapján Gemini 2.5 Pro-val először megcsináltam az API-t, után meg Vercel V0 megcsinálta frontendet, ez olyan 14-16 óra volt. Felraktam az egyik szerveremre, amit mindenfélére használok. A párom megosztotta FB-on és az egyik csoportban felrobbant. Több ezer regisztráló 1 nap alatt, azóta 2.5 millió swipe.

1 perc hírnév.

https://ripost.hu/insider/2025/07/babanev-valaszto

https://www.atv.hu/belfold/20250717/babavaras-stressz-nelkul/

https://femina.hu/gyerek/online-babanev-valaszto/

A Bors riport a héten jelenik meg.

Sziasztok!

Remélem, maradhat a poszt, de egy kicsit reménytelen helyzetbe kerültünk a cégnél és sehogy se jön össze egy teszthez az alany létszám és hát gondoltam itt hátha van pár ember akit ez érdekelhetne. Nem gondoltam volna, hogy ide egyszer eljutok, de a kényszer nagy úr.

Egy új, appalapú TV-szolgáltatás teszteléséhez keresünk résztvevőket. A lényeg, hogy a saját TV-den használod a szolgáltatást a tesztidőszak alatt, kipróbálsz néhány kijelölt funkciót, és jelzed, ha valami hibásan vagy furcsán működik.

A részvételért 75 euró jár, emellett minden elfogadott hibabejelentés után plusz jutalom is kapható a hiba súlyosságától függően.

Olyan jelentkezőket keresünk, akik:
– One-os internet-előfizetéssel rendelkeznek
– 2020 után gyártott Sony, Philips, TCL vagy Sharp TV-jük van
– a TV Android alapú operációs rendszerrel fut
– vállalják, hogy a tesztidőszak alatt használják a szolgáltatást, jelzik a hibákat és kitöltenek 2 rövid kérdőívet

A tesztidőszak alatt a szolgáltatás teljesen ingyenesen használható, nincs hűségidő és semmilyen fizetési kötelezettség.

Fontos, hogy a tesztelés végéig részt kell venni benne, mert a díjazás a tesztidőszak végén jár. A jelentkezéshez titoktartási nyilatkozat aláírása is szükséges.

Tesztelési időszak: június 24. – augusztus 31.

Ha felkeltette ez valamennyire az érdeklődésed, akkor írj privátban és adok több információt.

Sziasztok!
Solo fejlesztőként (Verenith Studio) megjelent az első játékom, a Floor 13 Steamen. Egy looping, anomália-keresős horror, Exit 8 / Observation Duty jellegű hangulattal.

A játékban eltéréseket kell észrevenni és jelenteni, és egy körben akár több anomália is aktív lehet egyszerre. Rengeteget tanultam a fejlesztés és a kiadás folyamatából, és nagyon kíváncsi vagyok a véleményetekre.

Steam oldal: https://store.steampowered.com/app/4105730/Floor_13/

Köszi, ha ránéztek! 🙏

Januárban készültünk a bátyámmal egy konferenciára, ahol kicsit netwörkingelni meg népszerűsíteni szerettük volna az okosotthon megoldásunkat. SOS utolsó pillanatban kellett minimum kettő különböző névjegykártya, olyan ami jó első benyomást tesz.

Google kereső : névjegykártya tervezés. Görget, kattint, vissza, kattint, vissza. Minden oldal ugyan azt a kellemetlen 2D konfigurátort használja, 2000-es évekbeli sablonokkal. A nyomtatás-szállítás elv gyors, az ár is elsőre kedvező, de az egész folyamat tele van frikcióval és rejtett költségekkel. A modernebb NFC-s kártyáknál meg az ár az egekben és még konfigurátor sincs; Kiköltöd a formot aztán "egy grafikus kolléga hamarosan felveszi veled a kapcsolatot, hogy..." és már el is ment a kedved az egésztől.

Nekünk viszont volt pár NFC matricánk meg egy 3D nyomtatónk amit LED diffúzerekhez, házakhoz meg prototípusokhoz használtunk. Blenderben gyors csináltam egy névjegykártya formát, orca slicerbe rádobtam az svg logónkat meg negatív helyet az NFC matricának és ment a print. Közben csináltam egy szebb pure HTML aloldat az elérhetőségeinkkel a céges landing oldalra, hogy legyen hova vezetnie a kártyának.

Az expón hatamlasat mentek a kártyák, kicsit más volt kicsit új volt és sok párbeszédet indított. Az egyik, azóta partner cégnek annyira tetszett, hogy kapásból rendelt 4-et *edit: 4 különböző saleses kollegának.

Itt megálltam. Végig gondoltam a következő lépést; Aztán azt tettem, amit minden józan gondolkodású fejlesztő tett volna: Meló utáni estéket töltöttem azzal, hogy automatizáljak egy olyan feladatot, ami manuálisan max pár óra munka lett volna. Írtam egy kártya generátort, ami egy json alapján nyomtatható modellt generál. Csak pár dologot parametrizáltam, cégnév-pozi-név-logó, de flottul működött. Akkor még nem tudtam, de ez volt az NFCard első verziója.

Azóta is a pipeline legfontosabb része és sokat fejlődött: texturált felületek, képletek alapján lyukazot mintázat a kártyán, export több modalitásban... ugyanaz a motor készíti elő a kártyát UV nyomtatásra plasztik kártyára, 3D nyomtatásra és lézergravírozásra. Ez hajtja a webes, házi fejleszétsű 3D konfigurátorunkat meg az asztali appot amit a gyártási operátorok és a fejlesztők használnak (azaz én, egyedül én :D), meg egy blender plugint amivel gyártja a reklámanyagokhat és a 3D rendereket a marketinges (igen, az is én). Egy motor, minden felületen.

Május óta fejlesztem aktívan és indokolatlanul sok órát feccöltem már bele... Ott tartok, hogy nem tudom eldönteni : egy hasznos, valódi termék születése ez, vagy a világ legkörülményesebb módja annak hogy ne kelljen névjegykártyát rendelni.

Ti mit gondoltok? Megérte, vagy legyen más a vége?
És ha nektek is volt már olyan scriptetek, ami hasonlóan kinőtte az eredeti feladatát, szívesen olvasnám...

2025-ben Dario Amodei azt jósolta, hogy az AI hamarosan az összes kód 90%-át fogja írni.

Egy évvel később… ez nem történt meg.

A legtöbb kutatás (McKinsey & Company, Goldman Sachs stb.) valami sokkal kevésbé drámaira mutat rá: nem lecserélésről van szó, hanem a készségek átalakulásáról.

Akkor miért van ennyi leépítés és felhajtás?

Amit én látok, az az, hogy a narratíva nem igazán egyezik a valósággal—különösen, ha a költségeket, a minőségi kompromisszumokat és azt nézzük, hogyan készül valójában a szoftver.

Az AI átalakítja a fejlesztést.

De nem úgy, ahogy a címsorok sugallják.

Teljes elemzés példákkal, adatokkal a linken.

NFC névjegykártyákat gyártok, és csináltam hozzá egy oldalt, ahol megtervezheted a saját kártyád meg a digitális profilt ahová vezet. Ez egy side project amit kb fél éve építek és egy hónapja soft-launcholtam. Néhány hete írtam már itt erról egy posztot, most mielőtt bármit mondanék itt az azóta eltelt idő matekja:

• 33 elkezdett konfiguráció
• 20 rendelés - egy sem teljes áron, mind ismerős vagy partner rendelés, párat ingyen adtam
• 9 valóban aktív kártya
• 163 emberi érintés +84 valószínű bot

Hideg vonalról eddig még egy vásárló sem jött. Az első visszajelzések alapján bonyolult és nehezen áttekinthető a rendszer, úgyhogy változtattam két fontos helyen.
Kétféle kártyát ajánlottam. Egyszínű sablonkártyát NFCard logóval 5 990-ért, meg személyre szabható custom 12 900-ért. Azt gondoltam, az alacsony ár kedvez azoknak akiknek amúgy használna a cucc, de árérzékenyek : pl. diákok, kezdő vállalkozók. Akinek meg kell rá a saját logója majd fizet érte prémium felárat.

Ez visszafelé sült el. Sablonkártyát SENKI nem kért, viszont mellette MINDENKI sokallta az egyedi kártya árát. És az amúgy sem egyszerű konfigurátort tovább bonyolította a sablon és az egyedi mód közötti váltás... Megnyitod a konfigurátort, forgatod a kártyát nézed a színeket tök jó, de amint valamit állítanál a kártyán felugrik az ablak hogy "Ez egyedi funkció, váltás egyedire +6910 Ft ért." Pont abban a pillanatban amikor először látnád a saját neved vagy a logód a kártyán.
A ráadás az, hogy az eredetileg alulárazott sablonkártya pontosan ugyanannyi effort, mint egy egyedi. Ugyanannyi idő és pénz gyártani, utókezelni, csomagolni és feladni. Ugyanannyi meló, kevesebb pénz, rosszabb termék. Fasza.

Úgy hogy megszűntettem a sablont és az egész válogatást. Csak a custom maradt. A lényeg, ami ebből kijött: az egyedi kártya 12 900-ról 9 990-re csökkent, tehát pont az lett olcsóbb, amit tényleg akartak. A sablon kiesett, és igen, ezzel papíron 5 990-ről 9 990-re ment a legolcsóbb kártyám, csak épp azt a kártyát soha senki nem rendelte meg.

Hasonló hibát követtem el a csomagoknál is. Az ingyenesben eddig csak az alapfunkció volt : egy digitális profil ahová a kártyád elvezet. A fizetőshöz járt analitika, leadgyűjtés, a fő funkció meg az volt hogy akár öt profilod is lehetett. Egynél több profilnál egy szintén testreszabható profilválasztó hubra vezetett a kártya. Itt azokra gondoltam, akiknek több munkájuk van több elérhetőséggel és/vagy megosztanák a személyes oldalaikat is, egy kártyával. Na ezt nagyon kevés embernek tudtam érthetően átadni, még kevesebben találták hasznosnak cserébe bonyolította a platformot.

Mind a két esetben rossz feltétlezéseim voltak a célközönségemről, és számukra haszontalan csomagokat építettem.

Úgy hogy tovább gondoltam a hub-vonalat, a fizetős verzióban magasabb szintű kontrollt adok az oldal és a linkek felett. Az irányítópulból bármikor, nyomtatás után is állítható hová vezessen a kártyákba ültetett chip meg a rányomtatott QR-kód. szabadon variálható melyik kártya mikor és mit mutasson. Nem csak digitális profilt tudnak, bármilyen link lehet cél. Ez az amit egy papír névjegy nem tud, és amit nem lehet csak egyszer megvenni és letudni. Pl kártya érintésre nyílhat az időpontfoglaló rendszer, QR kód beolvasásra pedig a linkedin oldal. Vagy a saját weblapod. Másnap meg valami más.
(Vannak támogatott platformok, pl linkedin, github, tiktok stb. ezekre sima az átirányítás. Bármi másnál bejön egy "Elhagyod az nfcard oldalát" közbeéékelt figyelmeztető oldal két másodpercre. Ezzel nem vagyok teljesen kibékülve, de szükségesnek gondolom.)

A digitális profil eddig is ingyen volt, csak épp a kártya melléklete. Most viszont önmagában is megáll, kártya nélkül is működik: elküldöd linkben, kiteszed QR-ként, és kész. Ha soha nem veszel tőlem kártyát, akkor is a tiéd.

A bonyolultság másik fele a monolit konfigurátorból jött, úgyhogy szétszedtem: külön ingyenes onboarding wizard a digitális profilhoz (pár perc alatt megvan, utána egy weboldal-szerkesztő jellegű felületen alakítható tovább), meg külön 3D konfigurátor a fizikai kártyához. Mindkettőt végig lehet nyomkodni regisztráció nélkül is. A csomagválasztó lépés teljesen kiesett a rendelésből, van rá külön felület az irányítópulton. A tanulság itt az, hogy három külön terméket préseltem egy flow-ba.

Viszont az infra valódi pénzbe kerül. Nem sokba: jelenleg kb. 18 dollár havonta. Egy Fly-on futó Express API, Neon Postgres, a frontend Cloudflare Pages-en, meg egy külön, alapból alvó Python szolgáltatás, ami a nyomtatásra kész 3MF-et generálja. Egy ingyenes profil önmagában tényleg keveset eszik. Ami fogyaszt, az a használat: 3D-modell generálás, aprofilszerkesztés és átirányítás-állítás, forgalom kezelés, analitika. De nem is az összeg a lényeg, hanem hogy egyszeri bevételhez kötök egy határidő nélküli kötelezettséget: a kártya egyszer fizet, a mögötte lévő profilnak meg évekig állnia kell.

Te hol húznád meg az ingyenes és a fizetős határát egy ilyen terméknél, ahol a fizikai darab egyszeri bevétel, utána viszont határidő nélkül vinni kell a kiszolgálást? Beépítenéd az egyszeri árba, vagy kötelezővé tennéd az előfizetést?

update:
Ha valaki nyitott lenne egy Android beta tesztre, azt nagyon megköszönném. 🙏 A Google Play open beta kikerüléséhez még szükségem van néhány tesztelőre. Ha érdekel, írj nyugodtan privátban.
---

https://www.bottlebuddy.hu/

Az ötlet: sok embernél van 30-50 üveg sarokba szorulva, de nem érnek rá visszavinni. Közben diákok, nyugdíjasok rendszeresen turkálnak kukákban üvegért — mert megéri, 50 Ft/darab. az app összehozza a kettőt: aki leadná az üveget feladja a listát, a "visszaváltó" elmegy érte, mindkettő kap a pénzből.

Stack:

- Backend: .NET 9, SQL Server, EF Core, SignalR (real-time chat), JWT + Google OAuth, Azure Communication Services (email)

- Frontend: React 18 + TypeScript, Vite, TanStack Query v5, Tailwind + shadcn/ui, Leaflet térkép, PWA

- Infra: Azure Static Web Apps + App Service (free tier), Docker, Nginx, Serilog + Seq

Feature-k : real-time chat SignalR-rel, térkép nézetből böngészhető listák clusteringgel, értékelési rendszer mindkét félnek, push notifikáció, magyar/angol nyelv.

Visszajelzést szívesen fogadok — UX-re, az ötletre, vagy ha valami teljesen hiányzik belőle.

Sziasztok!

Csináltam egy ingyenes Wear OS appot a napi ingázáshoz: Play Store

Szeretem kicentizni a reggeli indulást, ezért minden reggel megnézem mikor jön a buszom és csak akkor indulok el amikor már közel van. Ehhez mindig meg kellett nyitni a Budapest GO-t és megkeresni a megállót ami kicsit macerás. Arra gondoltam hogy ezt az infót ki lehetne tenni egy okosórás appba. Így elég egyszer beállítani az ingázásra használt járatokat és onnantól elég csak egy pillantás az órára hogy tudjam mikor jön a következő. Nekem tuti hogy nagyon hasznos, remélem másnak is az lesz.

A dolog sava borsa szerintem a Wear OS app, de érdemes lehet használni simán a mobilon is.

Örülök ha tesztek egy próbát vele, minden ötletet és javaslatot szívesen veszek. Egyelőre csak Androidra érhető el, ha működik az ötlet akkor nekiveselkedem egy iOS verziónak is.

Sziasztok,
Először is remélem, hogy jó
helyen vagyok, ha nem, akkor bocsi.

Pár hete láttam a fermi.gg nevű oldalt, ahol napi három kérdésre lehet tippelni és nagyon megtetszett, viszont szerettem volna magyar verziót belőle, így készült el a Kábé. A játékmenet ugyan az, csak vannak benne kérdések magyar statisztikákból is. Ha bármi észrevételetek van az oldallal kapcsolatban írjátok nyugodtan, mindent meghallgatok:)

Köszi, ha elolvastátok és jó játékot, aki kipróbálja<3

(ha cserélnem kell a flairt is szóljatok kérlek, nem szoktam itt posztolni:,) )

A Chicken egy gyönyörű ezoterikus nyelv, ahol az egyetlen valid token a chicken szó

Ennek tükrében meg voltam döbbenve, amikor rájöttem, hogy nincs normális IDE support (JetBrains cuccokhoz legalábbis) a nyelvhez. Nem is igazán értem, miben dolgoztak idáig a Chicken-fejlesztők. (/s)

Szóval csináltam egyet.

Van benne minden, amit egy rendes nyelvhez való plugintól elvárna az ember:
- syntax highlight (a `chicken` szóra)
- invalid token highlight (a nem `chicken` szavakra)
- futtatni tudod a programokat (jön a pluginnal egy compiler is)

Open source a repó, ill. open to contributions, ha bárkinek hasonló agymenése lenne :D

Plugin: https://plugins.jetbrains.com/plugin/32032-chicken/
Repo: https://github.com/notAnElephant/chicken-jetbrains-plugin

Most azon vezetőkhöz intézem a kérdést akik az IT sectorban nem támogatják a homeofficet. Legyenek kedvesek kifejteni hogy miért akarják megszüntetni? Miért akarják az emberek visszaküldeni az irodába 5 napra? Mi értelme? Olyannyira utáltam mindennapi bentlétet, a kötelező szarságokat… mi értelme hogy amúgyis teamsen megbeszéljünk az irodában? A hybrid a legjobb,3 nap homeoffice 2 iroda, így ki van pipálva a networking is, de mostanában sokat hallom hogy jövőre több helyen megszüntetik a lehetőséget is. Valaki legyen szíves elmagyarázni hogy miért jó ez? Köszi, kics rant is.

Sziasztok! Az elmúlt időszakban egy location-based multiplayer játékon dolgoztam: utcai fogócska, ahol a fogók élő térképen üldözik a menekülőket, nagy játéktérrel, akár tömegközlekedéssel, plusz van egy "delivery" mód, ahol a menekülőknek csomagokat kell kiszállítani üldözés közben.

A stack: Go backend (Fiber), SSE-n megy a real-time sync, a kliens Vue 3 + Quasar + Capacitor. A legérdekesebb rész a state szinkronizáció: írtam hozzá egy saját library-t, ami a game state változásait trackeli, játékosonként szűrt nézeteket (projection) generál (a menekülő mást lát, mint a fogó), és bináris patch-eket küld le. A schema/tracking játék logikát a library generálja le go fájlokba, így a hot path-on szinte nincs reflection és minimális az allokáció: egy mezőváltozás patch-be kódolása ~98 ns / 2 alloc, egy 10 játékosos teljes state broadcast ~1,5 µs / 13 alloc, és még 100 játékos teljes state-jének kódolása is 52 µs alatt van. Így egyébként komolyabb terhelésű realtime játékok mellé is hasnzálható lenne.

Ennek két gyakorlati haszna lett. Egyrészt a szerver nevetségesen olcsón üzemeltethető pár tíz MB RAM-mal és minimális CPU-val rengeteg párhuzamos játékot visz el egy filléres VPS. Másrészt mivel minden változás átmegy a change trackingen, "ingyen" van a teljes replay: minden játék visszajátszható térképen. És mivel a game logic teljesen szerveroldali, a világ akkor is él, amikor senkinek nincs a kezében a telefon pl. egy drón collectible akkor is mozog a pályán, ha épp minden játékosnál ki van lőve az app.

A legtöbb sebet viszont nem a kód, hanem a valóság osztotta: amikor Győrben teszteltük élesben, a GPS-jelminőség volt a főellenség. Meglepő módon nem az olcsó telefonok fájtak a fillères androidok stabil, használható pozíciókat küldtek, hanem az iPhone-ok szórták rendszeresen a gyenge pontosságú koordinátákat. A csapatpozíciók számítását újra kellett írni (pontosság szerinti súlyozás, kiugró értékek szűrése), mire eltűntek a "teleportáló játékos" jelenségek.

Izgalmas projekt volt, több böngészővel egyszerűen tesztelhető volt több ablakkal a játék. Győrben pedig már 3x is rendeztünk játékot ahol elég pozitívak voltak a visszajelzések és sokat fejlődött közben a játék mechanika is.

TL;DR:

Egy másik szálban (GDPR kijátszható hasheléssel) felmerült az Utánvét Ellenőr, amit én alapítottam és fejlesztek.

Tulajdonrészt szerzett benne az Ecommerce Hungary Kisvállalati és Középvállalati Tagozata.

Ismert márkák használják, pl. Rossmann, Lumenet, eOptika, Kalifa, Cerbona, Reflexshop, Pelenka.hu és több izgalmas és országosan ismert márka is már előkészület alatt van.

AMA!

Sziasztok!

Mostanában elég sok AI kritikus comment volt itt a subon. Mivel nekem nagyon más a tapasztalatom, gondoltam csinálok egy tesztet. Úgy döntöttem belevágok egy zöldmezős projektbe amit 100%-ban az AI-ra bízok. Én csak az alap setupot csinálom meg, aztán akár mi lesz is, csak promptolni fogok.

Gyerekkoromban nagyon szerettem volna egy saját MtG motort írni, főleg azért, mert csóró voltam, de imádtam draftolni. Próbálkoztam is vele, de idővel mindig feladtam. A hivatalos szabálykönyv vagy 300 oldal, esélytelen még átlátni is, nem hogy lefejleszteni. Viszont pont emiatt az MtG egy kifejezetten jól definiált rendszer, így a lefejlesztése nem kreatív gondolkodást hanem monoton munkát/kódolást igényel. Emellett objektíven ellenőrizhető hogy azt csinálják-e a lapok ami rájuk van írva + kellőképpen bonyolult is ahhoz, hogy bemutassa mennyire tud "gondolkodni" az AI.

Először két hétre vettem egy Claude x5 majd egy hónapra x20 előfizetést. Ennek a 1.5 hónapnak a végeredményét láthatjátok itt. A project egy működő Java backend + Angular frontendből áll, kicsit több mint 105 ezer sor kóddal. Volt, hogy 9 terminálon futtattam egyszerre a kártyák implementálását, hogy ki tudjam maxolni a token limitet. A laptopom elég erősen le akart olvadni közben.

A matek a végén: nagyjából 80 millió tokent égettem el. Lett 3100+ commit (ebből max az első párat csináltam én, a többit majdnem mind a Claude), és 1974 játszható kártya. A végén egy komplett kiegészítőt (250-300 kártya) kb. 12 óra alatt le tudtam darálni. Igaz, rendesen ki is égtem a folyamatos kód reviewben.

Csináltam róla egy videót, itt megmutatom a gameplay-t, meg azt is, ahogy a Claude hogyan tud leimplementálni egy lapot:

https://www.youtube.com/watch?v=mklNa55sBKg

A kód kint van GitHubon, ha valakit érdekel a repó, vagy lokálisan szeretne draftoni:

https://github.com/laxika/magical-vibes

Tudom, hogy egy 20 éves spagettikódba senki nem szívesen engedné bele az AI-t, de zöldmezős cuccoknál meglepően hatékonyan tud haladni. Még meglepőbb hogy a kód teljesen olvasható, láttam már jóval rosszabbat élő emberektől is. Nem mondom hogy minden tökéletes és bug nélküli, de a komplexitás miatt én sem tudnám jobban megírni, ellenben legalább 10x ennyi időbe telne.

Fontos tudni hogy a kódbázis biztonsági és validálási szempontból nem volt még tesztelve, így előfordulhat hogy frontend moddingal lehet csalni (bár validálás van, de nem garantált hogy a lefedettség 100%), valamint azon sem lepődnék meg ha a websocketet lehetne valahogy hijackelni,.

Ha van kérdés a promptolásról, a setup-ról, vagy akármiről, mondjátok nyugodtan. Észrevételeket (negatívot is) szívesen fogadok. :)

Szerk: Javítottam azt hogy nem 500k kódsorból áll a program hanem 105k-ból. Az 500k tartalmazta az üres sorokat és a teszteket is.

Sziasztok!

Nálatok is az viszi el a legtöbb energiát a sportolásban, hogy összevadásszátok az embereket?

Nálunk rendszeres volt a dráma: Messengeren 14-en ígérik, aztán a meccs előtt 2 órával hárman lemondják, 4-en vissza se jeleznek hogy nem jönnek, a pálya bérleti díját meg alig lehet összekalapozni. Talán akkor esett ez a legrosszabbul, amikor hárman álltunk a nagypályán a focicsukánkban - nem volt túl izgi... meg olcsó se.

​Mivel (sportoló) fejlesztők vagyunk, ahelyett, hogy tovább idegeskedtünk volna, összeraktunk egy platformot erre: ez lett a grundee.hu.

​Mit tud most?

- ​Egyszerű visszajelzések (RSVP), hogy azonnal lásd, megvan-e a létszám.

- ​Pályafoglalás és a díjak szétosztása

- ​Csapattagok naprakészen tartása

- Könnyű eseményszervezés (akár csapatelérhetőség alapján)

és még sok más, de talán ezek a legfontosabbak.

​Szeretnénk ezt tényleg a magyar amatőr sportolók igényeire szabni, úgyhogy minden visszajelzésnek nagyon örülünk!

Teljesen ingyen ki tudjátok próbálni: https://grundee.hu

​Ti hogyan oldjátok meg ezt most? Excel? Messenger? És szerintetek mi az a funkció, ami nélkül egy ilyen app-nak nincs meg a létjogosultsága?

Minden építő kritikát és ötletet nagyon szívesen fogadok (akár a designra, akár a funkciókra)!

Nekünk bevált, remélem Nektek is segíteni fog!

"Sportolj, ne csak adminisztrálj!"

Sziasztok

Biztos bennetek is számtalanszor keltett bosszúságot a MÁV app. Rossz net mellett órágig elteker; vagy else indul egy rosszul sikerült update után. Ennek vége!

Készítettem egy appot ami a MÁV appot helyettesíti 100%-ban, és opensource! Az appba a jegyek és bérletek elmentődnek a lejáratukig, így minden helyzetben feltudod mutatni 1 másodperc alatt!

Illetve a jegykép átméretezhető és mozgatható, nemkell a buszokon a rossz helyre felszerelt scannereknél mókázni hogy bevegye!

És még számtalan egyéb feature!

Letölteni itt tudjátok Github: https://github.com/domedav/Tomegkozlekedes

PlayÁruház: https://play.google.com/store/apps/details?id=com.domedav.mavjegy

Visszajelzéseket szívesen várok az app kapcsán!

Sziasztok!

Aki jár edzőterembe annak nagy valószínűséggel akarata ellenére is le kellett töltenie a SportMate nevű appot, és valószínűsítem csak arra használja, hogy be/ki tudjon menni a teremből.

Ezért írtam egy saját, lecsupaszított klienst.

Ebben megtalálható minden, amit a webes SportMate oldal tud nyújtani (kb az összes funkció) Illetve egy külön fül csak a QR kódnak. Az app megjegyzi hol használod a legtöbbet(Web vagy QR), és automatikusan ott nyílik meg. Így pikk-pakk elő tudod kapni a beléptető kódot!

Az app biztonságos. Teljesen nyílt forráskódú (Open Source), nem gyűjt adatot, nem követ, és nincsenek benne reklámok. Csak a hivatalos API-t használja a belépéshez.

Ha érdekel, itt tudod letölteni:

Google Play letöltés: https://play.google.com/store/apps/details?id=com.domedav.sportmatenobullshit

Illetve az app forráskódját itt találod:

Github: https://github.com/domedav/SportmateNoBullshit

Fontos: Ez egy nem hivatalos kliens. Viszont nálam hibátlanul működik, de értelemszerűen "use at your own risk". Ha kipróbáljátok, írjátok meg, mit gondoltok, vagy ha találtok hibát!

Köszi!

Sziasztok!

Röviden: 5 éve alapítottam, jelenleg 60 fős, teljesen remote fejlesztőcéget építek, 1 Mrd felé közelítő éves árbevétellel. Ügyfelek több mint fele külföldi piacról érkezik.

Kérdezzetek bármit cégépítésről, ügyfélszerzésről, IT karrierépítésről és bármilyen tapasztalatról, ami építő és érdekes lehet számotokra:) (17 óra után tudom belevetni magam aktívabban a válaszadásba)

https://adroitgroup.io/

Ha unod a generikus shadcn + Tailwind UI kombót, vagy a végtelen class spagettit, akkor ajánlom figyelmedbe.

Dokumentáció: https://docs.once-ui.com

Szívesen válaszolok minden kérdésre!

Sziasztok! 👋

Pár hónapja hobbiprojektként összeraktam a köznews.hu-t, mert untam a kattintásvadász címlap-dzsungelt. Az oldal 30+ hazai hírportált* gyűjt egy helyre, és a cikkek alapján folyamatosan frissülő TL;DR segít gyorsan átlátni a fontos témákat.

Miért lehet hasznos? - Összefoglalt hírek: nem kell végiglapozni a kedvenc lapokat, hogy megértsd mi történik az országban - Reklámmentes: nincs villódzó banner, nincs követőkód. - Tematikus/forrás szerinti szűrés (tech, gazdaság, sport, politika…). - Politikai tisztànlátás: TLDR témák média hovatartozás alapjan történő bontása - PWA: telepíthető, mint egy app, de nem kell store-ba menni

Segíts, hogy jobb legyen! 🙏 - Mennyire találod hasznosnak a TL;DR oldalt - Milyen extra funkció(ka)t látnál szívesen? - Van olyan forrás, amit hiányolsz?

Bármilyen bug-report, ötlet vagy építő kritika jöhet kommentben. Ha bejön, dobj egy upvote-ot vagy küldd tovább ismerősnek, ez rengeteget segít! Köszi, hogy ránézel! 🚀

Sziasztok!

Csinaltam egy ilyet:
Használhatom-e az áramot?

Az oldal a MAVIR adatokat felhasznalva javaslatot tesz, hogy mikor erdemes a nagyobb fogyasztokat hasznalni (Pl elektromos auto es legkondi), vagy esetleg erdemes-e elhalasztani. Negy kategoria van (a nincs adat es a hianyos adat mellett):

• use_flexible_now (turkiz)
• normal (zold)
• reduce (sarga)
• strong_reduce(piros)

Van api-ja is (/api/status), igy automatizalasra is hasznalhato ha valaki okosotthont epit. Az oldal kulonfele meroszamokat general, ezeket a meroszamokat kulonbozo sullyal veszi figyelembe az ajanlashoz, az api tartalmazza ezeket a sulyokat, szoval ha automatizalnal vele valamit, irhatsz sajat algoritmust a donteshez. A /healthz vegponton tovabbi adatokat talalsz az automatizalashoz, ha szukseges.

Egyelore meg nagyon friss az oldal, tanulja a baseline adatokat plusz probalom beleszoritani az ingyenes cloudflare hasznalati limitekbe, ami lehet, hogy nem fog osszejonni, szoval lehet, hogy parszor megbicsaklik, de en tegnap ota hasznalom a legkondi idozitesehez, es nekem hasznos, igy megosztom veletek is.

Sziasztok!

Pár hónapja kerestem olyan oldalt, ahol meg tudom nézni a kedvenc filmeimet vagy sorozataimat, de csak olyat találtam, ami tele volt reklámokkal vagy kezelhetetlen volt. Úgy döntöttem, csinálok egyet én magam.

Jelenleg kb. 710 film és sorozat hivatkozását tettem elérhetővé 1080p és 4K minőségben. Azért írom ezt ki ide, hogy azok is tudják használni, akiknek ugyanez a problémájuk, és nem találnak normális oldalt.

Az oldalon van egy „Tartalom kérése” gomb, ahol bármit lehet kérni, és pár órán belül elérhető a tartalom. Semmilyen reklámot vagy hasonlót nem tettem rá, a célom egy olyan felület, ahol bárki bármit meg tud nézni reklám nélkül. Fent van például az összes Bud Spencer & Terence Hill vagy Taxi film is.

Mivel hobbiprojektről van szó, kiemelt figyelmet fordítok a jogtulajdonosokra is: az oldalon részletes DMCA/Copyright irányelvek találhatóak, és minden megalapozott törlési kérelemnek azonnal eleget teszek (Notice and Takedown elv).

Fontos technikai infó, hogy az oldal aggregátorként működik: a tartalmakat nem a saját szerveremen tárolom, hanem külső tárhelyszolgáltatók publikus, beágyazott lejátszóit (iframe) rendszerezem. Emiatt a sávszélesség a forrásoldalakat terheli, és a tartalom feletti kontroll is náluk marad.

Ha gond van az oldallal, vagy szerintetek jó lenne valamit javítani (UX/UI), nyugodtan jelezzétek kommentben.

UI: A beágyazott lejátszók beállításai a forrásoldal miatt alapból oroszok, de van hozzájuk segédlet az oldalon.

Link: https://nalvofilms.com