Danilo Jezernik_

• 
  01namizjev razvoju

  AI Development Studio →

  Namizni orkestrator, v katerem AI agenti gradijo programsko opremo. Studio za vsakim agentom preveri, ali je delo res narejeno, odločitve pa ostanejo meni. Ko AI agent reče »končano«, to še ne pomeni, da je delo narejeno. Testi so lahko zeleni, ker preverjajo napačno stvar. Build lahko uspe na mojem računalniku in pade na strežniku. Agent lahko v commit zapiše geslo, pa tega nihče ne opazi. AI Development Studio sem začel graditi s preprosto mislijo: agent naj piše kodo, preverjanje pa naj ostane programu, ki agentu ne verjame na besedo, in človeku, ki sprejme odločitve. Studio je namizna aplikacija. Vanjo v slovenščini napišem nalogo, Studio pa požene ekipo specializiranih agentov na Claudu (Opus, Sonnet in Haiku prek Claude Agent SDK). Na koncu je v repozitorijih na GitHubu delujoča aplikacija. Lahko je spletna (Nuxt, FastAPI in MongoDB), Android aplikacija v Jetpack Compose ali namizna aplikacija v Pythonu z namestitvenim programom in samodejnimi posodobitvami. Ekipa namesto enega agenta Studio nima enega vsevednega agenta, ampak 23 vlog. Vsaka ima svoj model, svoje znanje in svoje meje. Vodja napiše specifikacijo. Arhitekt napiše arhitekturo in delo razreže na majhne naloge z odvisnostmi. Nato gradijo oblikovalec, frontend, zaledje, mobilni in namizni razvijalec. Pri spletnih projektih je zraven še vloga, ki zgradi nadzorno ploščo s prijavo in pravimi podatki iz API-ja. Sledijo pregled kode, dostopnost, vsebina in SEO, integracija frontenda in zaledja, končni pregled, varnost, dokumentacija in testi. Dostopnost na spletu preverja axe-core v Playwrightu, na Androidu pa semantika Compose in dovolj veliki cilji dotika. Vloge si delo predajajo kot ekipa. Naslednja vloga ne dobi le tega, kar je o svojem delu povedal prejšnji agent. Dobi tudi dejstva, ki jih zbere Studio sam: katere datoteke so se spremenile, kako so se izšla preverjanja in kateri poskus je bil. Deli aplikacije se gradijo vzporedno, največ dva hkrati. Ko eden pade, drugi dela naprej, gumb »Nadaljuj« pa ponovi le tistega, ki je padel. Studio preveri sam Bistvo Studia je v tem, kar se zgodi po vsakem agentu. Studio sam požene lint, teste, build, preverjanje dostopnosti in E2E teste. Docker sliko zgradi iz oddanega commita, nikoli iz delovne mape, zato v sliko ne pride nič, česar ni v gitu. Preveri, da spletna aplikacija teče s strežniškim upodabljanjem. Iz prave kode zaledja ustvari opis API-ja in ga primerja s pogodbo v dokumentaciji. Tako frontend ne kliče endpointov, ki ne obstajajo. Preveri tudi, ali je vloga sploh oddala izdelek: frontend vsaj eno stran, oblikovalec dokument videza. Če je karkoli rdeče, gre delo nazaj k agentu skupaj z izpisom napak, največ trikrat. Ko isto delo dvakrat zapored pade, naslednji poskus teče z močnejšim modelom. Najprej je to Haiku, nato Sonnet, nato Opus, na koncu pa Opus z višjo stopnjo razmišljanja. Pregledovalec frontenda dobi pravi brskalnik. Studio zažene aplikacijo na sveži testni bazi s testnim skrbnikom, agent pa jo prek Playwrighta pregleda in poslika. Iz posnetkov Studio sam prebere širine zaslona. Če manjka pogled na telefonu, tablici ali namizju, delo vrne agentu. Videz izberem jaz. Oblikovalec najprej naredi tri samostojne osnutke, Studio pa jih z brezglavim Chromom poslika pri širini 1440 in 390 pikslov. Izberem enega ali pa vse zavrnem s pripombo in zahtevam tri nove. Od razvoja do produkcije Veje vodi Studio, agentom so menjave vej prepovedane. Razvoj teče na veji dev, testiranje na veji test, produkcija pa na veji master. Na koncu teka agent QA v ločeni kopiji repozitorija na veji test piše teste za obstoječo kodo. Če so testi rdeči, gre popravek nazaj na dev, največ v treh krogih. Nato Studio odpre pull request iz veje test v master. Zapiše svoj CI workflow z istimi različicami orodij, kot jih uporablja lokalno, in nastavi zaščito veje. Samodejno združi le, ko je njegov CI zelen za natanko tisti commit, ki ga je odobril. Če CI pade, Studio prebere dnevnik, ga skrajša, skrije morebitne skrivnosti in ga preda agentu kot nezaupane podatke, ne kot navodila. Na pull requestu lahko pustim komentar z ukazom /studio. Studio takrat popravi kodo po komentarjih in odgovori v vsaki niti. Spletni projekti dobijo Docker slike v GitHubovem registru, pripravljene za strežnik. Namizne aplikacije dobijo namestitveni program (PyInstaller in Inno Setup) in izdaje na GitHubu s kontrolnimi vsotami. Posodabljajo se same, posodobitve pa so podpisane s ključem Ed25519, katerega javni del se pripne ob prvi izdaji. Android aplikacijo Studio zgradi z Gradlom in jo z enim klikom zažene v emulatorju ali na priključenem telefonu. Varnost v vsakem koraku Agenti pišejo kodo, ki jo Studio nato poganja. Zato gre vsak ukaz agenta skozi varnostno politiko, ki ga dovoli, vpraša mene ali zavrne. Agent ne sme sam pushati, uporabljati GitHubovega orodja gh, brisati mape .git, menjati vej ali ustavljati procesov po imenu. Vsaka sprememba datotek CI vedno vpraša mene. Nobena skrivnost ne gre v commit ali na GitHub. Detektor išče po imenih datotek, po vzorcih žetonov in po dejanskih vrednostih iz lokalnih datotek .env. Pred vsakim pushem pregleda vsak commit posebej in nato pusha natanko tistega, ki ga je pregledal. Procesi z agentovo kodo tečejo brez moje prijave v GitHub. Nastavitve agentov in izvršljiva znanja v repozitoriju Studio prepozna po zgoščeni vrednosti. Ob vsaki spremembi vpraša, tudi ko je vklopljena samodejna potrditev. Plugini so privzeto omejeni na varne datoteke Markdown, za izvršljivo kodo je potrebna izrecna privolitev. Agenti tudi ne dobijo mojih povezav z drugimi storitvami, kot sta pošta in Slack. Možgani: zemljevid, ki se uči Možgani so 3D mreža celotne aplikacije. Skener kodo prebere, ne da bi jo zagnal. Python razčleni, tuje kode pa nikoli ne uvozi. V JavaScriptu, TypeScriptu in Vue prepozna tudi samodejne uvoze Nuxta, pozna pa še Kotlin in Retrofit. Iz tega poveže strani s klici API-ja, klice z endpointi in endpointe z zbirkami v bazi. Doda še datoteke, ki se v gitu spreminjajo skupaj. Mreža se izriše s Three.js. Na grafu Studia samega, s 646 nevroni in 5.038 povezavami, sem izmeril od 56 do 60 sličic na sekundo. Med tekom zasvetijo datoteke, ki jih agent v tistem trenutku bere, išče ali piše. Možgani se učijo iz tekov. Pri vsakem koraku Studio beleži, katere datoteke je agent bral, katere je prebral cele in katere je urejal. Iz zadnjih 30 tekov izpelje, katere datoteke so krhke. Krhka je datoteka, ki jo je moral agent urejati, da je rdeče preverjanje, na primer lint ali testi, postalo zeleno. Studio pri tem ne posluša, kaj agent pravi, da je popravil. Šteje le to, kar je res urejal. Na mreži krhko datoteko obda rdeč obroč, datoteko s predlogom za manjšo porabo pa oranžen. To znanje gre nazaj k agentom. Pred vsako stopnjo agent dobi kratek blok s tokom od strani prek API-ja do baze za svoj del. V bloku so tudi datoteke, ki se spreminjajo skupaj, in izkušnje iz prejšnjih tekov. Tako agentu ni treba vsakič znova raziskovati projekta. Ali blok res pomaga, Studio meri sam. V dnevniku porabe za vsako vlogo posebej primerja, koliko celih datotek so agenti prebrali z blokom in koliko brez njega. Kaj se je Studio naučil, povedano z besedami 3D mreža pokaže, kaj Studio ve, ne pove pa, kaj je novega. Zato ima vsak projekt stran Učenje, kjer Studio naučeno zapiše v navadnih stavkih. Vse nastane iz zapisov tekov in skena kode, brez klica modela. Stran se začne s časovnico »Novo od zadnjič«, pod njo pa so štirje pregledi. Prvi so krhke datoteke, opisane s stavki, kot je »auth.py je krhka: ko je bil gate pytest rdeč, jo je popravek moral urejati.« Drugi pregled pove, kje agenti porabijo največ, in predlaga, kako porabo zmanjšati. Primer je velika datoteka, ki jo agenti berejo celo, čeprav je nikoli ne spremenijo. Drug primer je korak, ki je stal veliko, spremenil pa ni ničesar. Tretji pregled so najbolj brane datoteke. Pri vsaki piše, kolikokrat so jo agenti brali, kolikokrat v celoti in ali so jo sploh kdaj spremenili. Zadnji pregled pove, kaj Studio ve o kodi: koliko je endpointov, klicev API-ja in povezav med stranmi in endpointi ter koliko je klicev brez endpointa in strani brez klicev. Časovnica nastane iz posnetkov. Studio posnetek naredi pred vsakim tekom, ob osvežitvi zemljevida in ob odprtju projekta ali strani Učenje. Vsak posnetek primerja s prejšnjim, razliko pa zapiše kot vnos. Vnos pove, kaj je novo, česa ni več in kaj se je spremenilo, ter po katerem teku se je to zgodilo. Prvi vnos je »Začetek beleženja« z vsem, kar je Studio takrat vedel. Novost mora biti res novost. Število branj se spremeni ob vsakem teku, zato ne gre v časovnico. Prav tako ne gre vanjo predlog, pri katerem se je spremenil le znesek žetonov. Če skener enega repozitorija ne more prebrati, Studio ne zapiše, da je vse iz njega izginilo, ampak tisti posnetek preskoči. Posnetka lahko nastaneta tudi hkrati, na primer pred tekom in ob odprtju strani. Takrat starejši ne more prepisati novejšega. Stran ne trdi več, kot povedo podatki. Ne piše, da je Studio kaj popravil ali prihranil, ampak le, kaj je opazil. Urejanja beleži od novembra 2026, zato se krhke datoteke nabirajo z vsakim novim tekom. Ko se pokvari Studio sam Napako v svoji kodi Studio opazi sam, v svojem dnevniku. Najprej jo ponovi s testom, ki mora pasti, nato popravek pripravi na ločeni veji. Agenti pri tem delajo v strogem načinu. Smejo le pognati teste, vprašati Možgane in brati git, popravljati pa smejo le module s seznama dovoljenih. Spremembe Studio bere iz gita in teste poganja sam, ne glede na to, kaj agent trdi. V glavno vejo gre popravek šele, ko kliknem »Združi«. Delovno okolje Tek spremljam na platnu toka dela. Vsaka vloga je na njem vozlišče s stanjem, časom, stroškom in številom krogov popravkov, ob njem pa konzola izpisuje dogajanje v živo. Vse, kar čaka na mojo odločitev, je zbrano v zvoncu. Odločitve med koraki preživijo tudi ponovni zagon Studia. Med tekom lahko napišem opombo, ki gre v navodila naslednjih vlog. Tek lahko tudi ustavim in ga pozneje nadaljujem. Pišem lahko izbrani vlogi ali pa prepustim ekipi, da sama odloči, kdo bo odgovoril. S povleci in spusti določim, katere vloge sodelujejo. Vsak tek ima mejo porabe in se ob njej ustavi. Studio meri žetone, vrh konteksta in strošek po koraku, vlogi in modelu, po teku pa napiše poročilo s predlogi. Aplikacijo z enim klikom zaženem na predogledni bazi s testnimi podatki. Če so vrata zasedena, se predogled sam prestavi na prosta. Kako je narejen Studio je napisan v Pythonu 3.12. Za vmesnik uporablja NiceGUI 3 in pywebview, za podatke SQLModel in SQLite, za agente Claude Agent SDK, za vizualni pregled Možganov Three.js in za brskalnik Playwright. Za dostavo skrbijo git, GitHub CLI, GitHub Actions, Docker, PyInstaller, Inno Setup in Gradle. Prvi commit je nastal 18. julija 2026, v slabih štirih mesecih pa se jih je nabralo 1.060. Studio ima 4.641 avtomatiziranih testov. Tečejo z determinističnim lažnim ponudnikom, torej brez klicev modela in brez stroškov. Poti, ki jih unit testi ne morejo pokriti, preverjam z dimnimi preizkusi s pravim Claudom. Vsaka večja funkcija gre skozi dokument zasnove, izvedbeni načrt in izvedbo s testi. Dokumentov zasnove je 70, vsaka seja pa ima zapis v dnevniku. Studio razvijam skupaj s Claude Code, torej z AI agentom gradim orodje za AI agente. Kaj sem se naučil Zelen test ni dokaz. Skener Možganov je imel vse teste zelene, na pravem projektu pa ni našel niti ene povezave med frontendom in API-jem. Testi so potrjevali primere, ki sem si jih izmislil sam. Od takrat vsak skener preverim na pravem projektu. Diagnosticiraj vzrok, ne simptoma. Napaka »Claude Code not found« ni pomenila, da program manjka. Sistemski poziv je imel okoli 37 KB in je presegel omejitev ukazne vrstice v Windows (32.767 znakov), SDK pa je pravo napako zakril. Rešitev je bila, da poziv podam prek datoteke. Preverjanje mora gledati pravo stvar. Preverjanje Docker slike je gradilo commit pred agentovo spremembo. Agent je zato šestkrat popravljal isto rdečo napako, kar je stalo 18 dolarjev. Zdaj Studio zeleno kodo odda tik pred gradnjo. Okolje je del pogodbe. CI na GitHubu je namestil novejši linter kot lokalno in padel na kodi, ki je lokalno prešla. Studio zdaj v CI pripne iste različice orodij. Agent je toliko dober kot okolje okoli njega. Največ dela ni šlo v pozive. Šlo je v preverjanja, meje in v trenutke, ko mora odločiti človek.

  • Python
  • NiceGUI
  • pywebview
  • +17
  </>
