Szakmai cikkek
Így fejlesztünk – mérnöki írások a gyakorlatból
Határozott véleményű cikkek arról, hogyan építünk mobil- és webtermékeket a HyperCode-nál: melyik stacket választjuk alapból, mely gyakorlatokhoz ragaszkodunk – és miért.
Mobil · Stratégia
Flutter, React Native vagy natív? Így döntünk a gyakorlatban
Mind a négy stackkel dolgozunk – Swift, Kotlin, Flutter és React Native –, így egyik keretrendszer mellett sem kell kardoskodnunk. Ezt a döntési folyamatot járjuk végig minden ügyfelünkkel, azokkal a kérdésekkel együtt, amelyek többet nyomnak a latban, mint maga a technológia.
Cikk elolvasásaAI · Fejlesztés
Így veszünk át egy AI-val épített kódbázist: a felmérési checklistünk
Egyre több alapító kopogtat nálunk olyan appal, amelyet maga rakott össze AI segítségével. Működik, demózható, néha már felhasználói is vannak – csak éppen nem lehet tovább fejleszteni. Elmondjuk, hogyan mérjük fel, amit hoznak, mi alapján döntjük el, mi maradhat, és hogyan lesz belőle termék úgy, hogy közben nem dobjuk ki, amit tanultak.
Cikk elolvasásaFlutter · Állapotkezelés
Miért Riverpoddal kezeljük az állapotot a Flutter-alkalmazásainkban
Az állapotkezelés kérdését minden Flutter-projektben el kell dönteni. Több megközelítéssel is szállítottunk már éles appot, és végül a Riverpod lett nálunk az alapértelmezés. Leírjuk, miért – és azt is, hol nem ez a jó válasz.
Cikk elolvasásaAI · Architektúra
LLM-funkciók élesben: mi marad állva, amikor igazi felhasználók használják
Egy látványos LLM-demót egy délután alatt össze lehet rakni. Egy olyan LLM-funkció viszont, amely igazi felhasználóknál is jól viselkedik – igazi válaszidővel, igazi költségekkel és igazi hibalehetőségekkel –, már mérnöki projekt. Összeszedtük, mit tanultunk a saját termékeinkbe és ügyfeleink rendszereibe épített AI-funkciókból.
Cikk elolvasásaWeb · Architektúra
Miért Firebase + Next.js + Vercel az alapértelmezett stackünk adminalkalmazásokhoz
Szinte minden mobiltermék mellé kell előbb-utóbb egy back-office is: egy adminfelület, ahol az ügyfél kezeli a felhasználókat, a tartalmakat és az adatokat. Ezekhez nálunk mindig ugyanaz a stack kerül elő – és az indoklás nagyrészt arról szól, mit nem kell megépítenünk.
Cikk elolvasásaMobil · Architektúra
Offline-first: amikor a telefon az iroda
Két általunk fejlesztett termék – a Snacker és az Invoice Guru – nem a felhőt, hanem magát az eszközt tekinti az adatok elsődleges forrásának. Ez nem kényszerű kompromisszum volt, hanem tudatos architekturális döntés. Megmutatjuk, mikor érdemes offline-first megközelítést választani, és mi változik tőle.
Cikk elolvasásaMinőség · Tesztelés
A unit teszt megtérül – a UI-teszt pedig valódi eszközre való
A tesztelés rendszerint az első tétel, amit kihúznak a mobilos büdzséből – az értéke ugyanis láthatatlan, egészen addig a napig, amíg baj nem lesz. Megmutatjuk, hogyan gondolkodunk a tesztpiramisról a gyakorlatban: az üzleti logika unit tesztjeitől az Appiummal automatizált, device farmon futó UI-tesztekig.
Cikk elolvasásaFolyamat · Együttműködés
Minden funkcióhoz írott spec – mert az elképzelés fejlesztés közben is változik
Az ügyfélprojektek legdrágább pillanata nem egy bug, hanem az, amikor egy követelmény félkész kódban változik meg. A mi válaszunk nem látványos, de működik: nálunk egyetlen funkció fejlesztése sem indul el addig, amíg nincs róla egy rövid, írott spec, amit az ügyfél jóváhagyott.
Cikk elolvasásaMobil · Release
Kiadás mindkét store-ba, dráma nélkül
Az app megírása csak a munka fele. A másik fele az, hogy be is kerüljön az App Store-ba és a Google Playre – és hogy a release-ek unalmasak, gyakoriak és visszafordíthatók maradjanak. Ez önálló szakma. Így csináljuk a saját termékeinknél és az ügyfeleink appjainál.
Cikk elolvasásaMobil · Monetizáció
In-app előfizetés fájdalom nélkül
Az előfizetés elsőre megoldott problémának tűnik: mindkét store ad hozzá API-t, mi lehet ebben nehéz? Kiderül, hogy nehezebb, mint bármelyik másik „standard” mobilfunkció. Így építünk előfizetést az olyan appokba, mint az Invoice Guru – és ezért nem írjuk meg többé kézzel ezt a réteget.
Cikk elolvasása