Denník NP OpenData 2.0

Toto je problem co treba eskalovat na MIRRI. Predsa toto musi byt vyriesene tak, ze sa tam datovy kurator prihlasi (idealne cez SSO) a za 10minut to ma vyklikane ak uz rovno neexistuje API, ktore to tam natlaci.

Ja pevne verim, ze sucastou noveho projektu je aj migracia dat, ved to by nedavalo zmysel predsa.

Statistika nestatistika, to je take sliepka-vajce problem. Pokial na data.gov.sk nebudu dobre odkazy, tak tam nikto nebude chodit a naopak.

2 Likes

ale rovnako dopadli aj moduly v eDOV … u6 prti prvom vyslovení názvu modulu a jeho určernia bolo jasné že je to mrtvý modul. Aj som to v Globalteli vtedy povedal… Ale aj tak sa urobil, pričom iné oblasti IT živoria…

tak ja som vychádzal z oznamu M. Líšku z dátovej kancelárie…

Vyššie som sa to snažil vysveliť. Súčasťnou OD2.0 je viac výstupov, portál je len jedným z nich.
Tak či onak, portál je rozdelený na tri samostatné časti:

  1. NKOD (70k, realizovateľ MFFUK) - Národný katalóg prepoužitý z ČR (kde je treba najskôr urobiť metadátový profil DCAT-AP-SK, migrovať metadáta, nastaviť pipeline na dátový procesing - import, meranie kvality),
  2. Webový portál (400k, realizovateľ SKIT/VO) (frontent), ktorý musíme spraviť podľa idsk.gov.sk, autentifikáciu, migráciu, služby na zápis do centrálneho úložiska, štatistiky používania (v čR to nemajú), registrácia poskytovateľa
  3. Open Data Komunita (300k, realizovateľ VO2)- registrácia používateľa, rôzne funkcie - hlasovanie za dataset, podnety na zverejňovanie

Čiže rozpočet na celý portál 770K (pôvodne to bolo cca 1.9Mil). Takže milión ušetríme. Potom je tam ešte rozpočet na publikačné minimum, govgit, a experimentálen metódy.

Datasety treba určite publikovať na súčasné data.gov.sk, pretože samozrejme budeme robiť migráciu (metadát, aj uložených súborov) a nebude treba nič znovu nahadzovať. Naopak, je pre nás dôležité stále mať poriadok v dátach a plniť aj súčasný katalóg.

V rámci migrácie pracujeme na zvalitnení dát. Ešte do samotnej migrácie chceme opraviť čo najviac datasetov, napr. nesprávna katalogizácia distibúcii datasetov s rôznou časovou platnosťou

resp, nesprávne zkatalogizované služby pre opendáta
MetaIS,

prípadne úplne že prázne datasety. Podrobnosti zverejníme čoskoro.

1 Like

Zostávajúce dve časti portálu pre otvorené údaje sú otvorené na pripomienkovanie:

OD2.0-data.gov.sk2 Katalóg požiadaviek (v.2022-02-15)

OD2.0-Komunita Katalóg požiadaviek (v.2022-02-15)

čiže tieto verzie ešte neobsahujú zapracovania tvojich požiaviek.

(edit: zle som pochopil jana suchala, on navrhoval niektoré vylepšenia pre opendata FSSR, čiže katalógy požiadaviek za OD2.0 zatiaľ beriem ako konzistentné, hoc ešte neuzavreté)

1)

Ešte raz sa k tomu vrátim.
Ako som už písal, samozrejme že plánujeme migráciu (metadát a aj dát). A mrzí ma, že proces registrácie je byrokratický, mne tiež trvalo, kým sa mi podarilo získať prístup za MIRRI. Rozhodne, nič nebude treba 2x katalogizovať.

Podľa plánu, portál bude dokončený až nabudúci rok, čiže určite prosím nečakajte a zkatalogizujte svoje opendata už teraz.

Pokiaľ viem, niekto za Vašu organizáciu musí mať prístup do elektronickej schránky, v rámci ktorej potom požiada o sprístupnenie funkcionality publikovania otvorených údajov.

2)

Každopádne toto plánujeme v OD2.0 zjednodušiť cez jednoduchý formulár pre poskytovateľa. Nie je to však ešte predne vyšpecifikované, ako to bude fungovať.
V rámci OD2.0 plánujeme umožniť registrovať publikáciu otvorených dát aj nie OVMkam, ale aj akademickým subjektom, neziskovým organizáciam alebo privátnemu sektoru.

