Kloni nalog

[matijapretnar]

Po manjšem razmisleku glede klonov (torej nalog, ki se z isto vsebino pojavljajo na več koncih), se mi zdi najboljša rešitev sledeča.

• Ko narediš kopijo, se naredi v celoti nova naloga, vendar se v obe v polje clones zapiše, da imata identično vsebino.
• Ko se naloga popravi, se vsem učiteljem klonov nekje pokaže, da je bil eden od klonov spremenjen, in se vpraša, ali bi posodobili tudi svoje naloge. Če ja, se vsebina popravi, če ne, se prekine povezavo.

Na tak način se izognemo temu, da bi kdo po nesreči popravljal našo nalogo, saj lahko vsak posodablja le tiste naloge, za katere ima tako ali tako pravico urejanja. Če imaš pravico urejanja pri več predmetih, lahko hkrati popraviš pri vseh. Če pa je kakšen klon v "lasti" drugega učitelja, pa je to njegova odločitev.

Kako se vam zdi?

[lokarM]

Mislim, da je to dobra rešitev. Dobro bi jo bilo izpeljati na ta način, da bi, preden se odločiš, videl spremembe.

A prekopiram in dobim A1. Potem prekopiram A1 in dobim A2. Se sedaj "ve", da so to vse tri naloge iste? Verjetno da.

In še to - pri iskanju bi bilo morda smiselno v spisku zadetkov pustiti le eno nalogo in zraven označiti, da ima še n klonov, ter omogočiti, da z dodatnim klikom zveš, v katerih sklopih so ti kloni.

---

Par zadev je potrebno še razmisliti ...

Recimo, da sem naredil nalogo A in sem jo sedaj razmnožil in imam poleg osnovne A v različnih problemsetih še A1, A2, A3, A4. Spremenim A3. Ali se moram za vsakega od klonov odločiti, ali naj bo spremenjen ali ne [osebno mislim, da DA]?

Kaj se zgodi, dokler se ne odločiš? Verjetno uporabljaš nespremenjen klon?

Kaj, če bom spremenil poleg A3 še A1 [in se pri klonih še nisem nič odločil glede A3]. Ali pri A2 dobim izbiro za posodabljanje bodisi iz A3 in A1? In če se za najprej odločim, da spremembe A3 NE upoštevam, ali imam možnost, da upoštevam spremembo v A1 (in ostanem njegov klon). Kaj pa pri A3 - mi pove, da je A1 spremenjena in mi omogoči, da vzamem njegove spremembe?

[gregorjerse]

Se najinih 5 centov.

1. Ne komplicirajmo. Stvari morajo ostati preproste. Zaenkat imamo samo ucitelje in studente. Predagam, da nalogo v danem predmetu lahko skopira katerikoli ucitelj v tem predmetu in jo premakne kamor jo lahko. Naloga pri tem postane njegova in lahko upravlja z njo po mili volji. Kaksnih dodatnih pravic ne bi uvajal.
2. Pri kopiranju lahko zapisemo, iz katere naloge smo izsli. Kaksne avtomatike s preverjanjem spremb se jaz ne bi sel, saj te zelo obremenjuje streznik in je tezko implementirati pravilno (poleg pomislekov Matila L. se lahko spomnim se vsaj 3 druge zoprne scenarije, ki jih je zelo tezko (nemogoce?) pokriti pravilno).
3. Ce ze hocemo 'avtomatske' posodobitve nalog bi naredil takole.
   • ucitelji, ki lahko vidijo izpeljano nalogo, imajo poleg nje se gumb 'Posodobi' (ki se lahko prikaze samo v primeru, ko je posodobitev na voljo).
   • ob kliku nanj ti pokaze razlike med tvojo nalogo in nalogo, iz katere je bila izpeljana.
   • nalogo lahko potem posodobis (ali pa tudi ne). Ce jo posodobis, se njena vsebina prepise z vsebino naloge, iz katere je naloga izpeljana.

