This is for czech students, hence in czech only.

Rád bych zde shrnul pár svých poznatků z vedení diplomek.

Než to zpracuju do podoby článku, dávám k dispozici pár instruktážních mailů.

Jsou psané na konkrétní situace, v článku (snad) později zobecním.

Výběr tématu

Diplomová práce je jednou z vašich posledních možností, kdy se budete moci věnovat přesně tomu, co si sami vyberete.

Dále je to vaše vizitka do budoucna - první zaměstnavatel se bude na 100 % zajímat, co jste jako diplomku dělali.

Navíc je možné, že se z diplomky stane úspěšný opensourcový projekt, případně na ní založíte start-up.

Proto:

• Věnujte výběru tématu dost času.
• Téma prodiskutujte s navrhovatelem a případnými vedoucími.
• Zjistěte si, zda by vám v případě těžkého problému pomohl nějaký expert.
• Vyzkoušejte si pár praktických tutoriálů pro technologie, které použijete.
• Ideální je, když už potřebné technologie znáte, ale i tak byste si měli rozšířit obzory.
• Promyslete, zda nehrozí zákys na něčem, co technologie neumí.
• Vyvarujte se závislosti na projektech téměř mrtvých (Caché), nevyzpytatelných (PHP), špatně zdokumentovaných nebo s nevelkou či neaktivní komunitou.

Zadání

Zadání obsahuje úkoly jak pro praktickou, tak textovou část práce. Mělo by z něj být jasné, co vlastně máte dělat.

Za účelem volnosti ve zpracování se někdy zadává vágně, ale je lepší, když se v závěru dá jasně posoudit, zda jste uspěli či ne.

Mělo by tedy obsahovat konkrétní cíle.

Nemusí však stanovovat, jak se těmto cílům dostanete. Proto se v zadání nelimitujte na podružné technologie a postupy (kromě těch, kterých se práce týká); spíše si určete mantinely.

Obvykle zadání vypadá nějak takto:

• Seznamte se s technologií MarsShelter a systémy, kterými vytváří životní podmínky pro lidskou posádku.
• Dále se seznamte s metodami používanými pro těžbu v antarktických oblastech.
• Navrhněte způsob využití těchto metod k zapuštění MarsShelter pod povrch Marsu.
• Zbudujte pokusnou podzemní základnu v Antarktidě či Grónsku obsahující aspoň dva propojené moduly MarsShelter.
  • Moduly musí být nezávisle vytápěné
  • Mezi moduly musí být schopen pohodlně projít člověk
  • Každý modul modul musí mít nezávislý vchod z povrchu.
• Vyhodnoťte, zda systémy pro podporu života mohou v takových podmínkách fungovat.

Metodika práce

Při práci na prvním větším projektu se snadno stane, že se dostanete do tzv. paralýzy vyvolaná analýzou. To je stav, kdy máte natolik složité vstupní podmínky a natolik mnoho či naopak málo možností řešení, že se točíte na místě a výsledek je bobtnající chaos. Správná metodika práce je prevencí proti uvíznutí v takovém stavu. Metodika sestává z obecných pravidel.

• Jako úplně první věc si založte textový soubor, do kterého si budete zapisovat veškeré poznámky o průběhu práce. Ten bude základem pro textovou část.
  • Soubor hned na začátku strukturujte pomocí nadpisů. Ty budou představovat fáze práce.
  • Během doby se struktura tohoto dokumentu párkrát změní - text budete přesouvat, dělit, slučovat. Více viz "Textová část".
  • Behem práce do tohoto souboru zapisujte poznámky o tom, na jaké výzvy jste narazili, jaké byly možnosti a proč jste se pro rozhodli pro ten který postup.