Medzi datasetmi bude možné pridávať relácie (napr. zdrojový dataset). Ak budem napr. privátny sektor a budem mať svoj katalóg datasetov, ktoré budú obohacovať datasety štátnej správy (napr. pridanie ďaľších údajov, stotožnenie údajov, … ) v detaile pôvodného datasetu uvidím aj súvisiaci skvalitnený dataset. A prípadne aj aplikáciu, ktorá tento dataset využíva.

Otázka je ale vyriešiť registráciu takýchto subjektov, aj nových OVM (pretože zatiaľ je ich na data.gov.sk menšia množina). Tam predpokladáme, že sa stále použije nutnosť mať elektronickú schránku. Zatiaľ to neplánujeme umožniť fyzickým osobám, ale neskôr to nevylučujeme.

1 Like

Ešte plís, pripomienky prosím posielajte do 28.2. na mail opendata@mirri.gov.sk. Samozrejme bude radi keď ich dáte aj tu, aby sme sa o nich porozprávali.

V utorok 22.2. 13:00 je pracovná skupina Otvorené údaje, tam budeme prezentovať aktuálny stav OD2.0 tiež.Takže sa kľudne pripojte. Ak nemáte pozvánku, tiež dajte nám info tiež na horeuvedený mail.

Ahojte,

dovoľte mi Vás poprosiť o pomoc. :pray:

Potrebujeme na úrade doriešiť vzťah CSRÚ a Opendata. CSRÚ počíta s tým, že nám bude dávkovo zapisovať súbory, čomu sa chceme vyhnúť. Pripomeniem ešte že projekt OD2.0 počíta zo zapisovaním súborov do centrálneho portálu (tak ako je to dnes), no kvoli maximálnej kvalite otvorených dát ja osobne preferujem API (či už na stiahnutie naraz celej dávky dát, alebo len konkrétneho datasetu). A obzvlášť je to pre nás dôležité ak sa bavíme o kľúčových národných projektoch (CSRU).

Aby som to ešte upresnil, hľadáme modus-operandi, kedy by bolo použitie CSRÚ pre opendáta prínosné, nie opak.
Ja by som si vedel predstaviť použitie CSRÚ pre opendáta napr. tak, že tento systém skvalitní dáta, napr.

1) obohatenie opendát o referenčné dáta: vytvorený dataset bude obsahovať kvalitné zreferencované dátá. Napr. že vytvorí krásny dataset z RPO, pričom v stĺpci adresa si už nájdem rovno identifikátor z registra adries. Toto ale vyzerá že je mimo scope projektu a CSRÚ s ničim takýmto nepočíta.

Čomu sa chceme vyhnúť je, že CSRÚ sa pripojí na nejaké API ISVS, zoberie si dáta a dávkovo ich nahrá do OD2.0. Toto považujem za zníženie kvality opendát, pretože v tomto prípade je lepšie skatalogizovať rovno živé API bez potreby kopírovania a ukladania dát.

2) skvalitnenie opendát: tu si viem predstaviť, že CSRÚ poskytne API napr. na vygenerovanie inej transformácie datasetu. Napr. opendata ITMS poskytujú len JSON, a CSRÚ by urobilo službu, ktorá bude trasformáciou poskytovať aj CSV. Opäť toto by ale malo byť riešené službou.

3) poskytnutie špecifických služieb: napr. že CSRÚ poskytne službu anonymizácie dát (napr. datasety s osobnými údajmi transformuje na číselné dátové kocky), a tá sa skatalogizuje na data.gov.sk

Aký máte prosím na to názor?
Do pár dní toto musíme vyriešiť. Inak nám hrozí scenár, že bude CSRÚ nahrávať súborové datasety.
Projekt CSRÚ aj OpenData2.0 má definovaný merateľný ukazovateľ: počet inštitúcií, ktoré publikujú opendata cez CSRÚ. (Čo je dosť divný indikátor pre OD2.0, merať ju za to, čo urobí externý systém). Tak či onak, keby dokázalo robiť CSRÚ služby v zmysle bodov 1, 2, 3 - tak katalogizáciou týchto služieb na data.gov.sk by sme tieto indikátory považovali za splnené, a to najlepšiu formou splnenia.

Aby som bol úplne presný, tu je tabuľka požiadaviek IS CSRÚ. Náš opendatový pohľad sú tie dva zelené stĺpce na konci.

Ďakujeme za každý názor.
PS: Ten zelený komentár je môj pohľad na vec.