• 
  02spletv1.8.0 · v produkciji

  spec/write →

  spec-write je orodje za pisanje funkcionalnih specifikacij, v katerem specifikacija ni dolg dokument, ampak model. Vsaka zahteva, gradnik, vmesnik, podatkovni model in odločitev je oštevilčen zapis s statusom in tipiziranimi povezavami, zato ekipa v vsakem trenutku ve, kaj je potrjeno, kaj se je spremenilo in kaj je že implementirano. Arhitekt, razvijalci in stranka delajo v istem dokumentu, vsak s svojo vlogo. Pogovor teče ob bloku besedila, status gre od osnutka prek pregleda do potrditve, iskanje razume slovenske oblike besed. Stranka nikoli ne vidi osnutkov ne internih komentarjev — pravilo velja že v poizvedbah na strežniku in je pokrito s testi, ne le skrito v vmesniku. Besedilo lahko živi v aplikaciji ali kot Markdown v repozitoriju GitHub. V drugem primeru spec-write doda oštevilčene zapise, komentarje in iskanje, spremembe pa vrne kot v IDE: delovno drevo, commit s soavtorji, push, razreševanje sporov in najmanjši možni diff. Uvoz iz Worda in izvoz v .docx ali .md sta vgrajena. Orodja za pisanje kode (Claude Code, Cursor, VS Code, Codex) specifikacijo berejo prek strežnika MCP z osebnim žetonom samo za branje. Razvijalec zahteve ne kopira več ročno, orodje pa vidi natanko toliko kot on. Zasnoval in razvil sem ga od prve skice do produkcije: Nuxt 4 in TypeScript na spletu, FastAPI in MongoDB v zaledju, dvostopenjsko preverjanje in šifrirane skrivnosti, več kot 1000 testov e2e s Playwrightom ter Docker slike in izdaje prek GitHub Actions. Vmesnik je v slovenščini, dostop je zaenkrat samo z vabilom.

  • Nuxt 4
  • Vue 3
  • TypeScript
  • +15
  </>
