A lap 2022. november 20., 22:54-kori változata

Szabványok, ajánlások

• folyamatábra szabványok: https://irh.inf.unideb.hu/~vargai/APA/Flowchart_hu.html
• rendszertervezés-demo (inkl. meta-modell): https://www.youtube.com/watch?v=Fr3mNBbeys8
• a tervezés szabványszerű megközelítésének lehetősége: https://www.youtube.com/watch?v=RlgKfeu18h4
• projektmenedzsment, minőségmenedzsment, stb. - IT-projektek (vö. szoftverfejlesztés esetére is): https://www.youtube.com/watch?v=RlgKfeu18h4
• katalógus: Ide feltölthetjük az esetlegesen külső helyen hostolt adatfájlok linkjeit? <--igen

Tervezési kockázatok

Túlspecifikálás vs. metaszintű leírás

• a tervezés egyik/első/külső rétegének mindenképpen csak annyit szabad, de annyit kell specifikálnia, hogy a quasi bármilyen programnyelven való megvalósítás ezen "kotta" alapján lehetséges legyen
• a választott programnyelvre vonatkozó tervrészletek csak ezt az általános kottát illene, hogy kövessék időben és logikailag is
• vö. https://miau.my-x.hu/mediawiki/index.php/BPROF:2dm#Adatt.C3.A1rol.C3.A1s

Problémák, ötletek

• a tervezési folyamatban nem a fejlesztés tényleges (főleg nem utólagos) problémái dokumentálandók
• a tervezési folyamatban felmerülő probléma-jelenségek = kockázatok
• hasonlóképpen a tervezési folyamatban az ötletek, mint döntési pontok kell, hogy ábrázolásra kerüljenek:
  • indítvány: kitől/miért/mi
  • döntés: ki által/milyen indoklás mellett

Ideális rendszertervezési folyamat

A wiki-szócikk kapcsán javasolt működési mód (ez lett volna az órai anyag is): készüljön el elsőként a TELJES tartalomjegyzék-tervezet azaz megfelelő számú =...= jelek között álljon elő minden modul/réteg/blokk/fejezet/alfejezet címe s ezt optimalizáljuk közösen majd a teljes véglegesnek remélt fejezet-struktúra kerüljön át vitalapra (is) ahol minden egyes fejezethez (egységhez) fel kell írni: milyen kérdésekre fog a fejezet válaszokat adni s ezt is optimalizáljuk közösen ezután még mindig a vitalapon minden egyes kérdéshez kerüljön hozzárendelésre: mennyi karaktert igényel a válasz és kell-e majd képi támogatás, ha igen mennyi kép kell? ezt is optimalizáljuk közösen UTÁNA indulhat a szócikkben a kérdések tételes megválaszolása inkl. képe/ábrák (melyek ugye általam lesznek amiau-ra feltéve és így lesz hivatkozható URL-jük) a kérdések megválaszolásakor minden választ közösen tudunk majd optimalizálni (pl. alapvetően távmunkában) a többiek számára a teljes folyamat maga is tananyag a fejezetstruktúrához az eddigi ajánlott irodalmak kellenek minimum és minden más, ami még előkerül és logikusan illeszkedik a tervezési folyamatba...

WIKI-szócikk szerkesztése

• lehetőség szerint minden sor esetén szabványosságra törekvés
  • pl. ne legyen manuális számozás,
  • pl. ne legyen manuális kötőjel,
  • pl. ne legyen
    

Ötletek

• Github-on puzzle katalógus repo, amibe bárki bele tud committolni.
• Ezt fetchelne az alkalmazás és így ott is meg tudna esetlegesen jelenni egy külön marketplace nézet, és innen lehetne aktiválni egy egy témát.Ezt rendezni, szűrni lehetne. Plusz, Github csillagok alapján népszerűségi sorrend is felállítható
• puzzle inditasakor a puzzlet letrehozo szemely által elvárt azonosító input (neptun kod,nev,becenév stb (nem kell ezzel foglalkoznom h valid-e,mert nekem elég ha egy string az output))- Ez is belekerülne a logfajlba, mely segítené a teszt írójának beazonosítását.
• előző ellentéte: puzzle anonim leadásának lehetősége
• puzzle kiértékelése a tanár részéről:
  • output fajlokat osszeszedi (nem erdekel, hogy hogyan, emaillel beküldik a diákok stb….), és beolvastatja a programmal, ami csinal egy egyszeru excel táblát, akár kimutatásokkal