Bi bilo tako v redu? Se vedno bi imel hierarhijo nalog, ne bi pa drzal vseh 'klonov' dane naloge.

[matijapretnar]

Glede pravic se strinjam, ne razumem pa čisto, kakšno avtomatiko imaš v glavi. Ali bi bila kaj drugačna, če bi imel samo enega starša namesto vseh klonov?

Še to, če imaš samo enega starša, bi nastal sledeč problem. Npr, imaš nalogo A1 in jo skopiraš še v nalogi A2 in A3 pri dveh drugih predmetih. Potem ravno urejaš A3 in popraviš napako. Kako zdaj to spremembo hitro spraviš do A1 in A2?

[lokarM]

Zaenkat imamo samo ucitelje in studente. Predagam, da nalogo v danem predmetu lahko skopira katerikoli ucitelj v tem predmetu in jo premakne kamor jo lahko. Naloga pri tem postane njegova in lahko upravlja z njo po mili volji. Kaksnih dodatnih pravic ne bi uvajal.

Ne razumem "katerikoli ucitelj v tem predmetu" - imamo potem ucitelje vezane na določen predmet? Če da, ali bomo potem mi (kdo?) skrbeli za dodeljevanje predmetov učitljem oz. učitelje predmetom?

In če vem prav, naj bi objavili sistem, ki bi ga lahko uporabljali "vsi" učitelji. že tako ali tako bomomo imeli pribleme, kako ločiti med učiteljem in učencem. In verjetno moramo učiteljem omogočiti, da določenih nalog pač "ne delijo". V tem trenutku mi je najbolj všeč rešitev, da je vsaka naloga, ki jo sestavi učitelj, avtomatsko opremljena s potrditveno kljukico - naloga je javna (kar pomeni, da gre v skupen "pool" in jo lahko od tam pobere (in s tem v svoj predmet naredi kopijo). Če pa kljukico pobriše, je v tem poolu ni [torej se ne ubadamo s tem, da bi nekaterim učitelj omogočal kopiranje, drugim pa ne - torej le vsem učiteljem ali pa nobenemu]

Ampak to je pravzaprav neodvisno od posodabljanja, saj bi vsaj jaz osebno rad imel sistem, kjer bi tudi v sklopu istega predmeta in med "lastnimi" nalogami imel možnost, da posodabljam (ali pa ne) izpeljanke!

[matijapretnar]

Kot vidim, se pogovarjamo o dveh stvareh:

1) kloniranje nalog, kjer isto nalogo, katere rešitev poznaš, uporabljaš v več predmetih 2) izposoja nalog, kjer si v svoj predmet izposodiš nalogo nekoga drugega, vendar je ne moreš urejati in ne vidiš njene rešitve.

Predlagam enostavno in predvidljivo rešitev za 1) (z @gregorjerse sva enkrat imela podobno, tu je pa popravljen še en manjši detajl).

Vsaki nalogi dodamo še hash njene celotne vsebine, torej navodil, rešitve in testov. Vsakič, ko nalogo popraviš in naložiš, se pogleda, ali obstajo na strežniku še kakšne naloge z enakim hashem, za katere imaš pravico urejanja. Če so, te vpraša npr.:

Na strežniku naloge z enako vsebino obstajajo tudi v sledečih sklopih:
1. Uvod v programiranje / Zanka for
2. Programiranje 1 / Zanke
Ali jih posodobim?

Namesto hasha bi lahko imeli tudi vnos o skupinah nalog v bazi, vendar mi je hash všeč, ker so naloge z enako vsebino vedno povezane, ne glede na to, kako so nastale (copy&paste, ali pa si pri obeh naredil isti popravek, ...)

[lokarM]

Kar se tiče STVARI 1, se mi zdi omenjena rešitev dobra in smiselna.