• 
  03spletv razvoju

  Atlas za psihoterapevte →

  Atlas za psihoterapevte je večplatformna rešitev za psihoterapevtske prakse: zvočni posnetek seje spremeni v prepis in nato v strukturiran osnutek zapisa, terapevt pa ga pregleda, dopolni in podpiše. Vsak, ki dela s klienti, pozna trenutek po zadnji seji dneva. Pogovori so končani, zapisi pa še čakajo, in vsaka ura zamika zabriše podrobnosti, ki so bile zjutraj še jasne. Dokumentacija je strokovna in zakonska obveznost, hkrati pa breme, ki terapevtu jemlje čas in zbranost za delo s človekom. ATLAS izhaja iz tega trenutka, zato ima eno glavno merilo: koliko časa mine od konca seje do podpisanega zapisa. Ob tem deluje na področju z najobčutljivejšimi podatki, kar jih človek lahko zaupa drugemu. Prav ta dvojna zahteva, razbremeniti terapevta, ne da bi mu vzeli presojo ali klientu zasebnost, je oblikovala vsako tehnično odločitev, opisano v nadaljevanju. Osrednji tok je preprost za uporabo in zahteven za izvedbo. Terapevt na telefonu posname sejo ali pa po njej nareče kratek zapisek. Posnetek seje je mogoč le, če ima klient v kartoteki veljavno soglasje za snemanje. Brez njega je gumb onemogočen, strežnik pa posnetek zavrne tudi, če bi ga kdo poskusil poslati mimo vmesnika. Zvok nato obdela ozadje: pripravi prepis s časovnimi žigi in ločenima govorcema, ključne teme, predloge opravil in osnutek po razdelkih izbrane predloge, na primer SOAP ali DAP. Vsaka točka osnutka nosi sklic na odsek prepisa, zato jo terapevt preveri v nekaj sekundah, ne da bi znova poslušal celo uro. Predlogi pridejo v zapis šele, ko jih terapevt sprejme, podpiše pa ga vedno človek. Umetna inteligenca pomaga pri dokumentiranju, strokovne presoje pa ne nadomešča. Tehnično ATLAS sestavljajo štirje repozitoriji. Zaledje v Pythonu 3.13 s FastAPI in Pydantic v2 je edini vir resnice. Spletna aplikacija je napisana v Nuxt 4, Vue 3 in TypeScriptu, Android aplikacija v Kotlinu in Jetpack Compose, četrti repozitorij pa je wiki v Nuxt Content, ki se posodobi v isti spremembi kot koda. Vsi odjemalci govorijo z istim API-jem s 244 končnimi točkami pod /api/v1, ki ga določa zapisana HTTP pogodba. Pogodba ni le dokument: zaledje samo ustvari primere odgovorov, ki jih berejo Android testi, zato se neskladje med strežnikom in telefonom pokaže kot rdeč test v CI, ne kot napaka pri uporabniku. Zaledje uporablja MongoDB kot replica set, ker morajo nekateri zapisi v več zbirk uspeti skupaj ali pa sploh ne, to pa omogočajo le transakcije. Koda je razdeljena v plasti route, service in repository. Poti so tanke, poslovna logika živi v storitvah, do zbirk pa dostopajo le repozitoriji. Ta razdelitev ni estetska. Vsak repozitorij s podatki prakse vsaki poizvedbi sam doda identifikator organizacije, praksa pa se vedno izpelje iz prijavljene seje, nikoli iz parametra v zahtevku. Razvijalec filtra zato ne more pozabiti. Tuj ali neobstoječ ID vrne 404, ne da bi razkril, ali zapis sploh obstaja, poskus pa se zabeleži v revizijski dnevnik. Dolga opravila ne smejo zadrževati zahtevkov, zato ob API-ju teče ločen worker. Oba procesa delita isto kodo domene, repozitorijev in storitev, worker pa nima HTTP vmesnika. Posle jemlje iz vrste v MongoDB in skrbi za prepise, AI-obdelavo, izvoze kartotek in redna čiščenja, od začasnih datotek do kopij pri zunanjih ponudnikih. Napaka, ki je ponovni poskus ne more popraviti, posel takoj označi kot neuspešen, druge se ponovijo, terapevt pa lahko neuspelo obdelavo sproži znova brez ponovnega nalaganja. Ker platforma obdeluje posebej občutljive podatke, varnost ni dodatek, temveč del arhitekture. Klinična besedila, kot so zapisi, prepisi, uvozi in odgovori na vprašalnike, so šifrirana z AES-256-GCM že na ravni aplikacije, zato bi tudi ukradena kopija baze pokazala le šifrirano vsebino. Zvok, dokumenti in izvozi so v S3 hrambi s šifriranjem na strežniku, prenašajo pa se le prek podpisanih povezav, ki veljajo nekaj minut. Posnetek se privzeto izbriše sedem dni po podpisu zapisa, praksa pa lahko izbere takojšnji izbris ali 30 dni. Prijava za vse zahteva dvostopenjsko preverjanje s TOTP, števci poskusov tečejo ločeno na sejo, uporabnika in dan, ob zaklepu pa uporabnik dobi opozorilo po e-pošti. Vloge so ostro ločene: platformski skrbnik do kliničnih podatkov praks nima dostopa, lastnik prakse ga nima samodejno, revizijski dnevnik pa beleži, kdo je kdaj kaj odprl, uredil, podpisal ali izvozil, nikoli pa same vsebine. Dnevniki, e-pošta in obvestila ne vsebujejo imen klientov, naložene dokumente pa pregleda ClamAV. Pri umetni inteligenci je ključna zamenljivost. Ponudnika prepisa in jezikovnega modela sta skrita za enotnim vmesnikom in se izbereta s spremenljivko okolja, zato menjava ne zahteva spremembe kode. V razvoju in testih teče sintetični ponudnik z izmišljenimi podatki, lokalno pa faster-whisper na grafični kartici. Za produkcijo sta pripravljena Soniox in Speechmatics z obdelavo v EU. ATLAS kopijo pri ponudniku izbriše takoj po prepisu, redno čiščenje pa ujame tudi tiste, ki bi ostale. Osnutke pripravlja Claude prek Vertex AI v regiji EU z uradnim SDK. Povezava je implementirana in testirana, dejanska uporaba pa še čaka na odobritev kvote. Vsak AI posel hrani namen, ponudnika, model, različico in vire, iz katerih je nastal. Najpomembnejši del umetne inteligence je tisti, ki ga uporabnik ne vidi. Model dobi natančna navodila, njegov izhod pa nato preveri še strežnik z varovali. Ta zavrnejo vsako diagnozo, diagnostično oznako, oceno tveganja ali priporočilo zdravljenja. Meja je postavljena natančno. Stavek »Klient je omenil samomorilne misli.« sme v osnutek, ker poroča, kaj je bilo rečeno. Stavek »Visoko tveganje za samomor.« ne sme, ker je klinična ocena, ta pa pripada terapevtu. Varovala so preverjena na korpusu 179 primerov, med katerimi so tako stavki, ki morajo skozi, kot tisti, ki ne smejo. Android aplikacija je zgrajena okoli zanesljivega snemanja, saj izgubljen posnetek pomeni izgubljeno sejo. Snemanje teče v storitvi v ospredju, zato deluje tudi pri ugasnjenem zaslonu do tri ure, ob telefonskem klicu pa se samodejno ustavi in ponudi nadaljevanje. Zvok se že med snemanjem šifrira s Tink (AES-256-GCM-HKDF, ključ v Android Keystore). Če proces nenadoma umre, aplikacija datoteko reši do zadnjega celega segmenta, kar pomeni izgubo največ nekaj kilobajtov. WorkManager posnetek nalaga po kosih po 8 MiB, vsak kos ima kontrolno vsoto SHA-256, prenos pa se po prekinitvi nadaljuje pri prvem manjkajočem kosu. Z naprave se posnetek izbriše šele, ko strežnik potrdi prejem. Klinični zasloni imajo onemogočene posnetke zaslona, aplikacija se po petih minutah neaktivnosti zaklene z biometrijo ali PIN-om, en račun pa lahko poveže največ dva telefona. Arhitektura je MVVM s StateFlow, omrežni sloj pa Retrofit in OkHttp s kotlinx.serialization. Spletna aplikacija v Nuxt 4 loči dva svetova. Javne strani se izrišejo na strežniku zaradi hitrosti, iskalnikov in pravilnih jezikovnih različic. Delovni del aplikacije teče kot SPA brez strežniškega izrisa in je zaprt za iskalnike, tako da strežnik kliničnih podatkov nikoli ne izrisuje. Celoten sistem je dvojezičen: slovenščina in angleščina veljata za vmesnik, sporočila API-ja, e-pošto, PDF-je in Android aplikacijo. Dostopnost po WCAG 2.2 AA preverja axe v Playwright testih. Center za pomoč v aplikaciji in PDF navodila nastaneta iz istega vira, zato si ne moreta nasprotovati. Integracije so izbrane tam, kjer prihranijo korak. Stripe skrbi za naročnine prek Checkout in Billing. Podpisani webhooki se shranijo enkrat in obdelajo v workerju, zato podvojen dogodek ne more dvakrat spremeniti naročnine. Zoom se poveže prek OAuth za vsakega terapevta posebej: ATLAS ustvari sestanek z nevtralnim naslovom, po koncu pa samodejno prevzame povzetek Zoom AI Companion kot vir seje, nikoli neposredno v podpisan zapis. Push obvestila prek FCM in e-pošta ne vsebujejo imen klientov, povezava do koledarja ICS pa se ob varnostnih dogodkih samodejno prekliče. Za supervizijo ATLAS pripravi psevdonimizirane primere, strežniška pravila pa pred deljenjem poiščejo osebne podatke tudi v sklonih in imenih priponk. Zanesljivost razvoja podpira več kot 3.500 avtomatiziranih testov: skoraj 2.000 v pytestu za zaledje, okoli 1.000 v Vitestu za splet, 565 za Android in 42 celovitih tokov v Playwrightu, ki ključne poti preverijo skozi pravi brskalnik. GitHub Actions jih poganja v vseh štirih repozitorijih. Vsaka sprememba pogodbe se v isti seji prenese v zaledje, oba odjemalca in wiki. Za objavo sta pripravljena Docker Compose in Caddy. Projekt še ni javno objavljen in je v zaključnem preizkušanju. Pravi preizkus ne bo število testov ali končnih točk, temveč merilo z začetka: ali terapevt zvečer zapre računalnik prej kot včeraj, ne da bi pri tem zaupal manj. Pri gradnji se je najtežje vprašanje izkazalo za netehnično. Ni šlo za to, kaj umetna inteligenca zmore, ampak za to, ali bi ji terapevt zaupal zgodbo svojega klienta. Vsaka odločitev v tem besedilu je poskus odgovora na to vprašanje.

  • FastAPI
  • Nuxt 4
  • Kotlin
  • +17
  </>
