REST API a Python

Jedna z mojich dlžôb bolo vytvorenie REST rozhrania k morfologickému analyzátoru. Rozhranie pre python ma trápilo viac (github/pymajka), takže malo výrazne vyššiu prioritu. Vytvoriť REST by preto mala byť len rutina, takže ma to ani príliš nelákalo. Požiadavky na výkon som nemal, akurát som nechcel žiaden veľký framework.

Prvý pokus bol s web.py, tutoriál funguje úplne krásne. Prvé API postavené za pár minút, ale vyskytol sa dosť divný problém. Spolupráca s modulom pymajka fungovala krásne z príkazového riadku, ale cez HTTP to končilo s core dump. Riešil som a riešil, ale nepodarilo sa. Padalo to na mieste, kde céčková knižnica mala všetky parametre :/

Po týždni som sa dostal k druhému pokusu. Tentokrát som skúsil bottle a ten funguje od začiatku ako má. 

Prečítal som: Python Testing - Beginner's Guide

Kniha nebola písaná pre niekoho ako som ja, čo som ale mohol čakať už podľa
názvu. Napriek tomu som sa ňu tešil, pretože masívnejšie využitie testovanie
ma ešte len čaká. Kniha od čitateľa nečaká veľa, ale jednoznačne sa hodí mať
nejaký základný prehľad o Pythone. Na knihu pre začiatočníkov sú však podľa
mňa priložené zdrojáky príliš dlhé (a viac-menej nudné). Aj preto sa mi
podarilo prečítať/prebehnúť celú knihu za jedno poobedie.

Kapitoly sa postupne zameriavajú na využitie Doctest, unittest, nosetests a
mock. Práve ten mock ma zaujímal najviac, ale to vysvetlenie mi prišlo také
nijaké a asi by som z toho pochopil len tú základnú myšlienku, ale na
samostný spôsob ako to použiť by som potreboval iný materiál. A to aj
napriek tomu, že príkladov je tam dostatok.

Záver? Nekupovať.

Záverečné práce za posledný semester

Dnes sa odovzdali posledné bakalárske práce tohoto semestra. S trochou šťastia to bol môj posledný semester s veľkým počtom prác. Oproti minulým semestrom som si síce pomohol (vďaka Adam :)), ale stále ich bolo tesne pod dvadsať. Jedna práca neprešla, pár ich prešlo len tesne a tri sú nominované na cenu dekana. Pretože sa nájdu aj zaujímavé práce u niekoho iného, tak tu je zoznam prác z FI, ktoré stoja za to.

Iné, ale podľa názvu ma zaujali a po prečítaní si ich chcem pamätať:

• Martin Otáhal - Analýza a návrh architektúry v MapReduce
• Po zbežnom prečítaní to vyzerá ako rozumný návod na pochopenie MapReduce a jeho inštaláciu/konfiguráciu.
• Daniela Plachtová - Umelá inteligencia do OpenTTD
• Umelá inteligencia pre spoločnosť, ktorá prepravuje tovar/osoby vlakmi implementovaná do openTTD. Pri snahe o implementáciu UI do nejakej našej hry by to mohla byť dobrá inšpirácia. 
• Michal Hlaváč - System for Recognizing Textual Entailment utilizing Expert Knowledge
• Hoci posudky nie sú nič extra, tak pretože o téme prakticky nič neviem, dostáva sa do zoznamu na čítanie. A áno, nefunguje to.
•  Petr Machovec - Automatická sumarizace textu

Ako sa hodnotí bakalárska/diplomová práca? [0.4]

Tento príspevok bude zameraný na kontrolu záverečných prác z informatiky (na univerzite nezáleží), pravidlá sú vlastne rovnaké pre študenta, vedúceho aj oponenta. Pravidlá sú zoradené chronologicky podľa toho, kedy som na daný problém narazil.

