af6628367f
Při běžení testů nejdéle trvá namigrovat (prázdnou) databázi. Toto tento krok přeskočí. By default django pro testy používá in-memory SQLite3 databázi, která se schovat přirozeně nedá. Používání souborů trvá déle (data níž), ale další běhy už jsou rychlé. Zatím nevím, jestli se někde nemůže omylem schovávat nějaký nežádoucí stav, ale testy mi i opakovaně běží, takže se to asi nerozbíjí úplně moc. Na první pohled je uložená databáze prázdná. Pro produkci a CI bych klidně běžel testy od nuly, tam nevadí čekat pár desítek sekund až jednotky minut na výsledek. Tato optimalizace je důležitá jen pro lokální vývoj, kde je žádoucí mít testy co nejrychlejší. V .gitignore už přesně toto jméno souboru je. Nevím proč, ale možná to tak bylo by default v některém dávném Djangu. Data --- Spouštěl jsem příkaz `time ./manage.py test [--keepdb] api`. Běhy byly relativně konzistentní (±1 s) a trvaly u mě: - In memory SQLite (default): 26 s - První spuštění s db na disku (HDD): 44 s - Následná spuštění: 7.7 s Data jsou nejspíš zkreslena tím, že všechno je nejspíš nacachované v systému, ale i tak je vidět zřetelné zrychlení. Původní motivace: úplně triviální a nedatabázový test na starém notebooku běžel kolem 3:14, což je zoufale nepoužitelné když si chci napsat testy jako pomůcku pro vývoj. |
||
---|---|---|
_git_hooks | ||
aesop | ||
api | ||
data | ||
deploy_v2 | ||
docs | ||
galerie | ||
header_fotky | ||
ilustrace_odmeny | ||
korektury | ||
make | ||
mamweb | ||
odevzdavatko | ||
personalni | ||
prednasky | ||
seminar | ||
setup | ||
soustredeni | ||
treenode | ||
various | ||
vue_frontend | ||
vysledkovky | ||
.editorconfig | ||
.gitignore | ||
checklinks.sh | ||
constraints.txt | ||
convert_spaces_to_tabs.sh | ||
diff_db_backup.sh | ||
fix_json.py | ||
Makefile | ||
manage.py | ||
README.md | ||
requirements.txt |
Web M&M
Tohle je repozitář s kódem M&Mího webu. Pokud zde hledáte web samotný nebo informace o semináři, najdete je na https://mam.matfyz.cz (a upřímně nechápu, jak jste se dostali k tomuhle textu :-D)
Pokud jste tu zůstali, tak vás beztak zajímá vývoj webu (a jestli ne, tak budeme rádi, když začne :-)).
Co je M&Mweb uvnitř
Celý náš web je napsaný v Pythonu ve frameworku Django. Web běží na serveru zvaném Gimli, jako databázi používá PostgreSQL (pro lokální vývoj naopak SQLite) a všechen náš kód je uložený v Gitu na téhle gitee. Pro dokumentaci používáme Sphinx.
Jak si web pořídit
Prosím přečti si podrobnější návod v <docs/vyvoj.rst> (tady by bylo zbytečné ho duplikovat).
Jak web vyvíjet
Na webu je mnoho věcí k dělání, některé ani nevyžadují kódění (třeba uhánění orgů, aby si psali medailonky, aktualizace fotek, …), některé se naopak týkají infrastruktury pod kódem (Gitea, Gimli, …). Je proto těžké mít na to úplně obecný návod, tak tady je zhruba návod na úpravy kódu a pokud se něco z toho nedá aplikovat, tak to prostě zkus nějak udělat jinak, po svém. (Omlouvám se neinformatikům, ale líp to teď nesepíšu :-))
- Nejprve si stáhni repozitář a rozběhni si lokální web u sebe (viz <docs/vyvoj.rst>).
- Najdi si problém v Kanboardu (klikni na „Issues“ na Gitee) a/nebo se domluv s webaři, na čem bys tak mohl/a pracovat.
- Najdi místo, kde se to dá opravit a zkus to tam opravit. Uznávám, že tenhle bod je otravně obecný, pokud tápeš, zkus se zeptat zkušenějších webařů nebo podívat do dokumentace.
- Vyzkoušej, že ti to lokálně funguje tak, jak má.
- Zvládneš-li a máš-li čas, zkus to i zdokumentovat a/nebo napsat testy (TODO: chybí návod)
- Po dohodě s webaři to vyzkoušej na testwebu
- Pošli pull-request a případně zkus reagovat na komentáře
- Až se změna začlení do hlavní větve (
master
) a nasadí se web na produkci, můžeš mít radost, že se web bude používat lépe Tobě i ostatním orgům :-)
Proč pull-requesty?
Účelů pull-requestů je několik. Jednak doufáme, že pomůže webařům se orientovat v kódu, jednak tím umožňujeme dělat experimenty a dávat si zpětnou vazbu. V neposlední řadě pomáhají držet aspoň trochu konzistentní kód, což má pomoci pohodě při programování… (A asi jsem na něco zapomněl :-))