Za STVAR 2 pa smo še vedno tam, da se pravzaprav sploh nismo zmenili glede načina uporabe Toma in se pravzaprav obnašamo, kot da bomo Tomo uporabljali na posvem isti način, kot starega. Verjetno to NI možno, ker imaš nenadoma precej večjo množico uporabnikov ...

[matijapretnar]

Za Stvar 2 smo se na sestanku dogovorili, da učitelji pri kateremkoli predmetu lahko katerokoli nalogo, ki jo vidijo, ne glede na vidnost njenih rešitev, z rešitvami vred prekopirajo v svoj predmet. Načeloma bomo pravice učiteljev dodeljevali ročno, zato študentje do rešitev ne bodo mogli priti okoli ovinka. Sklope z izpitnimi nalogami pa že zdaj lahko skrijemo, s čimer jih učitelji pri drugih predmetih ne vidijo.

[matijapretnar]

Za Stvar 2 predlagam, da se ob kopiranju naloge lahko učitelj odloči za lastno kopijo (torej varianta 1) ali pa za "izposojo", pri čemer vzame v zakup, da ne bo imel vpliva na vsebino naloge (razen če bo dobil pravice za urejanje v prvotnem predmetu). Mogoče to, da so pravice vezane na prvotni predmet, ni najboljše, ampak dokler ne najdemo boljše rešitve, bo tudi to šlo.

[lokarM]

Ja, mislim, da je smiselno. Ob kopiranju se torej odločiš, ali za samostojno kopijo ali za klon. In verjetno je to smiselno tudi za nadaljnje kopije, klone, ... Torej če narediš kopijo, ki jo potem nekdo klonira, ima tisti s klonom seveda dostop do klona (samostojne) kopije in ne originala ... IN če nekdo kopira klon, je ta njegova kopija od sedaj samostojna ...

Torej nekako bi imeli tako sliko

Kopija več ali manj začne svojo pot ...

Če imaš klon - ali lahko vidiš vsebino naloge (zagotovo ;-) ), rešitev naloge in teste? Osebno mislim, da da ... Torej nalogo lahko vidiš kot "-edit", le če narediš kakšne spremembe, ti Tomo pove, da ne gre, ker imaš klona!

Fino bi bilo tudi, če bi se ob spremembi originala, vse "lastnike" kopij in klonov obvestilo (po e-pošti), da je bil original spremenjen (in kje je original ;-) ) Pri tem je mišljeno, da, če se spremeni rdeča (oz. zelena) pika na moji sliki, potem sporočilo dobijo vsi potomci te barvne pike ...

Če pa menite, da bi to lahko povzročalo zmedo, potem je morda bolje, da prepošiljanje sporočil rdeča pika ustavi (torej, da rdeča pika, ki je dobila sporočilo, da se je njen prednik spremenil, tega NE posreduje več svojim potomcem ... - ker končno je za njih ona original in ne predniki!)

[matijapretnar]

Ne, stvar vidim bolj enostavno. Za primerjavo (malo drugače sem pobarval, da se vidi struktura):

Vse izposojene naloge kažejo na isto prvotno nalogo. Med njimi ni neke posebne hierarhije, saj se spreminjajo natanko tedaj, ko se spremeni prvotna. Mogoče lahko vse, ki so si jo izposodili, obvestimo o tem, vendar so prej še druge stvari, ki jih je treba narediti. Ko narediš klon, torej samostojno nalogo, se povezava prekine. Spet, mogoče bi lahko imeli okvirno povezavo, od kod je naloga prišla (pikčaste sive črtice), ampak to je spet v drugem planu.

[lokarM]

Saj dejansko je bilo mišljeno tako, kot si narisal (a skupaj s pikčastimi povezavami). Pri "navpični" liniji sem želel le poudariti, da v praksi kdo pač naredi klon klona (interno pa se seveda vodi "koren", oziroma so vsi kloni na nivoju 2 - če je original na 1).