OK. V rámci riešenia spolupráce OpenData a CSRU sme našli dohodu, ako danú prepojenie riešiť čo najsystémovejšie do budúcna. Riešenie na ednej strane podporuje priamu katalogizáciu aplikačných rozhraní ISVS sprístupňujúcich otvorených údaje ak takéto rozhrania existujú. V tomto prípade je prednostnejšie katalogizovať služby priamo, čiže opendata sa neukladajú do súboru ale sprístupnia sa cez API. Ak však systém nemá takéto opendatové API, a svoje údaje do CSRÚ poskytuje, tak v tomto prípade je možné zapisovať do centrálneho portálu nielen metadáta ale aj samotné distribúcie.

Detailnejšie informácie je to možné nájsť v novej jednotnej metodike spôsobov zverejňovania otvorených údajov:
https://wiki.vicepremier.gov.sk/pages/viewpage.action?pageId=82019428

Ahojte,

v rámci projektu OD2.0 riešime aj GovGit, čo je systém pre uloženie zdrojových kódov ISVS. Opäť túto tému nechceme vymyslieť nanovo ale chceme sa čo najviac inšpirovať ako to vo svete funguje. Ked sme si robili research, našli sme opakovane riešenie založené na centrálnej katalogizácii otvorených zdrojových kódov, ktoré boli fyzicky nahraté v GitHuboch v správe jednotlivých OVM.

Napr.:

v USA majú portál

kde potom podľa jednotlivých OVM (agencies) sú zoskupené ich podradené organizácie a ich množina sprístupneniach kódov. Napr. Department of Agriculture, obsahuje odkazy na

a podobne.

vo Francúzsku podobný portál:

ktorý napr. odkazuje na projekt

Takže keby sme tento prístup zachovali, stačilo by vybudovať jednoduchú katalogizačnú apku dostupnú na adrese code.gov.sk , ktorá by obsahovala metadáta jednotlivých otvorených zdrojových kódov. Aj napr. samotný zdrojový kód nového portálu chceme takto zverejniť, či už na GitHub dátovky:

alebo NASESu, ktorý bude prevádzkovateľ.

Avšak my na slovensku už máme platnú vyhlášku ako to urobiť, aj je to bohužiaľ veľmi centralizované:

Okrem samotnej centralizácie, za mňa nie je celkom šťastné, že sa miešajú dáta a kódy, tj. že sa zdrojové kódy majú publikovať cez data.gov.sk. Tu by teoreticky mohlo existovať riešenie, že v rámci nového portálu bude urobená stránka zo zoznamom týchto zdrojových kódov, a teda mohlo by to byť prístupné na adrese code.data.gov.sk, čo je ale opäť trošku pomiešané.

Tak či onak, ak sa jedná o zdrojové kódy, ktoré majú obmedzený prístup, asi len ľudia z verejnej správy či dodávateľ na základne nejakej zmluvy, tak toto by teoreticky na centrálne miesto so zdrojovými kódmi ísť mohlo. Takže modus operandi zdieľania zdrojových kódov by bol hybridný. Ak môže byť zdrojový kód úplne prístupný, tak môže byť na githube ale musí byť katalogizovaný na centrálnom mieste. Ak nemôže, pretože že má obmedzený prístup, tak musí byť umiestnený v centrálnom Gite, ktorý bude niekde vo vnútorných sieťach.

:point_right: Tak či onak, čo potrebujeme riešiť sú ešte aj metodiky publikácie otvorených zdrojových kódov (čo všetko sa musí spraviť pred samotnou publikácou, ktorých systémov sa týka čo …). Celá táto problematika sa zatiaľ vyvíja, diskusia začína naberať na obrátkach. Otázka je, ako rozdeliť, ktorý softvér sa môže vôbec publikovať ako otvorený, napr. čo napr. s MetaIS, alebo čo s kritickými systémami, ktoré musia byť stále dostupné.

Ak máte na to plís nejaký názor, budeme radi keď ho sem vyzdielate.

PS:) Finišujeme interne na dokumente Strategická priorita Otvorené údaje 2022, zverejníme ju čoskoro.

Ja len dufam, ze tuto nikoho ani len nenapadne nieco programovat ale proste sa kupi-zoberie nejaky gitlab.

Samozrejme, nič také nemáme v úmysle, tj. vyvíjať žiaden nový gitlab, alebo čo.