• Založte online repozitář (např. na Github.com). Pokud neumíte, naučte se Git, SVN nebo Mercurial - po dohodě s vedoucím.
• Věnujte podstatnou část času rešerši dosavadních výzkumů, stávajících řešení, jejich výhod a nevýhod.
• Používejte cokoliv k systematizovanému sledování postupu. Může to být textový soubor a papír, ale samozřejmě je mnohem lepší online systém, abyste mohli plány a výsledky konzultovat s vedoucím, případně konzultanty. Sloužit může jednoduchý, např. issue tracker na Github.com, ale ideální je nějaký sofistikovaný, který vám umožní i sledování a plánování projektu, např. Jira.
• Práci se věnujte pravidelně. Vyhraďte si pravidelné delší časové úseky, například každé úterý a středu od rána do čtyř, a každou neděli. Udělat diplomku na B za měsíc samozřejmě jde, ale pak budete optimalizovat na známku, a kromě odškrtnutí podmínky pro získání titulu vám takové odfláknutí nic nepřinese.
• Pravidelně informujte vedoucího o postupu. Viz "Komunikace".
• Postup neměřte na řádky kódu, ale na hotové úkoly. Analýza, návrh (třeba kreslení na papír) a plánování práce jsou také úkoly a můžou zabrat celé dny.

Komunikace - s vedoucím, s komunitou

• Pravidelně informujte vedoucího o postupu. Pokud by delší dobu neodpovídal a o vaše výsledky nejevil zájem, zvažte změnu vedoucího. Někteří vedoucí vás budou aktivně kontaktovat s žádostí o popis stavu, jiní nechají aktivitu na vás. Každopádně byste měli mít detailnější odezvu minimálně jednou za měsíc.
• Pravidelně commitujte do repozitáře. Commitů dělejte tak akorát - necommitujte každé písmenko, ale také ne velké nečitelné celky s mnoha nesouvisejícími změnami. Ideální (podle mě) je tak 1 až 8 commitů na jeden úkol v issue trackeru.
• Buďte viditelní v komunitě. Založte si blog a popisujte svůj postup. Dejte vědět o svém projektu v relevantních komunitách - fóra, mailinglisty.
• Dokumentujte veškeré funkce vaší applikace či knihovny. Pamatujte, že nezdokumentovaná funkce nikomu k ničemu nebude.
• Pokud se na něčem zaseknete, prvně hledejte; potom se ptejte na mailinglistech, fórech a webech jako je stackoverflow.com. Pokud nezískáte odpověď, potom teprve kontaktujte experty. Pokud byste je spamovali s prkotinami, v lepším případě vám odpoví "google it", v horším ztratí chuť vám pomáhat. Na druhou stranu, pokud jste poctivě hledali a zkoumali, nebojte se jim napsat. Většina budou ráda za zájem.

Vedení komunitního projektu

TBD

Textová část

Dělí se, jak znáte ze slohu ze základky, na úvod, stať a závěr.

Úvod

V úvodu rozebíráte, o čem vlastně práce je. Tj. krátké (2-3 odstavce) pojednání o tématice.

Dále konkrétní věc, kterou chcete řešit, a proč - tj. proč je současný stav nevyhovující či co jde zlepšit.

Existující řešení - jak se problém řeší (či obchází)

Stať

Hrubý návrh vašeho řešení

Představení možných technologií

Stanovení kritérií pro výběr technologií, které použijete. Měly by korelovat se zadáním a s tím, co chcete zlepšit (rychlost, snadnost, škálovatelnost, rozšiřitelnost, ...)

Vyhodnocení kritérií a výběr technologií

Opět návrh, tentokrát detailnější, se zohledněním vybraných technologií.

Problémy při realizaci a jejich řešení

Závěr

Vyhodnocení výsledků - srovnání s dosavadními kritérii podle nějakých kritérií.

Pokud se projekt uchytil v komunitě, uveďte - vypadá to dobře.

Možnosti dalšího vývoje - co byste hrozně rádi dodělali, ale nebyl čas; nicméně projekt je na to připraven (pluginovatelný nebo API, dobrá struktura).