ja, verjetno lahko idejo "pikčastih" povezav spustimo (odložimo za kdaj kasneje). Torej - kakor hitro narediš kopijo, je to povsem samostojna naloga, ki ne ve nič o tem, od kje je prišla.

Uporabnik klon torej vidi kompletno nalogo (rešitve in teste) - le popraviti je ne more/sme?

Kaj pa glede obveščanja - ali je možno, da kloni zvedo, da se je original spremenil? In če to gre - če naloga ve, kdo vse jo klonira, potem ji načeloma ni potrebno vedeti, ali jo klonira ali kopira in se ob spremebi enostavno obvesti vse, ki so iz nje izšli. Avtorji, ki so uporabili klon vedo, da je bil s tem njegova naloga avtomatsko spremenjena, za avtorje s kopijami pa je morda to samo "signal", da je morda smisleno popraviti tudi njihovo kopijo (a zato so zadolženi avtorji koopije).
In seveda, obveščanje se ustavi na prvem nivoju - kloni kopije ne dobijo obvestila, da se je original spremenil (končno je zanje original tisto, kar so klonirali in načeloma sploh ne vejo, da je to kopija nečesa ...)

[nbasic]

Trenutno je model sledeč: imamo Problem, ki ima lastnosti title, description, problem_set (foreign key, ki se sklicuje na ProblemSet), history, tags in language. Poleg tega imamo model ProblemSet.

Za klone bi bilo smiselno vpeljati še model VirtualProbem. Nova situacija bi bila sledeča:

Problem bi dobil še lastnost author. Avtor naloge bi lahko vedno urejal svojo nalogo, tudi če ta ni razporejena v noben sklop. Model VirtualProbem bi imel dva tuja ključa in sicer problem in problem_set, poleg tega pa še lastnost editable.

Hec je v tem, da se lahko različne inštance VirtualProblem sklicujejo na isti Problem. Če si nekdo nalogo sposodi, potem se naredi samo nov VirtualProblem, ki dobil ima editable nastavljen na false. Učitelj lahko naredi vedno novo svojo kopijo naloge. Pri tem se naredi tako kopija od Problem kot od VirtualProblem, editable pa se nastavi na true.

Vprašanje je, kdaj lahko učitelj ureja neko nalogo. To lahko v primeru, ko je avtor ali pa ko je učitelj pri vsaj enem predmetu, ki ima sklop, ki vsebuje virtualproblem, ki se sklicuje na problem.

Seveda bi bilo treba popraviti tudi skripte za urejanje in sicer bi skripta vedno izpisala seznam vseh sklopov, v katerih živi naloga, ki jo spreminjamo.

[matijapretnar]

Mogoče bi namesto VirtualProblem rekli Problem, namesto (stari) Problem pa ProblemContents.

[nbasic]

Poraja se eno čisto filozofsko vprašanje oz. design issue. Trenutno so oddaje študentov vezane na ProblemContents. Ali naj bodo oddaje po novem vezane na Problem ali na ProblemContents? Torej, če se ista naloga oz. "klon" pojavi še pri nekem drugem predmetu, ali jo mora študent reševati ponovno ali se "prizna ista rešitev"?

[matijapretnar]

Moje mnenje je, da naj se prizna ista rešitev. Učenec lahko tako ali tako vzame svojo staro rešitev in jo prilepi namesto nove. Če mu rešitve ne priznamo, mu le delamo dodatno brezvezno delo. @lokarM, mogoče tvoje mnenje?

[lokarM]

Sam mislim, da je za študenta vsaka naloga "nova". Res je sicer, kar pravi @matijapretnar glede kopiranja, vendar mislim, da (če bo študent to uporabil) še vedno ni čisto "brezvezno delo". Študent je pač "prepoznal", da gre za isti problem, poiskal njegovo rešitev in jo uporabil. Če mu nalogo avtomatično "priznamo", mu niti opaziti ni treba, da gre za enako/isto nalogo.
Premišljal sem načeloma o scenarijih, ko imamo istega študenta pri dveh različnih predmetih, ki imata neko skupno (isto) nalogo. Načeloma se mi zdi, da se to lahko zgodi npr. takole:

1. - [naloga se pojavi drugo leto pri drugem predmetu] Denimo pri Programiranju 2 za ponavljanje uporabimo določeno nalogo, ki smo jo zastavili že lansko leto pri Programiranju 1. Mislim, da tu nikakor ne želimo, da so rešitve "avtomatično" prenesejo
2. - [študent ponavlja predmet] Študent ponovno opravlja predmet Programiranje 1. Tudi tu menim, da ni dobro, da se mu naloge avtomatično prenesejo. Vem, da to lahko naredi /in načeloma bodo to nekateri uporabljali/. A če študent
3. - [študent opravlja dva predmeta z isto nalogo v istem šolskem letu] Pri predmetu X in predmetu Y se uporabi ista naloga. Tu pa je morda avtomatičen prenos "neškodljiv" (ali morda celo zaželen)

Ampak v splošnem mislim, da je 3. precej manj pogosti slučaj, kot 1. in 2. In za oba 1. in 2. mislim, da je pedagoško slabo, če je rešitev avtomatično prenešena.

Torej moj predlog je - za študenta je vsaka naloga samostojna.

[lokarM]

Glede urejanja klonov pa mislim, da naj bi veljalo tako, da kakor hitro se klon ureja (pa naj bo to sprememba besedila, sprememba testa, rešitve ...) to ni več klon ampak samostojna naloga (kopija). Morda bi bilo smiselno na to opozoriti učitelja, ki klon spreminja.

Morda, če je to tehnično lažje, ali pa bolj "modelsko čisto", pa lahko rečemo, da klonov ni mogoče spreminjati (lahko se vidi vsebina, testi - govorim seveda o učiteljih) klona kot takega pa se ne da spremeniti (če ga učitelj želi spremeniti, mora pač narediti kopijo, ki je samostojna). Vendar se verjetno to zakomplicira, če se se učitelj naknadno (potem, ko so jo njegovi študenti že reševali) odloči, da ne želi, da bi bila njegova naloga klon, ampak samostojna naloga (ker ne želi, da jo prvotni avtor še spremeni, želi dodati kak test ...) - takrat bi verjetno želel, da se rešitve te naloge njegovih študentov ohranijo, kar se ob kopiranju seveda ne zgodi!

Torej moj predlog:

Če učitelj hoče popraviti klon, je obveščen, da bo s tem prekinil povezavo do originala in da je sedaj ta naloga "samostojna". Vse rešitve se pri študentih tega predmeta (če je bil klon pri tem predmetu že reševan) ohranijo.

[matijapretnar]

Plan je sledeč:

• [x] določi ER diagram
• [x] dodaj razred courses.ProblemInstance, ki vsebuje atribute iz Problem, ki se tičejo predmetov
• [ ] v razred Problem dodaj owner referenco na ProblemInstance, prek katerega se ureja besedilo (in se uporablja v obstoječih attemptih, ki niso vezani na ProblemInstance)
• [x] v Attempt dodaj povezavo na ProblemInstance (ki je začasno null)
• [x] napiši migracije, ki za vsak Problem ustvarijo ProblemInstance, ki kaže nanj (in obratno)
• [ ] v Attempt dodaj validacijo cikla (dve možni poti do Problema)
• [x] napiši migracije, ki vsakemu Attemptu nastavijo ustrezen ProblemInstance
• [ ] iz razreda Problempobriši stvari, ki so zdaj v ProblemInstance
• [ ] popravi kodo in preveri, da vse dela kot običajno
• [ ] dodaj metode za izposojo in kopiranje
• [ ] ugotovi, kako boš te migracije pognal na HistoricalAttemptih na strežniku, ker jih je ogromno
• [ ] v Attemptu pobriši null
• [ ] v uporabniškem vmesniku omogoči nove funkcionalnosti