Ja som sa skôr chcel spýtať, ako vnímate pôvodný zámer, že sa majú všetky kódy dávať len na jedno miesto, tj. štátny github, a nie decentralizovaný princíp, ako som ukázal príklady vyššie, tj. keď kódy sú na vlastných githuboch OVMiek, avšak všetky sú skatalogizované v jednoduchej apke niekde v centre.

Mať iba jeden štátny GovGit by to asi bolo jednoduchšie riešenie, a nemusíme urobiť ani tú malú apku s katalógom sprístupnených kódov, ani by sme nemuseli prevadzkovať dve riešenia. Ešte k tomu plánujeme robiť menší research, chceme pozrieť aj ako to majú v ČR. Možno že to zbytočne komplikujeme, pretože hoc aj dnes existujú GitHuby našich OVMiek, pravdepodobne nejde vždy o zverejnený kód nejakého veľkého ISVS, skôr sú tam rôzne súbory opendata.

Čiže možno by nakoniec stačilo mať iba jeden štátny git, vo vyhláške by sme opravili že to nemá byť na data.gov.sk, ale na code.gov.sk, a hotovo. Ešte si dovolím jednu otázku, ako je to s IDSK, keď sa kupuje celý soft, ten sa asi nemusí prerobiť, že?.

Pár aktuálnych informácií o projekte:

1)

S projektom sa pomaly rozbiehame. Zmluva s MFFUK je už takmer dopodpisovaná všetkými inštanciami. Jednou z prvýhc vecí, ktoré sa budú realizovať bude návrh metadát pre otvorené údaje, kde samozrejme ideme použiť DCAT (teraz už vo verzii 3.0). Aby som to skrátil, bude to viacmenej to isté ako DCAT-AP-CZ

https://ofn.gov.cz/rozhraní-katalogů-otevřených-dat/2021-01-11/

kde pridáme atribúty:

  • typ poskytovateľa - [government, academy, private sector, ngo]
  • typ datasetu - [publikačné minimum, high-value dataset, najžiadanejší dataset …]

a potrebujeme ešte vyriešiť licencovanie, kde sa ideme rovnako inšpirovať cz legislatívou:

Inak, na tejto veci sme už začali robiť v roku 2017, keď som ešte na MIRRI nerobil. Viedol som jednu bakalarku, kde výstupom bolo prvotné vytvorenie profilu. A je tu k tomu ešte samostatné vlákno.

Aby som ešte upresnil. DCAT-AP-SK bude otvorená formálna nielen pre centrálny portál otvorených údajov (data.gov.sk), ale aj pre iné portály, ktoré sa budú chcieť dať harvestovať.

2)

Druhá krátka info je o realizovaní frontendu - druhá časť portálu (webové stránky, autentifikácia). Pôvodný plán bol, že ho realizuje SKIT. Bohužiaľ ten je momentálne absolútne vybookovaný, takže hľadáme náhrané riešenie. Zatiaľ máme viac scenárov. Na našej strane sa snažíme urobiť toho čo najviac - Opis predmetu zákazky, Návrh obrazoviek, DNR, a všetky ostatné dokumenty, tak aby zadanie bolo čo najpresnejšie a v konečnom dôsledku - realizácia najmenšia - resp. aby sa celková cena vošla opäť do VO s nízkou hodnotou. Tu si ale musíme spraviť dobrý prieskum, za koľko by to niekto vedel vyvinúť. Ďaľšia varianta je, že budeme hľadať interného kódera, spolu s ktorým by sme mohli vyvinúť web aj u nás (aby mal nový NKOD už aj GUI). Celkové riešenie bude pravdepodobne kombináciou rôznych možností. Je to ešte otvorené.

“download” button, resp. teda perma link na samotne data je na OD FS akosi “obfuskovany”, podrovnejsie vid Lepšie služby .

+ co pisal Jano:

Dalej:

Vyhlaska sa da zmenit. Aj u mna je “nahravanie zdrojovych kodov na data.gov.sk” na facepalm, ale viem, ze to PS volakedy davno takto schvalili. Kto a preco to navrhol, to uz si zial nepamatam. (Pre mna osobne je dolezitejsie mat zdrojaky a nezdrziavat to zbytocne dohadovanim sa o tom, na akom URL. URL je sekundarne, mozeme doriesit neskor. Zatial som ale napr. nevidel ziadne zdrojaky, pricom novy zakon o ISVS a aj Vyhlaska uz platia nejaky ten rok. Vynimka: microcomp · GitHub - ano, mozem namietat GitHub, mozem namietat “microcomp” a nie “nases”, ale urcite nejdem namietat to, ze su tam zmysluplne a relativne zive repozitare.)