Typografie

• Vyjděte z šablony vaší fakulty
• Rozmyslete si úrovně nadpisu, odpovídají členění
• Neodsazujte mezerami a entry
• Pozor na mezery za interpunkcí
• Obrázky mají mít popis ve vlastnostech
• Používejte odrážky
• Používejte odlišné řezy konzistentně, neplýtvejte jimi

Prezentace

• Prezentaci si minimálně třikrát natrénujte. Celou řeč si napište. Při zkoušce sledujte čas a udělejte si checkpointy.
• Nečtěte slajdy. Odrážky jsou jen odpíchnutím pro vás. Nemusíte jít bod po bodu - je to jen osnova vašeho vyprávění.
• Slajdy pojměte jako tabuli - uberte odrážky, přidejte schémata, vizualizace a ukázky kódu. Ukázka třeba zde.
• Na prezentaci přineste slajdy minimálně na dvou médiích, mějte je i někde online na URL, kterou si pamatujete.
• Nespoléhejte na konkrétní software, mějte prezentaci i jako PDF, kdyby něco.
• Mluvte hlasitě, energicky, ale ne zas pateticky. Dobře vyslovujte.
• Nedívejte se do země. Nemusíte nutně udržovat oční kontakt, ale v pauzách se na komisi podívejte.
• Zjistěte si zaměření členů komise.
• Nezabíhejte do technických detailů a zkratek; zaměřte se na přínos vaší práce.
• Pokud je práce někým použitá v praxi (firma, komunita), dejte o tom vědět.

Další zdroje

• Leaný blog: Píšete diplomku
• Blog Adama Herouta
• Čili Chilli
• PisuDiplomku.com

Technické zdroje - bude zpracováno do dalšího postu:

• http://docs.codehaus.org/display/MAVENUSER/Multi-modules+projects

>> Takže, vědecká práce má nějaké metodologie a postupy. Není třeba to

>> nějak extra hrotit, ale třeba výběr SVG vs. Canvas nabízí možnost

>> předvést, jak postupovat a zjednodušit si výběr.

>>

>> 1) Založ si nějaký textový soubor, třeba ve Wordu (nebo, jestli jsi

>> linuxák, tak LibreOffice, nebo Latex, ... ale klidně i plaintext, a

>> naformátuješ potom).

>>

>> 2) Do něj si napiš osnovu. Osnova se dělá tak, že si v onom Wordu

>> vytvoříš obsah automaticky generovaný z nadpisů (kdybys nevěděl jak,

>> zeptej se, nebo to určitě najdeš na netu), a pak začneš psát nadpisy