• puzzlek között lépkedni lehet előre hátra, ha van több puzzle (ezt a puzzle szerkesztője engedélyhezheti/tilthatja le)
• teszt folytatasanak engedelyezese is tanartol fuggjon, logolva lesz a szüneteltetés
• tesztben a kép pathje nem képre mutat,hanem egy más fajta fájlra, akkor ezt le kell kezelni (ilyen hiba case-eket ki kell listázni, és ki kell küszöbölni)
• más, nem 3x3-mas teszt használatát engedélyezni*
• logger teszt irása közben:
• logolni fogja a szoftver a user általi: alkalmazás váltást, alkalmazás minimalizálást, és az ezekhez tartozó időpontot is
• log az egyenlore egy txt fajl
• “log {timeOfStart}.txt”
• lehetőség a webes rendszerbe való fejlesztéshez(???):

itt ebben ha megvaltoztatom a

COLOR_GREEN_DOT_1

-eket

COLOR_GREEN_DOT_2

-re, akkor at fog váltani 2 pöttyre, és a játék el fogja fogadni amikor odahúzom a 2 pöttyös zöld mezőbe

• ne lehessen a json fájl stringjeibe olyan adatot beírni,amit esetleg a C# parancsként értelmez (valós biztonsági rés ez? kell e ez fixálni?)
• Tartalmi ellenőrzés, minimum obszcén szavak kiszűrése 3 nyelven (magyar,angol,német) (erre adatbázis vs api)

https://www.nuget.org/packages/Profanity.Detector/

Saját kvíz publiklálása

Lehetőség van saját magunk által készített teszt publikálására is. A publikált tesztek a "Marketplace" (vagy valami ehhez hasonló,később kitalált fantázianévvel ellátott) menüben fog megjelenni.
Az adatokat a Github organizacioban (https://github.com/GTS-catalog) kell nyilt,saját repositoryba feltölteni, es a szoftver ezeket fogja fetchelni,megjeleníteni.

Problémák a nyílt forráskóddal:

• nem lehet ellenőrizni, hogy minden teszt adatfájl megfelelő -> erre megoldás lehet egy custom Github Action,ami ellenőrzi az adatok validságát (ha lehet ilyet)
• trollkodás: cenzúrázatlan adatok is felkerülhetnek, akár egy egyszerű github regisztrációval -> új akadály: cenzúrázzon maga a keretrendszer is? (kellene gondolom elég erősen)
• duplikáció -> megint csak Github Action-ös megoldás?

GitHub repository struktúrája/kikötések (még nem tudom):

• Readme.md
• mappa a képekkel
• tesztConfig.json
• ...

Readme.md fájl meg fog jelenni az alkalmazáson belül is, tehát fontos egy rövid ismertető fájl készítése a fejlesztett tesztről.
Már lehet fejleszteni tesztet, hiszen minden adott hozzá (kivéve a struktura , az még készül, illetve a jogosultság githubon)
Probléma: nincs jogosultság githubon, és nem is tudok egyenlore automatikusan addolni usereket az organizációhoz. Plusz weboldal kellene a user regisztrációhoz. (Ez nem lenne tul nagy biztonsági rés?/informatikailag butaság?)
Jogosultság adása CURL parancs használatával:

curl -X PUT -u <UserName>:<Generated-Token>https://api.github.com/repos/<user-name>/<repo-name-to-add-collaborator>/collaborators/<user-name-to-add-as-collaborator>

https://github.com/thundergolfer/automated-github-organization-invites

Köv. probléma:
el kell fogadni a pull requesteket manuálisan:
erre már biztosan van github action
Ebből fakadó probléma:
minőségbiztosítás, hogy biztosan megfelelő-e az adat logikailag.