• 
  04splet5+ brezplačnih orodij

  ADHDpodpora.si →

  ADHDpodpora.si je spletna platforma, ki sem jo ustvaril za starše otrok z ADHD, učitelje in vse, ki želijo otroke bolje razumeti ter jim pomagati pri vsakdanjih izzivih. Projekt je nastal iz osebne izkušnje in želje, da bi družine na enem mestu našle razumljive informacije, praktične pripomočke in podporo. Pri njem povezujem razvoj programske opreme z vsebino, ki mi je osebno blizu. Na platformi so zbrani članki in raziskave o ADHD, predstavljeni v dostopnem jeziku. Vsebine obravnavajo pozornost, izvršilne funkcije, čustva, zdravljenje, šolo in družinsko življenje. Starši in učitelji lahko najdejo tudi praktične strategije za rutine, domače naloge, sodelovanje s šolo ter informacije o tem, kje poiskati strokovno pomoč. Pomemben del projekta so brezplačna interaktivna orodja in gradiva za tisk. Med njimi so vizualna rutina, dnevnik opažanj, pripomoček za umirjanje, igra spomina in listi za lažjo komunikacijo med otrokom, starši in šolo. Pri dnevniku opažanj sem upošteval tudi zasebnost: ob uporabi brez računa zapisi ostanejo v uporabnikovem brskalniku. Platforma vključuje zgodbe staršev, predstavitve strokovnjakov, dogodke, programe podpore in spletno trgovino. Obiskovalci lahko spremljajo nove vsebine, se prijavijo na e-novice ter spoznavajo izkušnje drugih družin. Projekt tako združuje vsebinski portal, interaktivna orodja in funkcionalnosti, ki zahtevajo povezavo z zalednim sistemom. Uporabniški vmesnik je izdelan z Nuxt 4, Vue 3 in TypeScriptom, za oblikovanje pa uporabljam SCSS. V tehnološki sklad sta vključena tudi Nuxt Content in Chart.js. Vmesnik je prilagojen različnim velikostim zaslonov, od telefonov do namiznih računalnikov, pri zasnovi pa sem pozornost namenil pregledni navigaciji in jasni predstavitvi večje količine vsebin. Zaledje temelji na Pythonu in FastAPI-ju, podatki pa se shranjujejo v MongoDB. Spletni del se z zaledjem povezuje prek API-ja, ki podpira delovanje platforme, uporabniške račune in delo s podatki. Projekt vključuje prijavo uporabnikov in upravljanje sej, med uporabljenimi tehnologijami za avtentikacijo pa je tudi JWT. Za shranjevanje slik in drugih datotek uporabljam objektno shrambo, združljivo s S3, do katere zaledje dostopa prek knjižnice boto3. Spletna plačila obdeluje Stripe, v projekt pa je vključena tudi povezava s Facebook Graph API-jem. Pri razvoju sem pozornost namenil zaščiti uporabniških računov, omejevanju poskusov prijave in komunikaciji prek povezave HTTPS. Poskrbel sem tudi za postavitev in delovanje zaledja na strežniku. Rešitev uporablja Docker in Nginx, med orodji za razvoj in preverjanje pa so še pytest, Playwright in GitHub Actions. Projekt še naprej vzdržujem in nadgrajujem z novimi vsebinami, orodji ter funkcionalnostmi. ADHDpodpora.si je zame projekt, pri katerem lahko uporabim svoje znanje načrtovanja in razvoja celotne spletne rešitve – od uporabniškega vmesnika in interaktivnih funkcionalnosti do API-ja, podatkovne baze in postavitve na strežnik. Hkrati je to prostor, s katerim želim prispevati k boljšemu razumevanju otrok z ADHD in njihovih družin.

  • Nuxt 4
  • Vue 3
  • TypeScript
  • +17
  </>