[matijapretnar]

Tole:

• [ ] related_name za ProblemInstance pusti na problems in atribute iz ustreznega Problema daj kot https://github.com/Property, da nam ni treba preveč popravljati kode

bi raje spremenil v

• [ ] problems je iterator čez vse Probleme, ki spadajo v dani ProblemSet

Ker načeloma ProblemInstance vsebuje samo informacijo o tem, v kakšnem vrstnem redu se pojavljajo (ter kasneje, kateri so vidni). Potem lahko uporabimo več ali manj enako infrastrukturo kot prej. Na ProblemInstance pa bi prenesel metode, ki se tičejo oddanih rešitev (saj so zdaj vezane na ProblemInstance).

[matijapretnar]

Gledam stare zapiske z Bleda, pa je vredno omeniti še sledeče stvari:

• sklopov/predmetov se ne bo nikoli kloniralo, kvečjemu se bo naredil nov sklop/predmet, v katerem bodo vse naloge polinkane.
• linkamo lahko samo naloge iz repozitorijev

[lokarM]

Je zadnje (linkanje le iz repozirorijev) res dobro? Kako pa potem izvesti scenarij:

imam lastno nalogo (ni v repozitoriju). Želim jo uporabiti v več predmetih, a tako, da bom popravljal le krovno nalogo.

Če pa s tem zadevo zapletemo in bi zahtevala precej več dela in s tem kasnejšo implemntacijo, se takoj ospoved zgornjemu scenariju in sem za "linkamo (izposojamo) lahko le naloge iz repozitorijev"

[matijapretnar]

Ja, seveda, izposojaš si lahko tudi naloge iz repozitorijev ali iz svojih predmetov. Verjetno je potem tako, da kjerkoli jo popraviš, popraviš vse?

[lokarM]

Hm, mislim, da s "kjerkoli" pridemo spet do problema, ki smo ga imeli "pred leti".

Torej:

imam repozitorij R in svoja predmeta A in B. V predmetu B si izposodim nalogo nR iz repozitorija R in nalogi n1A in n2A iz predmeta A .

• Popravim nalogo nR v repoziroriju. V predmetu B imam popravljeno to nalogo (še vedno je izposojena)
• Popravim nalogo nR v predmetu B. naloga nR se v repozitoriju ne spremeni, naloga nR v predmetu B je sedaj samostojna (ne več izposojena) in če nR v repoziroriju spremenim, to nima več vpliva na nalogo v predmetu B.
• V predmetu A popravim nalogo n1A. Popravki so vidni (saj je kopija) tudi v B.
• V predmetu B popravim nalogo n2A. Naloga se v predmetu A NE spremeni. V predmetu B ta naloga postane samostojna (ni več izposojena)

V predmetu C (ki ni moj in ni repozitorij) vidim zanimivo nalogo. Lahko jo le skopiram, ne morem pa si je izposoditi.

Bo tako smiselno?

[matijapretnar]

Ja, mogoče je tako bolj pregledno. Lahko naredimo tudi tako.

[matijapretnar]

Pri klonih sem se spomnil še ene neizogibne težave. Po klonih bo poskus vezan tudi na ProblemInstance, trenutne datoteke, ki jih imajo učenci naložene, pa tega podatka nimajo. K sreči imamo že vzpostavljen mehanizem nadgrajevanja datotek, ampak še vseeno bo treba za te naloge najti v katero instanco spadajo. Glede na to, kar se pogovarjamo zgoraj, bo vsak Problem (razen pobrisanih in tistih v repozitorijih) moral imeti tudi nek kanoničen ProblemInstance, prek katerega se ga bo lahko urejalo. Predlagam, da se za pri obstoječih datotekah vzame tega. Na začetku bomo itak vsak trenuten problem zamenjali s parom Problem & ProblemInstance, ki bosta kazala eden na drugega.