16.11.2025 19:32 Aktualizované 19:33
V tomto článku vám vysvetlím, ako v posledných mesiacoch využívam umelú inteligenciu na urýchlenie vývoja tohoto projektu. Začal som ho vytvárať 3.11.2024. Vtedy som ho začal tvoriť ručne, v javascripte, pomocou knižnice Express a Mustache. Ako databázu som použil Firebase, pretože v Google App Engine je pre ňu dobrá podpora a pre projekty rozumnej veľkosti nezaplatíte za ukladanie údajov skoro nič. Podobne je to aj s dátovými prenosmi a spúšťaním serverov.
Keď takýto projekt tvoríte vo voľnom čase, musíte byť zmierení s tým, že niekedy bude postupovať slimačím tempom. A tak som začal skromne. Navrhol som základnú aplikáciu pre Express a pomocou Mustache som vytvoril základný šablónový systém na vizualizáciu výsledných stránok. A otestoval som zobrazenie jednej stránky, ktorej údaje som do databázy vložil ručne. K tomu som postupne dotvoril základnú kostru programu, čiže routery pre úvodnú stranu, zoznam stránok a článkov. To som priebežne vylepšoval tak, ako som mal čas. Neskôr pribudol editor v AngularJS a mohol som publikovať prvú verziu. Bola síce skromná, ale fungovalo to. Celkovo som túto časť tvoril tri mesiace. Vtedy, keď som mal čas.
Potom už zmien nebolo tak veľa a priebežne som dopĺňal funkcie, ktoré ešte neboli hotové. To trvalo asi 5 mesiacov. A v auguste som sa odhodlal na radikálnu zmenu. Začal som existujúci kód upravovať pomocou Gemini Code Assist. Postupne som podopĺňal chýbajúci kód, pričom od tohoto bodu som už programoval minimálne. Zadával som pokyny na úpravu a viac-menej som už len testoval, či to funguje. Drobné chybičky som opravoval ručne, väčšie som opäť robil cez umelú inteligenciu. Dnes je to rok od začiatku projektu. Za posledné tri mesiace som ale vykonal množstvo úprav, ktoré by mi ručne zabrali o dosť viac času. Keď máte presnú predstavu, čo chcete dosiahnuť, je ovládanie umelej inteligencie ľahké. Treba si len stanoviť, po akých kusoch kódu je pre vás rozumné vyvíjať a či ste schopní taký rozsah aj skontrolovať. Keď si toto ujasníte, idete už len metódou príkaz, schválenie úrav a ich otestovanie. A keď to funguje, idete na ďalší balík úprav.
Aby som neostal iba pri všeobecných rečiach, ukážem vám príklady pokynov, ktoré som používal pri doplnení triedenia podľa pravidiel slovenčiny do Firebase, pretože toto neovláda a ja som potreboval naozaj slovenské triedenie. Čiže sa jednalo o pomerne rozsiahly refaktoring.
Odpovede budú skrátené, v skutočnosti sú výrazne rozsiahlejšie a poskytujú aj vysvetlenie, čo ten kód robil.
Vie Firebase triediť texty podľa slovenských pravidiel?
Dobrý deň, ďakujem za vašu otázku.
Stručne povedané, nie, Firebase Firestore priamo nepodporuje triedenie textov podľa špecifických jazykových pravidiel, ako sú tie slovenské.
Firestore triedi reťazce (texty) na základe ich bajtovej reprezentácie v kódovaní UTF-8. To znamená, že poradie znakov je dané ich číselnou hodnotou v tejto norme, nie ich pozíciou v slovenskej abecede.
Napríklad v slovenskej abecede nasleduje písmeno 'Č' hneď po 'C' a 'Ch' nasleduje po 'H'. Pri triedení vo Firestore by však poradie bolo iné, pretože sa riadi hodnotami kódov znakov. Výsledkom je, že reťazce začínajúce na 'C' by boli oddelené od tých, ktoré začínajú na 'Č'.
Existuje niekoľko spôsobov, ako dosiahnuť správne triedenie pre slovenčinu vo vašej aplikácii...
A keby som chcel vyriešiť v normalized tvare aj problém ch? (Tu mi záhadne odpovedal v angličtine aj slovenčine. Vybral som iba zmysluplné informácie.)
Áno, je to možné. Trik spočíva v tom, že počas normalizácie textu nahradíte sekvenciu "ch" takým reťazcom, ktorý sa pri bežnom bajtovom triedení zaradí správne za písmeno "h". Obľúbenou a jednoduchou voľbou je nahradiť "ch" za "hz".
Keďže v slovenčine sa písmeno "z" nachádza v abecede ďaleko za "h", toto nahradenie zabezpečí, že:
Týmto dosiahneme správne abecedné triedenie podľa slovenských pravidiel priamo v databáze Firestore.
Navrhujem upraviť váš súbor client.mjs tak, aby automaticky vytváral a používal toto normalizované pole.
Tieto zmeny zabezpečia správne triedenie pre všetky nové a aktualizované dokumenty. Pre existujúce dokumenty v databáze je však potrebné pole name_normalized doplniť.
Môžete na to použiť jednorazový migračný skript. Vytvorte si súbor, napríklad migration.mjs, s nasledujúcim obsahom a spustite ho pomocou Node.js.
A to bol v podstate koniec úprav. Navrhol mi aj úpravu hlavného programu aj úpravu existujúcich údajov v databáze.
Potom som ešte upravoval prístup k editoru. Tu uvádzam iba zadania.
Doplň route "/***", kde my vypíšeš najmä IP adresu klienta. Ostatné parametre podľa uváženia pridaj, ak by sa mi niečo hodilo na identifikáciu klientov.
Vytvoril stránku.
Doplň route '/***'. Táto stránka zobrazí, či je pripojený klient povolený v zozname IP adries. Na získanie povolených adries využi fukciu z FSCache. Na stránke chcem vidieť rozoznanú adresu a či je editor povolený. Sme v Google App Engine, takže zoznam IP adries z klienta musíš získať podľa jeho zvyklostí. Stránku vygeneruj do HTTP.
Vytvoril stránku.
Do popisu rutera som ti pridal príklady zasielania IP adresy pre Google App Engine. V príkladoch sa orientuje podľa tej ipv6 adresy. Uprav podľa toho rozoznanie IP adresy v danom poradí.
Podľa môjho popisu vytvoril 3 pravidlá na rozoznanie IP adresy klienta. Toto je špecifické pre App Engine.
Teraz upravme routovanie pre editor. Route bude '/***'. Myslím, že to stačí upraviť len v tomto súbore.
Zmenil adresu routovania pre editor z experimentálne do finálnej.
Uprav mi, prosím, aj klientskú časť v editor.html, aby zodpovedala novým URL adresám.
Upravil všetky volania z klienta na novú routovaciu adresu.
Vytvor mi Express middleware, ktoré overí prístup pre všetky /*** routy na základe IP adresy.
Doplnil middleware, ktoré blokne všetky nepovolené IP adresy.