• 
  05drugoAndroid + spletna stran

  Kozarec vode – aplikacija in spletna stran →

  Kozarec vode je projekt iz dveh delov: Androidove aplikacije za preprosto spremljanje dnevnega pitja vode in spletne strani, ki aplikacijo predstavi in promovira. Aplikacija namesto mililitrov in zapletenih grafov šteje kozarce: en dotik doda kozarec (2,5 dl), privzeti cilj pa je osem kozarcev oziroma dva litra na dan. Zaslon Danes s krožnim prikazom pokaže napredek proti cilju, zadnji vnos je mogoče razveljaviti, zgodovina pa prikaže tvoj teden v kozarcih. Dnevni cilj prilagodiš sam ali ga aplikacija predlaga glede na telesno težo, aktivnost in vroče okolje (kot splošno oceno, ne zdravniški nasvet). Na voljo so še opomniki ter svetla in temna tema. Spletna stran v nekaj sekundah razloži, kaj aplikacija ponuja: predstavi njene funkcije, pokaže zaslone v okvirju telefona in vodi do prenosa z Google Play. Vključuje tudi javni pravilnik o zasebnosti, ki ga zahteva Google Play. Stran je hitra, prilagojena mobilnim napravam in dostopna (WCAG AA, preverjena z avtomatskimi testi), optimizirana za iskalnike, z lokalnimi pisavami ter brez piškotkov, sledilnikov in analitike – tako sama sledi istim načelom kot aplikacija. Celoten projekt je zasnovan z mislijo na zasebnost: aplikacija ne zahteva računa, ne potrebuje internetne povezave in ne vsebuje oglasov ali analitike, vsi podatki pa ostanejo izključno na napravi. Spletno stran je zgradila ekipa AI agentov v AI Development Studiu.

  • Android
  • Nuxt 4
  • Vue 3
  • +4
  </>
