Součástí hodnocení je semestrální práce. Uvítáme, pokud si vyberete vlastní téma, které budete moci použít v jiném předmětu nebo sami pro sebe. Téma je třeba nechat si od nás schválit. Komplexnější témata mohou být po konzultaci s cvičícími uznaná jako jediná podmínka pro splnění předmětu.
Ve všech případech (kromě případných explicitních výjimek) musí práce splňovat tyto požadavky:
-
musí být napsaná v jazyce Python verze 3.4 nebo vyšší (Cython se samozřejmě také počítá),
-
musí splnit zadání, na kterém jsme se dohodli,
-
musí být v gitovém repozitáři,
-
kód musí splňovat konvence,
-
kód, komentáře i dokumentace musí být v angličtině,
-
commity musí obsahovat vhodně atomické změny a mít vysvětlující message,
-
kód musí být dostatečně pokryt testy (nechceme stanovovat číselnou hranici, použijte selský rozum),
-
projekt musí být zabalen jako pythonní balíček (za zveřejnění na PyPI pod svobodnou licencí jsou body navíc),
-
projekt by měl stavět na nějakém tématu probraném v předmětu MI-PYT.
Nemusí jít nutně o nový projekt nebo nápad. Přispění do existujícího open-source projektu je také možné. Máte oblíbenou knihovnu v Pythonu a chybí vám funkce na zalévání kočiček? Dopiště ji. Na čemkoliv, co dává smysl, se dá domluvit.
Pro nerozhodné časem připravíme několik témat, které můžete použít, budeme ale raději, pokud si zvolíte téma vlastní.
-
Téma schváleno do: 19.12.2018 (předposlední cvičení)
-
Odevzdáno do: 31.1.2019 včetně, možnost pozdního odevzdání do 9.2.2019 s penalizací
Pozdní odevzdání semestrálky do 9.2.2019 včetně s penalizací -10 bodů. Tato penalizace se nepočítá do podmínky 25 bodů za semestrálku. Je tedy možné mít 35 bodů ze semestru a 25-10 ze semestrálky a stále dostat E.
Následuje seznam témat, které si můžete po dohodě s námi zvolit, pokud nemáte téma vlastní. V žádném případě není vhodné na zde vypsaném tématu rovnou začít pracovat a doufat, že ho potom prostě jen odevzdáte. I téma z tohoto seznamu musí být odladěno a schváleno, témata uvedená zde jsou pouze rámcová.
Na FIT funguje API Sirius, které slouží jako zdroj dat pro aplikaci Fittable a poskytuje exporty rozvrhů ve formátu iCalendar (ICS) pro kalendářní aplikace. Nevýhodou exportu ICS je, že kalendářní aplikace neumožňují kalendář modifikovat, případně pokud si uživatel soubor ICS importuje, ztratí možnost synchronizace.
Cílem projektu je exponovat kalendářní data přes standardní protokol CalDAV a umožnit uživatelům osobní úpravy rozvrhu. Individuální změny se uloží pro každého uživatele zvlášť (tj. pokud změním poznámku u přednášky, ostatní uživatelé jí neuvidí). Synchronizace změn bude pouze jednosměrná, ze Siria do CalDAV; například pokud si smažu z osobního rozvrhu cvičení, v kalendářní aplikaci jej neuvidím, ale nadále jej uvidím v aplikaci Fittable.
Pro implementaci využijte existující implementace CalDAV pro Python, například Radicale nebo CalendarServer. Projekt může být implementovaný jako rozšíření stávajícího kalendářního serveru nebo jako samostatná aplikace, která synchronizuje Sirius s CalDAV serverem.
Uživatel si bude moci:
-
přidat osobní rozvrh do kalendářní aplikace
-
(volitelně) přidat přes CalDAV i ostatní rozvrhy, např. místností, vyučujících a předmětů
-
upravit události v osobním rozvrhu z kalendářní aplikace
-
smazat událost
-
změnit název a poznámku události
-
(volitelně) změnit účast u události
-
(volitelně) přesunout událost
-
(volitelně) přidávat přílohy k událostem
-
(volitelně) měnit události u jiných rozvrhů, než osobního
Pokud se změní události na straně Siria, změny se projeví v rozvrzích uživatelů. Aplikace však zachová uživatelské změny v událostech (např. pokud se v Siriovi změní čas události, nezmění se poznámka uživatele).
(Volitelně / dle potřeby) Aplikace bude mít webové rozhraní, které uživateli poskytne autentizační údaje pro CalDAV a případně možnost nastavit další volby.
-
Aplikace bude poskytovat CalDAV rozhraní s autentizací pro přístup k rozvrhům uživatelů.
-
Aplikace bude uchovávat změny událostí pro každého uživatele.
-
Aplikace bude využívat REST rozhraní pro Sirius, případně ICS export.
-
Autentizace bude prováděná jednou z následujících metod:
-
Pomocí autorizačního tokenu unikátního pro každého uživatele z API Sirius.
-
Přes OAuth server FIT.
-
Aplikace bude respektovat oprávnění uživatelů stanovená serverem Sirius.
-
Aplikace bude ukládat data do vlastní databáze; doporučená je relační databáze PostgreSQL, po diskuzi můžete zvolit i jiné řešení.
Podstata práce je stejná jako u zadání CalDAV server pro Sirius. Google Calendar podporuje přístup přes CalDAV, ale slouží pouze jako CalDAV server, nikoliv klient. Synchronizace s Google Calendar by proto byla řešená samostatnou aplikací, která by importovala data do Google Calendar přes CalDAV rozhraní, nebo přes Google Calendar API.
Aplikace bude mít webové rozhraní, přes které uživatel:
-
autorizuje přístup k API Sirius přes OAuth server,
-
udělí přístup ke svému Google kalendáři a zvolí do kterého kalendáře se mají události importovat;
-
alternativně mu je zpřístupněn samostatný kalendář ve správě aplikace.
Aplikace musí umožňovat autentizaci proti Google Apps for Education na FIT. Volitelně by aplikace mohla pracovat se zdroji (Calendar Resources), pro alokaci místnosti, ve které se událost koná.
Kontaktní osoba: Jan Vlnas.
In Showmax, we have two calendar systems which need to be synchronized.
See also SSP portal and subscribe there to get a financial reward too.
-
Investigate possibilities of synchronization (both calendars have slightly different features) and representation of different pieces of information in both calendars.
-
Investigate ways to keep them in sync when editing happens on either side.
-
Create a tool to synchronize calendar events from Google calendar to internal Showmax Phabricator installation via APIs, email or other automated means. The tool should:
-
be documented (basic README, commented source code);
-
have proper logging implemented;
-
be either triggered regularly or run as a daemon.
-
There is an interface to synchronize Google calendar one way to Phabricator. However that doesn’t fit our requirements. For example:
-
Many calendars are too big on Google so the import ends with a timeout.
-
We need to be able to filter events somehow.
-
Events are not paired with Phabricator users (by email address).
Working prototype in Python that would pass code review and would run on our Jenkins machine in our Debian based docker container (we’ll help with this step) or in our private cloud (also running Debian based docker containers). It can use PostgreSQL database if needed. In case it is going to run as a daemon, it should be implemented as a 12 factor app.
In Showmax, we have a manually maintained API documentation. We want to move the documentation to the code using OpenAPI specification.
See also SSP portal and subscribe there to get financial reward too.
-
Given a Grape API and a corresponding hand-written documentation in the RST (ReStructuredText) format, annotate the source code of the API with the information found in the docs.
-
This requires you to parse the RST and for each documented Grape API end-point, locate the end-point in the given source file, and attach the information into the source in the format required by Swagger.
-
Then, Swagger can be executed to generate the actual documentation output.
-
The ultimate goal is to get rid of the handwritten doc altogether.
-
There are some troubles: the documentation is handwritten, and hence it will contain little deviations in style. You need to come up with heuristics at times to stick the right information from the handwritten doc into the appropriate places in the source code. However, this is doable, as the handwritten doc is fairly simple.
-
In case the tool would fail (this should be at most few percent of documentation that doesn’t repeat) it should give operator enough information on what to handle manually and how.
A working tool with complete source code. It must be possible to run the tool you’ve provided on at least three API source files and obtain correct, swagger-processable source file containing the original API with all the metadata from the original handwritten doc.
Zadání spočívá ve vytvoření služby, která bude mít na starost synchronizaci definic štítků mezi různými repozitáři na různých službách.
Uživatel připraví konfiguraci štítků (jména, barvy, popisy) a konfiguraci repozitářů (služba, identifikátor repozitáře). Ideálně do gitového repozitáře.
Služba pak zajistí, že všechny definované repozitáře budou mít tyto štítky definované.
Přístupové údaje ke službám se budou zadávat postranním kanálem. Nebudou tedy součástí konfigurace, aby konfigurace mohla být veřejná.
Mělo by se jednat o modulární aplikaci, která musí být jednoduše rozšířitelná o další platformy. Součástí odevzdání musí být podpora pro GitHub a další jinou službu (Pagure, GitLab…).
Možno implementovat jako webovou aplikaci nebo jako cron job běžící na nějakém CI.
Kontaktní osobou je Miro Hrončok.