Resp. stale sa da spravit, ze zdrojaky nebudu medzi https://data.gov.sk/datasets ale medzi napr. https://data.gov.sk/gitlab . Nuz a potom prave napr. GitLab je Open Source riesenie, mozno teda obstarat prevadzkovatela, ktory to nasadi na servery NASES-u (fyzicke alebo v statnom cloud-e). Resp. taky NASES ci Slovensko IT by to mali alebo mohli byt schopni zvladnut aj bez nejakeho velkeho obstarka na externe kapacity. Resp. to objednat ako sluzbu a len to “schovat” pod. code.gov.sk, tot ak MIRRI zvladne trivialnu zmeny Vyhlasky.

+1

Vid napr. tie “data.gov.sk repozitare”, urcite lekcie a metodika sa da odpozorovat uz porovnanim tychto dvoch vystupov z data.gov.sk 1.0 resp. eDem/MOD:

  1. lepsie: microcomp · GitHub
  2. horsie: nases-sk · GitHub

Obsah je v zasade “ten isty”, len ta prva forma je vyrazne uzitocnejsia. Zvlast ked uvazime, ze to prve bolo k dispozicii uz pred nasadenim do PROD. To je presne to, co ako obcania resp. cast obcanov, vitam(-e) a vysoko ocenujem(-e).

2 Likes

Ďakujem, doplním do zmien na kt pracujeme k tým, čo mam od @jsuchal .
Ďakujem obom :slight_smile:

2 Likes

https://www.uvo.gov.sk/vestnik/oznamenie/detail/557899

II.1.4) Stručný opis

Predmetom zákazky OD V2.0 je vytvorenie portálu pre správu Národného katalógu otvorených údajov. V tomto portáli bude vytvorené metadátové jadro pre centrálne sprístupňovanie otvorených údajov. Pre dosiahnutie cieľa projektu OD V2.0 je potrebné vybudovať potrebnú infraštruktúru. Tento dokument špecifikuje technické požiadavky infraštruktúry pre projektu OD V2.0 vrátane jednotlivých komponentov architektúry OD V2.0, ktoré bude potrebné vybudovať.
Kompletná infraštruktúra bude vybudovaná z cloudových služieb poskytovaných komerčným poskytovateľom. Infraštruktúrne služby budú dodané pre projekt OD v2.0 v štandardnej lehote do 30 dní po podpisu zmluvy.

II.1.5) Celková predpokladaná hodnota

71 798,13 EUR bez DPH

Ja len pre upresnenie. Toto je druhé VOčko pre komerčný cloud (komerčná časť vládneho cloudu).
Mrzí ma, že je to trošku nezrozumiteľne napísané v tom predmete. O tomto VOčku som už písal vyššie:

Čo sa týka prvého VOčka - tj. vytvorenie NKODu (Národný katalóg otvorených dát), tam je už podpísaná pár dní aj zmluva s MFF.
https://crz.gov.sk/zmluva/6345166/

Tu posielam aktualizovaný pohľad na jednotlivé VO v rámci OD2.0:

Každé VO má inú farbu. Toto najnovšie (druhé VO) je tá zelená časť, v realizácii je to prvé (modrá časť).

Ešte info: 31.3. bol riadiaci výbor, na ktorom sa napr. schválil prechod do realizačnej časti (kvoli podpísanému prvému VO). S čím máme teraz problém je SKIT, pretože pôvodne mal realizovať tú oranžovú časť, bohužiaľ kvoli kapacitám vypadol. Snažíme sa urobiť čo najviac na našej strane, aby VOčko bolo potom menšie a presnejšie. Tu dokončujeme podrobný OPZ, a čoskoro zverejníme aj klikateľný prototyp vo figme, čo sme na úrade spravili. Celkom úplne nie je ani vylúčené klepnutie pár riadkov kódu, ktoré by potom viťaz mohol dokončiť.

Ahojte,

aspoň pár informácií o aktuálnom stave.

Projekt ide, samozrejme, bojujeme. Je nás veľmi málo a máme veľa agendy, ale OD2.0 napreduje. Hoc teoreticky / technicky by to mohlo byť aj hotové.