• 
  06spletže od leta 2021

  Hypnosis Studio Alen →

  Hypnosis Studio Alen je večjezična spletna stran, ki sem jo izdelal za predstavitev dela in storitev Alena Mariča. Obiskovalcem približa hipnoterapijo, samohipnozo, regresijo, jasnovidnost in medijstvo ter jim omogoča, da na enem mestu spoznajo ponudbo in stopijo v stik. Spletna stran je na voljo v slovenščini, nemščini, angleščini in hrvaščini. Poleg predstavitve posameznih storitev in terapevta vključuje blog, pregled dogodkov, galerijo fotografij, objave v medijih, mnenja strank ter odgovore na pogosta vprašanja. Obiskovalci se lahko prijavijo na e-novice, prek kontaktnega obrazca pa pošljejo vprašanje ali povpraševanje za termin. Projekt vključuje tudi predstavitev knjige in darilnih bonov. Zaledni API podpira delo z vsebinami, dogodki, kontaktnimi sporočili in prijavami na e-novice, fotografije v galeriji pa se nalagajo iz objektne shrambe. Pri razvoju sem pozornost namenil pregledni navigaciji, prilagoditvi prikaza različnim napravam ter večjezičnosti. Stran vključuje tudi metapodatke in strukturirane podatke za spletne iskalnike in deljenje vsebin.

  • Nuxt
  • Vue.js
  • JavaScript
  • +8
  </>