1. Vedúci/oponent vie často o téme viac než popisuje samotná práca. Preto je dôležité, aby úroveň práca bola taká, že ju pochopí aj osoba (absolvent informatiky), ktorý o téme nič nevie. Takže, ak použijeme regulárne výrazy, tak nevysvetľujeme. V prípade termínov ako bundling, alebo Context Dependency Injection je vysvetlenie skutočne nutné, potrebujeme preto krátky (adekvátny práci) popis v texte a odkaz na zdroj, kde sa čitateľ dozvie viac.
2. Prácu by okrem autora, vedúceho a oponenta mali pochopiť aj iní. Úvod by mal pochopiť každý VŠ vzdelaný človek, zbytok práce absolvent informatiky. 
3. Odkazovanie do bibliografie je tiež oriešok. Typicky a obvykle správne sa zadáva:
• priamo do textu -> len odkazy do literatúry (nie URL)
• pod čiaru -> typicky URL na webové stránky projektov
4. Pri položkách v bibliografii je potrebné dodržiavať "normu", ktorá sa líši fakultu od fakulty. Problém nastáva pri webových stránkach, kde je okrem URL potrebné zadať aj dátum čerpania.
5. Ak je práca zameraná na tému, kde sa dá očakávať, že to bolo riešené, tak je potrebné overiť, že sa na rozumne aktuálne práce odkazuje. Odborné články nájdete na scholar.google.com, ktorý vytvorí aj bibliografický záznam. Robí to automaticky, preto je na záver to potrebné ručne zjednotiť, aby to vyzeralo správne (pozor na diakritiku) a rovnako.
6. Odkazy na blogy, diskusné fóra, ... sú často najlepší zdroj praktických znalostí. Na popisy algoritmov, informatiky, .. sú často vhodnejšie. odborné články a monografie. Wikipediu radšej nepoužívať vôbec.
7. Ak sa preberá text/obrázok ako copy&paste (aj doslovný preklad), tak je nutné správne označiť zdroj. V prípade textu dať aj vizuálne najavo, že tento text je doslovná citácia. Inak sa to dá chápať ako plagiátorstvo.
8. UML diagramy (a aj všetky ostatné obrázky) sú vítané, ale ak tam sú bezúčelne, tak to komisiu naštve viac ako by tam neboli.
9. Ak zadanie explicitne menuje funkcionalitu, tak to práca musí splniť. Ak zadanie píše explicitne o vyhodnotení, testovaní, ... tak to práca tiež musí splniť. Ak sa to nedá, tak je potrebné vysvetliť a odôvodniť v texte, že to nie je reálna požiadavka. Obvykle je lepšie zmeniť včas oficiálne zadanie.
10. Jazyk práce (čeština, slovenčina, angličtina) by mal byť dodržiavaný počas celej práce. Takže je potrebné používať aj príslušné odborné termíny a vyhnúť sa slovám ako debugovať, logovať. V prípade, že preklad neexistuje, tak si ho nemusíte vymýšlať. Ak očakávate, že tých nepreložiteľných termínov tam bude priveľa, tak to píšte rovno anglicky.
11. Kvalita textu je z pohľadu univerzity aspoň rovnako dôležitá ako kvalita kódu aplikácie. Ak nemáte nikoho na kontrolu gramatiky, preklepov, predložiek tak ho za študentské ceny nájdete v ISe na inzercii.
12. Väčšina záverečných prác nemá teoretickú časť (veta, hypotéza, dôkaz, ...), ale textovú časť a praktickú časť. Niektoré osoby sú na to (vcelku oprávnene) háklivé.
13. Počet znakov záverečnej práce nie je univerzálne merítko. Ak by práca mala byť príliš dlhá, tak je vhodné vhodné časti (sady grafov, používateľský manuál) do príloh. 
14. Po odovzdaní musí byť všetko v informačnom systéme. Github je fajn, ale aj tak to tam má byť nakopírované.
15. Pre práce, kde sa niečo programuje odporúčam nasledujúcu štruktúru
• Popis aktuálnych (podobných) riešení
• Podrobná analýza problému
• Návrh a implementácia
• *Použité technológie -> ak ich zadanie explicitne zmieňuje, tak aj pred popis aktuálnych riešení, inak niekde k analýze/návrhu
• Vyhodnotenie výsledkov 
16. Ak vedúci uvidí prácu až tesne pred odovzdaním, tak času na opravy je už málo. A skoro určite to bude z posudku zrejmé. Komunikovať a posielať text je treba priebežne, netreba čakať na všetky kapitoly.
17. Odovzdaný kód by mal mať:
• dokumentáciu (API vždy, inak je to plus), ideálne podľa JavaDoc, PEP, ...
• súbory by mali byť rozumne veľké (riadky, objekty, funkcie)
18. Odovzdaný kód by nemal mať:
• divné konštrukcie, magic numbers, ...
• zakomentovaný kód bez jasnej dokumentácie
19. Bonus: ako na obhajobu
• Vybrať ruky z vačkov nohavíc
• Hovoriť nahlas a pozerať sa na ľudí
• Obrázok na slajde je plus
• Na slajdoch by nemalo byť všetko + nečítať
• Hodnotiť svoju prácu vecne a odborne