>> (za použití stylů "Nadpis 1", "Nadpis 2", ... a rovnou do odstavců

>> pod nimi i některé poznámky. Nějak takto:

>>

>> * Úvod

>> * cíle - co chceme dosáhnout

>> * motivace - proč to chceme dosáhnout

>>

>> * Analýza

>> * Jaký je současný stav - tj. jaká existují řešení - knihovny

>> řešící daný problém. Tuto rešerši jsem dělal já sám před lety, od té

>> doby asi bude hodně nového, takže se můžeš inspirovat, ale asi najdeš

>> kupu nových:

>> http://ondra.zizka.cz/stranky/programovani/web_javascript_ajax_canvas/javascript-isometric-libraries.texy

>>

>> * Jaké jsou technologie, které můžem použít. Sem právě patří SVG,

>> Canvas, pak možná můžeš zmínit Java applety, Flash, a vykreslování

>> pomocí <div> a <img> s průhlednými .gif nebo .png. Nebo pokud tě

>> ještě něco napadne.

>>

>> * Postup

>> Zde budou jednotlivé fáze vývoje:

>> Výběr technologií - kritéria, testy, výsledný výběr

>> Popis modelového (testovacího) problému (tj. např. "zkusíme

>> naprogramovat něco, co vykreslí mapu podobně jako Transport Tycoon,

>> nebo X-COM apocalypse, nebo Civilization 4, nebo Travian, atd...)

>> Dále návrh, jak se problém bude řešit, tj. např. pokud zvolíš

>> Canvas, tak bude potřeba kreslit odzhora dolu kvůli překryvům; pokud

>> budeš řešit kopce jako jsou v Transport Tycoon, pak je třeba vymyslet

>> algoritmus na výpočet, kde má daná dlaždice být vykreslena vzhledem k

>> výšce, atd.

>> Mezitím budeš kódit, takže ti budou přicházet další myšlenky

>> a problémy a jejich řešení, to vše si tam poznamenáš, později to

>> třeba stručně rozvedeš.

>>

>> * Závěr.

>> Zde je potom:

>> * ukázka, jak to ve výsledku funguje,

>> * zhodnocení, jak jsme splnili cíle práce,

>> * limity výskedku, tedy - co tvoje implementace neumožňuje, a

>> proč, a jestli se to dá dodělat, a to už přecházíme k ->

>> * možnosti dalšího vývoje - tj. co by se s tím dalo do

>> budoucna dělat (aneb "co bych býval udělal sám kdybych měl víc času"

>>

>> (Poznámka: Vědecké práce se píšou v množném čísle, i když ji píšeš

>> celou sám.)

>>

>> A teď konečně tomu SVG vs. Canvas:

>>

>> Obě technologie jsou dobré a obě můžou vyhovět. Takže jak už jsem

>> naznačil výše: stanov si kritéria, podle kterých vybereš. Navrhoval

>> bych:

>>

>> 1) Jednoduchost implementace. Prostě s čím se ti to líp naprogramuje.

>> SVG hodně usnadní věci tím, že má eventy jako HTML, tj. když máš

>> čtverec a v něm další, a jsou vnořené i jejich elementy, a klikneš na

>> ten vnitřní element, potom událost onClick probublá i k tomu

>> vnějšímu. Také když posuneš ten vnější, posune se i vnitřní. Atd.

>> Canvas zase asi umožnuje větší skopičiny - různé naklápění, barevné

>> filtry, 3D vykreslování, video, průhlednost, atd. atd.

>>

>> 2) Technické limity. Například je dost důležité, abys mohl po

>> vykreslení "mapy" také zjistit, kam v ní uživatel kliknul. Kdysi to

>> Canvas neumožňoval, teď snad už bude. SVG to umožňuje, posílá

>> normální JavaScriptový eventy, stejně jako v HTML - onclick objekt,

>> který má vlastnosti jako srcElement atd.

>>

>> 3) Výkon. Pokud budeš vykreslovat celou obrazovku prohlížeče na

>> monitoru 1920x1200, tak tam budou tisíce položek. Je třeba zkusit,

>> jestli to dokáže prohlížeč nějak rozumně rychle vykreslovat, a to i s

>> animacemi.

>>

>> 4) Podpora v prohlížečích. Kdysi SVG podporoval jen Firefox. Teď už

>> to snad budou všechny hlavní prohlížeče. Canvas je myslím jako

>> součást HTML 5 podporovaný ve všech nových.

>>

>> To by asi mohlo stačit.

>> Ta kritéria zhodnotíš nějakým jednoduchým testem - jednoduchou

>> stránkou, kde zkusíš danou věc. Co nejjednodušeji. Nejdelší bude asi

>> ta 3), kde bude nutné vykreslit těch X * Y buněk, a pak je nějak

>> posunovat - ale i to by mělo být tak na 2 dny (vypadals jako

>> ostřílený webař, tak možná i za den

>>

>> No a výsledky si oznámkuješ a na základě toho se rozhodneš. Kdyby to

>> vyšlo nastejno, tak si prostě hodíš mincí Ale ta 1) by to měla v

>> tom případě rozhodnout.