• 
  07namizje4 vrste dejavnosti

  Pavza →

  PAVZA je namizna aplikacija za Windows, ki skrbi za redne odmore med delom. Ob nastavljenem času se čez ves zaslon odpre miren zaslon z odštevalnikom in predlogom dejavnosti: popij vodo, raztegni se, zadihaj ali se razgibaj. Odmor lahko končaš kadar koli, ga preložiš za 5 minut ali izbereš drugo dejavnost. Uporabnik sam nastavi, kako pogosto ga aplikacija opomni, koliko časa traja odmor ter delovni čas in dneve. Doda lahko tudi svoje dejavnosti. Na pregledu vidi, kdaj je naslednji odmor in koliko odmorov je imel danes, v urniku pa današnji razpored. Aplikacija deluje povsem lokalno, brez računa in brez interneta, vmesnik je v slovenščini. Tehnično: vmesnik je narejen v NiceGUI (Quasar) in teče v lastnem oknu pywebview. Podatki se shranjujejo v SQLite prek SQLModel. Opomniki tečejo v ozadju, tudi ko je okno skrito. Aplikacija ima vedno le en zagnan primerek (Windows mutex prek ctypes) in se lahko zažene ob prijavi v Windows (register). Oblikovni sistem je lasten CSS, ilustracije in pisave pa so priložene aplikaciji. Kakovost preverjajo pytest (148 testov), Ruff in CI na GitHub Actions.

  • Python
  • NiceGUI
  • pywebview
  • +15
  </>