ČO sa týka prvého projektu s MFFUK, tj. databáza, metadata, procesing, kvalita, sparqlendpoint, to postupne prebieha. jednak sa tvoria nové pipelines, nové slovenské urička, pripravujú sa podklady pre migráciu. Určite dojde k zmene počtu datasetov, pretože súčasná štruktúra metadát skresluje skutočný počet datasetov - voči DCAT sémantike. Niekedy to čo je už nový dataset na data.gov.sk sa nesprávne eviduje len ako distrúcia datasetu. A naopak, niekedy dataset obsahuje len www odkaz na nejaký portál, kde sú datasety. toto ale nie je dataset, treba samostatne katalogizovať všetko na danom webe. Odhady sme ešte nerobili, ja predpokladám mierny nárast počctu datasetov.

Na tomto linku
https://sk-nkod.opendata.cz/datové-sady

môžete nájsť testovaciu verziu novej databázy OD2.0 (frontend je z data.gov.cz a počas vývoja ho udržujú priamo naši projektoví partneri z MFFUK). Skvelí Jakub Klimek a Petr Škoda.
Zatiaľ sa jedná o budovanie stavu AS IS. Mnoho metadát chýba. Meranie kvality začína postupne fungovať tiež.

Celkovo z pohľadu projektu, a teda najmä nového portálu, kedže vypadol SKIT (už ani nemajú hlasovacie právo na RV), je pre nás teraz kľúčové obsadenie dvoch interných vývojárov, ktorý by robili priamo pre nás. Hoc budeme robiť aj veľké VO na dokončenie všetkých komponentov, aby sme samozrejme nečakali/nestratili polroka, tak sme s tým rátali a do rozpočtu sme ich vložili. Zadanie pre vývoj si vytvárame priamo v dátovke.

Aby som bol presný, hľadáme jedného backendistu - tam silno preferujeme javu, spring, openapi - kedže pre RDF spracovanie zatiaľ jasne vyhráva RDF4J. Ako vyzerá konkrétny kód môžete napr. vidieť na našom projekte znalosti.gov.sk
https://github.com/datova-kancelaria/znalosti.gov.sk/blob/main/src/main/java/sk/gov/knowledgegraph/rest/DataAPI.java
(vráti zoznam datasetov nahraných do databázy)

Čo sa týka frontendu, tu chceme preferovať moderné webové javascriptové frameworky: AngularJS, ReactJS, TotalJS, VueJS.
Napr. na znalosti.gov.sk je použitý Vaadin (java) a dokonca vzniklo idsk4j

avšak nie som si istý, či je to tá najlepšia cesta aj pre OD2.0. Znalosti.gov.sk sú zatiaľ prototypový projekt, tam hlavne ide o API a je to OK.
Čo sa týka OD2.0, ide o to, aby sa dala ešte nejakú dobu udgradovať, a dobre servisovať mnohými potenciálnymi silami.

Tu prichádza otázka, či napr. také Ruby on Rails spadá do takej kategórie, alebo je to menej vhodné, podobne ako napr. idsk4j. Priznám sa že v oblasti frontentu som celoživotný junior, hoc snažím sa držať krok s dobou. Aký máte na to plís názor? Ide nám o to, aby bol i frontend v budúcnosti dobre supportovateľný čo najväčšioum potencionálnou množinou ľudí. Ak bude niečo treba dorobiť, aby sa to vedelo urobiť veľmi rýchlo.

Ak Vás to zaujalo, napíšte mi prosím na miroslav.liska@mirri.gov.sk

Ďakujeme

1 Like

V tom DataApi máš fatálnu chybu na ktorú prídeš až v prevádzke a bude sa prejavovať náhodnými pádmi alebo nesprávnym vysledkom. Dôvod : databaseTreemap je atribút v singletone, takže je zdieľaný krížom cez všetkých paralelne pripojených používateľov. Riešením je zahod ten atribút, nepotrebuješ ho. Stačí ti final premenená vo vnútri metódy. Navyše ani nepotrebuješ použiť treemap, ale stačí obyčajný ArrayList keďže na výstupe chces mať rovnaké poradie v akom čítaš záznamy.

AngularJS je uz zastaraný framework. Kompletne ho prekonali, teraz ho píšu v typescripte (lebo statická traspilacia do je má svoje nesporné výhody). Po novom sa to volá už iba Angular. https://angular.io/

Hovoríš o podpore frameworkov v mnoznom čísle. Odporúčam aby ste si vybrali jeden a sústredili sa naň.

Vyzerá to že hladate ako vyskladať vývojový stack, ja zvyčajne začínam s https://www.jhipster.tech/ kde si vyberám kombináciu gradle + Spring Boot + Angular + Hibernate + H2/development + postgres/produkcia a pridávam ku tomu ešte https://projectlombok.org/

2 Likes