Prečítal som: Tajemství Sit'n'Go, Phil Shaw

Druhá z kníh za štyri eurá dopadla výrazne lepšie. Jedná sa síce o SnG, ktoré aktuálne nehrávam, ale prišli mi výborná :) Na rozdiel od predchádzajúcej knihy, kde sa hral poker vyslovene pasívne, sa tu hrá normálny poker. S ohľadom na charakteristiku SnG je to samozrejme od istej fázy len all-in/fold, ale kniha to podáva veľmi rozumne. Celá kniha je postavená na počítaní ICM a tom ako to dopadá podľa veľkosti blindov. Každej z častí sa venuje jedna kapitola, takže máme hru rannú, strednú, neskorú, troch hráčov a heads-up. Jasne, že to sú SnG, takže žetóny žiadne a pri 2-3 hráčov to už podľa mňa nie je poker, ktorý by som chcel hrávať. Na záver je zoznam kvízových hand (~100 strán), takže sa to dá celé vyskúšať aj bez peňazí. Ale tak 80-90% som dal správne po prečítaní knihy a len odhadometricky, takže to nie sú úplne hraničné situácie.

Kupovať.

Prečítal som: Poker jak si vydělat hraním No-limit Hold'em (cash game)

Pokrové knihy vidím málokedy v bežnom kníhkupectve, tak som sa neudržal a naposledy kúpil rovno dve v akcii za 4€. Kniha (2010, preklad 2013) možno kedysi mala nejaký zmysel, ale dnes fakt nie. Prevažná časť textu je zameraná na konzervatívneho hráča a čakanie na výborný setup. S AK sa limpuje z buttonu, situácie 80/20 sa neriešia all-inom, lebo by to mohlo súperovi dôjsť. Podľa mňa to tak nefunguje, teda minimálne na micro-stakes. A v tom je ďalší problém, kniha píše v podstate o živej hre (mid-stakes) a fakt neviem ako sa hrá na 10/20$ a nebude to vedieť ani väčšina čitateľov.

Nekupovať.

Prečítal som: The Power Of Habit, Charles Duhigg

Konečne sa mi podarilo prečítať aj túto knihu. Medzi rozčítanými sa nachádzala asi od novembra, kedy som sa dostal do polovice.

Kniha sa zaoberá o tom ako vyzerajú naše zvyky (habit, tj. nie kultúrne zvyky), aký majú na náš vplyv a čo vďaka nim kto dokázal. Príklady sa mi veľmi páčili, to najlepšie na knihe je, že vlastne nie je prvoplánovo motivačná. Až v prílohe sa trochu rieši ako by mala vyzerať naša práca so zvykmi, ale ktoré zvyky sú vhodné a ktoré menej vôbec nerieši.

Asi najlepšia časť pre mňa bola tá, ktorá hovorila o trénerovi amerického futbalu a zmene tímu, tak aby pracovala automaticky (na základe zvyku). Zaujímavá perlička bola o gambleroch, ktorí pri takmer-výhre prežívajú podobné pocity akoby vyhrali a preto vydržia hrať dlhšie, o viac peňazí, ...