• 
  08splet78 tarot kart

  Tarot zate →

  Tarot zate je moj osebni spletni projekt, ki na enem mestu združuje izobraževalne vsebine, praktične vaje in interaktivna orodja za raziskovanje tarota, simbolike ter osebnostne in duhovne rasti. Obiskovalcem približuje tudi kabalo, Drevo življenja, qliphot, astrologijo, džjotiš, numerologijo, meditacijo in druge sorodne teme. Osrednji del platforme predstavlja zbirka vseh 78 kart velike in male arkane s podrobnimi razlagami njihovih pomenov in simbolike. Uporabniki lahko izbirajo med več kot 25 tarot postavitvami, naključno izžrebajo in obrnejo karte ter raziskujejo njihove pomene. Pri tem se upošteva tudi pokončna ali obrnjena lega karte. Stran vključuje še karto dneva, ki se vsakih 24 ur zamenja. Poleg tarota so na voljo meditacije, dihalne vaje in 22 sadhan, povezanih s kartami velike arkane. Obiskovalci lahko raziskujejo tudi priporočeno literaturo ter prenesejo brezplačne delovne zvezke, dnevnike in druga gradiva za samostojno delo. Projekt vključuje ločen API za prijavo, upravljanje bloga in kontaktnih sporočil ter administrativni del. Pri razvoju sem pozornost namenil pregledni organizaciji obsežnih vsebin, uporabniški izkušnji in prilagoditvi strani različnim velikostim zaslonov. Poskrbel sem tudi za metapodatke in strukturirane podatke za spletne iskalnike ter deljenje vsebin.

  • Nuxt
  • Vue.js
  • JavaScript
  • +7
  </>
• 
  09splet23 poglavij

  Večnost obstoja →

  Večnost obstoja je spletna stran, posvečena moji istoimenski knjigi, v kateri skozi osebna razmišljanja raziskujem vprašanja človekovega bivanja. Knjiga odpira teme časa, zavedanja, ljubezni, odnosov in minljivosti ter vabi k razmisleku o tem, kako nas oblikujejo pretekle izkušnje in kaj pomeni živeti bolj prisotno. Spletno stran sem ustvaril kot prostor za prvi stik s knjigo in njenimi idejami. Obiskovalec lahko spozna njene osrednje teme, prebere odlomek iz uvoda in izbrane misli, pokuka v kazalo ter izve več o avtorju. Na voljo so tudi intervju in povezave do knjigarn, kjer je mogoče naročiti izvod. Projekt mi je blizu, ker v njem povezujem dve področji, ki sta pomemben del mojega življenja: pisanje in razvoj spletnih strani. Pri zasnovi sem želel ustvariti umirjeno in pregledno predstavitev, ki obiskovalcu približa vsebino knjige ter ga povabi, da se za trenutek ustavi in razmisli.

  • Vue
  • Nuxt
  • HTML
  • +1
  </>

vsi projekti →