wegguy.cz

Občasný deník matfyzáka

Ačkoliv slovo "matfyzák" v nadpisu nabádá k tomu to očekávat, nechci tady psát blog o tom, jak jsem se naučil zavázat si tkaničku (i když i o tom by se daly psát romány...).

V současné době pracuji na svém prvním velkém projektu a kromě hromady starostí a práce je to pro mě taky hromada zkušeností. Rád bych se aspoň o část té hromady podělil s kýmkoliv, kdo se náhodou nachomýtne a bude mu to užitečné, a později, až se skleróza projeví naplno, sám se sebou.

Je mi naprosto jasné, že i přes deset let programování a titul Bc. z matfyzu jsem pořád ještě úplný amatér a všechny moje čerstvé zkušenosti jsou pro ostatní samozřejmé banality, a nedělám si iluze o užitečnosti téhle stránky pro kohokoliv kromě těch, kdo jsou v oboru ještě většími amatéry než já. Snad aspoň někdo z nich sem zabloudí a nějakou tu zkušenost si odnese.

Na téhle stránce by se tedy, pokud mě to nepřestane jako obvykle po chvíli bavit, měly vynořovat a zase zanořovat fragmenty mých zkušeností, postřehů, doporučení. Koncipováno jako průvodce neznámému vojínovi základní programátorské služby.

Obhájeno, zapsáno, zapito... (14.03.2008 14:09, #167)

...v hospodě, kde číšnici dělá jedna takymatfyzačka. Ale to sem nepatří.

O obhajobě toho moc napsat nemůžu, protože jsem v té době lyžoval kdesi v Alpách. Taky odevzdávat jsem nebyl já, ani předvádět to oponentovi...celkem vzato jsem se ke konci skoro flákal. Ale co už, měl jsem nejvíc odpracovaných hodin.

Zkusím shrnout aspoň nějaké závěrečné poučení a poučky z našeho projektu.

Softwarový projekt na MFF

Oficiální délka tvání projektu je podle nových pravidel 9 měsíců. Reálně jsme na projektu dělali skoro rok, a to nepočítám přípravu, úvodní dohadování se zákazníkem, hledání vedoucího a podobně.

Prvních zhruba 6 měsíců práce na projektu bylo celkem poučných a užitečných šest měsíců. Naučili jsme se leccos z reálného světa, kde si člověk nesmolí jen tak něco sám a pro sebe. Velkou studnicí zkušeností bylo, že jsme dělali reálný projekt pro reálného zákazníka (reálný zákazník se pozná zejména podle toho, že neví určitě, co chce, ale zato ví přesně, že to chce hned - no, nejpozději do týdne).

Pak se to ale tak trochu zvrtlo, jak už jsem koneckonců psal. Přišla fáze, kdy už se moc nevymýšlelo a nenavrhovalo, ale spíš dodělávalo, testovalo, opravovalo, dokumentovalo.

A nejhorší zkušenost asi mám z posledních dvou tří měsíců, kdy jsme začali finišovat a připravovat finální podobu aplikace i dokumentace k odevzdání. Tam se podle mého největší přednost projektu, reálný zákazník, začala jevit jako podstatná překážka při obhajobě. Projektová komise má pravděpodobně suplovat "reálného" zadavatele projektům, které skutečného (čti komerčního) zadavatele nemají a zadává je škola. My zadavatele měli a požadavky komise se tváří v tvář tomuto faktu splňovaly těžko. Bylo nám v podstatě řečeno, že to, že máme reálného zadavatele, je náš problém, a k obhajobě že to půjde podle požadavků komise. Takže jsme vlastně museli udělat aplikaci splňující požadavky dvou "zadavatelů", leckdy dost odlišné až protichůdné.

Obhajoba například požaduje odevzdání "hotového díla". Že v reálu děláte aplikaci na zakázku, u které se vysloveně předpokládá průběžný vývoj ještě po několik let? Nezájem. Že návod k použití má podle dohody sepsat zadavatel podle svých představ? Ale komise chce mít návod k použití od vás.

Nakonec jsme kvůli obhajobě udělali dost reálně zbytečné práce a (s pomocí vedoucí) složitě formulovali, že to a to není součástí projektu, abychom mohli říct, že co bylo součástí, je hotové.

Zlášť otřesným zážitkem, co jsem slyšel od kolegů, byl přístup komise k obhajobě samotné. Na obhajobu se od začátku uráčil přijít jeden z devíti členů komise, předseda komise přišel asi v půlce a nevěděl pak prakticky, o co se jedná oprava: kolega, co tam byl, mě opravil - předseda komise nepřišel vůbec. Naši roční práci prý zhodnotili slovy "No jo, tak obhájeno, další".

Na drouhou stranu pozitivní zkušeností, zlášť pro další generace matfyzáků, je, že v novém formátu už není vyžadována polovědecká objevná práce, ono dříve často zmiňované slibování hor a dolů. Obhájili jsme s projektem, ve kterém nebylo nic objevného, nebyla v něm použita žádná vyjímečná myšlenka, žádný extra algoritmus. Ale byl to projekt, na kterém jsme odpracovali podle našich záznamů 1650 hodin, trval 11 měsíců a byl z reálného světa. Nebyl to projekt, který by přinesl něco objevného světu, ale přinesl dost zkušeností nám. Tedy předmět, z něhož vytěžili primárně jeho studenti, ne fakulta.

Obecně

Tady je pár obecných pouček pro začátečníky, jako jsme (byli) my:

Komunikace - podle mě jsou zásadní pravidelné schůzky, e-mailová konference a ICQ nebo jiný instant messenger. Primárně jsme věci řešili přes mailing list, ICQ posloužilo pro rychlé řešení čehokoliv s jedním člověkem a týdenní schůzky se ukázaly nepostradatelné zejména kvůli motivaci - každý se snažil mít do schůzky to, co měl za ten týden udělat, opravdu hotové.

Repository - o nutnosti používat pro kód a další soubory repository, umožňující současnou práci celého týmu na projektu, snad ani nemusím psát. Zvolili jsme CVS. A protože jsme žili v reálném světě, nevyhnuli jsme se ani takovým libůstkám, jako je větvení.

Evidence chyb - používali jsme systém Mantis. Že to bez issue tracking systému nepůjde jsme zjistili, když jsme začali potřetí či počtvrté objevovat již jednou nalezené chyby, které ale v e-mailové konferenci "tak nějak zapadly".

Dokumentace - dokumentace v kódu je samozřejmostí, a ke konci začali už i moji kolegové zjišťovat, že není od věci popis funkce napsat dřív než její tělo. Kromě toho jsme myšlenky a návody k použití různých modulů aplikace dokumentovali s pomocí wiki (Mediawiki, konkrétně). Učesat nějak dokumentaci do odevzdatelné podoby, přidat uživatelskou a programátorskou příručku nám trvalo skoro půl roku.

Další dokumenty - je dobré si schovávat (nejlíp v repository) všechny dokumenty vzniklé při práci. A hlavně je užitečné schovávat si všechny dokumenty, které vám kdy zákazník poslal, nejlíp s datem přijetí. Kromě toho bych rozhodně doporučil zaznamenávat si důsledně počty odpracovaných hodin.

Modelování rozhraní aplikace - velice užitečná věcička. Protože naše aplikace byla webová stránka, použili jsme opět wiki (v ní se stránky a vazby mezi nimi dělají opravdu snadno a rychle). Nejen že nám model GUI umožnil najít místa, kde jsme zákazníka špatně pochopili, často taky našel místa, kde zákazník netušil, co chce, často ani netušil, že má něco chtít. Nad modelem to pak byl nucen domyslet. Zásadní je, že model se mění nesrovnale snáz, než výsledná aplikace.

Několik dokumentů, které jsme vytvořili (tedy hlavně já), když jsme se (všichni) učili se zmíněnými nástroji, jsem posbíral a nabízím vám je v tomhle ZIP archivu.

Trocha statistiky

Protože jsme si všichni víceméně poctivě psali odpracované hodiny, můžu posloužit několika grafy, které aspoň orientačně ukazují průběh naší práce.

Práce během měsíců v absolutních číslech:
průběh prací absolutně

Podíly jednotlivých druhů činností během měsíců:
podíly druhů činností na celokvém objemu prací během měsíců

Podíly druhů činností celkem:
podíly druhů činností na celokvém objemu prací

Finišujeme (10.02.2008 23:32, #156)

Náš projekt se konečně chýlí ke konci. Koncem února odevzdáváme. Píšu konečně, protože ač bychom nějaký měsíc navíc určitě užili, asi bychom to už psychicky nevydrželi.

V říjnu jsem psal o tom, že už jsme za bodem, kdy nás to přestalo bavit. A byla to pravda - produktivita šla rapidně dolů. Lepší je to až teď tváří v tvář termínu obhajoby. Nutno poznamenat, že krizi částečně zavinilo taky to, že dva z pěti členů týmu se museli věnovat ďábelské semestrálce na OSy (pro nematfyzáky - předmět Operační systémy s ďábelskou semestrálkou, kde letos museli ve skupinkách po třech až čtyřech lidech za semestr naprogramovat vlastní operační systém) a neměli skoro na nic jiného, tedy ani na projekt, čas. A můj pocit neproduktivity je určitě taky způsobený tím, že sám jsem koncem prázdnin dělal hodně a od října už konstruktivního skoro nic.

Dokumentace

Někdy v říjnu jsme se rozhodli, že už je načase začít dávat dohromady dokumentaci. Nějakou jsme už samozřejmě měli, jednak hi-level popisy některých tříd z úplného začátku a druhak jakés takés dokumentační komentáře v kódu, ale celé to potřebovalo důkladnou revizi a sjednocení úpravy a technických detailů.

Nebyl to špatný nápad.

Ty čtyři měsíce jsme opravdu strávili dokumentací velkou část času a díky včasnému začátku to vypadá, že to možná i stihneme dát do použitelného stavu. Bohužel generovanou dokumentaci asi při obhajobě jako primární dokument nepoužijeme, protože se nikomu z nás nechce tisknout 976 stran ve dvou exemplářích - ale je to solidní základ pro údržbu aplikace a můžeme se na ni beze studu odkazovat v papírově odevzdávaných dokumentech. Ty se rodí z revidovaných verzí popisů jednotlivých částí aplikace, jak jsme je psali v úvodu projektu vždy autor pro ostatní členy týmu. Velký problém budeme mít asi s uživatelskou dokumentací, protože na uživatelském rozhraní není moc co vysvětlovat, pokud nepočítám věty typu "pro přihlášení klikněte na odkaz přihlásit". Rozhraním k uživateli je jeho prohlížeč, rozhraní by mělo být prakticky intuitivní.

Testování

Zhruba v půlce prosince jsme se rozhodli trochu důkladněji otestovat nejnovější verzi aplikace, než ji nasadíme k zákazníkovi na produkční server.

To taky nebyl špatný nápad.

Objevil jsem v sobě dosud utajený talent pro testování. A v aplikaci jsem objevil desítky chyb. Zhruba dvě třetiny testů, které jsem si na ni vymyslel, skončily chybou.

V týmu mě teď opravdu nemají rádi.

Po tom, co jsem popsal, nepřekvapí, že z testování předvánoční aktualizace se vpodstatě stalo skoro finální testování před odevzdáním. Po odstranění těch vážných z objevených chyb (a v mnoha případech taky odstranění chyb nalezených v těch opravách...už chápete, proč mě nemají rádi?) jsme aktualizaci konečně nasadili bez známějších velkých chyb - dneska.

Ryba hnije od hlavy

Jedna z dalších věcí, která nám přitížila koncem roku a začátkem toho letošního, je, že na projekt začal tak trochu kašlat kromě mě a všech ostatních taky vedoucí našeho týmu. Ano, ten, o kterém jsem psal, že mu nemám skoro co vytknout. Už mám.

Jeho zimní koníčky, zabírající mu čtyři až pět dní v týdnu, nás ostatní štvaly asi všechny. Teď sníh není, ale zase by rád v dubnu odevzdal diplomku, takže má opět málo času. Nevyčítám mu, že nepracuje, hodin nemá nejmíň, ale ani nevede. O Vánocích to vypustili všichni a po Vánocích tak nějak nebyl nikdo, kdo by projekt postrkoval kupředu.

V tom depresivním výčtu, co všechno nás v posledních měsících trápilo, nacházím jen jeden pozitivní bod - za ty čtyři měsíce se přecijen srovnaly trochu počty odpracovaných hodin mezi jednotlivými členy týmu. Mezi prvním a posledním na výkazu odpracovaných hodin je sice pořád skoro dvojnásobný rozdíl, ale osobně to vnímám tak, že nakonec se opravdu nikdo z nás s ostatními nesvezl. Jeden z těch, na které jsem "nadával", si vzal na starost naprogramování jedné celé velké části aplikace, včetně libového AJAXu. S AJAXem jsem dělal jen jednou a docela mi to stačilo. A jiný z těch s méně hodinami si v podstatě vzal na triko kompletaci dokumentace a v posledních týdnech maká opravdu dnem i nocí.

Z posledního

Jak jsme na tom tři týdny před odevzdáním? Máme skoro hotovou implementaci, chybí jen dodělat a dotestovat jednu část, kterou jsme původně ani my dělat neměli. Kromě ní je aplikace i vcelku slušně otestovaná. Máme myslím velice dobrou dokumentaci kódu a skoro hotovou programátorskou dokumentaci. Zbývá tedy už snad jen dotáhnout do konce tyto, nějak dobušit uživatelskou dokumentaci, připravit prezentaci, nějak to obhájit a umřít.

Budeme rádi, až to budeme mít za sebou.

Motivace je základ (15.10.2007 14:36, #105)

Známou poučku o tom, že práce by člověka měla bavit, protože ji dělá větší část svého života, bych snad ani nemusel opakovat. Přesto ji opakuji, protože platí víc než jsem si myslel. A platí i u školního projektu.
Pracovat bez motivace je prakticky nemožné. Lidé si motivaci, zdá se, rozdělili do dvou škatulek - první je "má práce mě baví" a druhá "dostávám za to hodně zaplaceno". Protože však málokdo dostává tolik peněz, aby mu dostatečně vynahradily uspokojení z práce, která ho baví (kolik peněz to ale přesně je, to musí asi zjistit každý sám), skončíme většinou u požadavku, aby nás práce bavila.
A u školního projektu to platí dvojnásob. Za školní projekt vám asi těžko někdo dá hodně peněz, a tak všechno závisí především na tom, aby všechny v týmu práce bavila a vydržela je bavit těch 9 měsíců. V případě školního projektu je tu, pravda, ještě další motivace v podobě povinnosti předmětu, ta je však spíš bičem než cukrem a příliš nepomáhá - snad jen v závěrečné fázi projektu, kdy drží všechny nad vodou a nedovolí jim vzdát projekt před cílem.
Pokusím se nastínit hlavní věci, které ovlivní "zábavnost" projektu, tak, jak se na to dívám já po 7 měsících práce na projektu (můj pohled se za tu dobu poměrně dost změnil). A akčoliv píšu o školním projektu, myslím, že leccos platí i obecněji.

Zadání projektu

Každého napadne, že tohle bude stěžejní část motivace. Otázka ale je, které aspekty zadání jsou ty podstatné.
Když jsem zvažoval, zda se připojím k tomuto týmu a budu řešit nabídnuté zadání, zkoumal jsem kromě toho, co a v čem se bude dělat a jestli je to reálné za devět měsíců stihnout, taky dost to, kolik za to dostaneme. To je blbost. Samozřejmě že peníze něco motivace přidají a je rozhodně příjemné, když za svou práci nějaké dostanete, ale nečekejte a nežádejte nic moc. Na školním projektu vám asi nikdo nedá tolik, aby to vynahradilo jinou motivaci, to už jsem psal. Tedy - peníze projektu jistě dodají aspoň nějaký "smysl", ale nejde tu až tak moc o to, kolik jich bude. Jsou důležitější věci.
Důležitější je, aby vás práce na projektu bavila, abyste se nemuseli do něj od začátku do konce nutit. Proto by projekt měl směřovat do oblasti, která vás baví, a neměl by pro vás být ani příliš náročný, ani příliš jednoduchý. Důvodů, proč vás projekt může bavit, je spousta. Vyberte si. Ale hlavně si nevybírejte projekt proto, že zní jako něco čemu nebudete muset dát moc času. Lepší dělat 9 měsíců něco co vás baví dělat, než se 5 měsíců trápit.

Programovací jazyk

Ačkoliv každý správný matfyzák ví, že běžně používané programovací jazyky jsou v podstatě všechny stejné a jen se jinak píší (a každý druhý matfyzák viděl i důkaz tohoto tvrzení), každý má skupinu svých oblíbených jazyků a skupinu jazyků, které "nemusí".
Poučka je jasná - vyberte si projekt psaný v jazyce, který vám je blízký. Je nesmysl snažit se programovat v jazyce, ve kterém neumíte bez přemýšlení a bez chyby udělat zřetězení dvou textů nebo projít pole. Na projektu budete dělat 9 měsíců skoro denně - a pokud polovinu z tohoto času ztratíte psaním a přepisováním základních jednoduchých věcí, hodně brzo vás to přestane bavit.
Druhá věc je jít do projektu v jazyce, který příliš neovládáte, právě se záměrem se ho pořádně naučit. Mějte ale na paměti, že jde o experiment na 9 měsíců, z kterého po prvních pár týdnech už není snadné vycouvat.

Tým

Tady se dostáváme k bodu, který je naprosto klíčový a přitom asi nejhůř ovlivnitelný.
Základní poučka, proč programovat čistě a dobře, zní: protože z dobrého kódu máte dobrý pocit, a motivuje vás to psát dál.
Zní to divně, ale je to pravda - aspoň pro mě osobně. Můj názor je ten, že dobrý programátor by měl poznat, když napíše "prasárnu", měl by se za ni stydět a měl by takovou prasárnu opravit dřív, než ji commitne a ostatní ji uvidí. Tenhle reflex jsem si naštěstí osvojil (asi i díky tomu, že se občas vrátím k nějakému vlastnímu staršímu kódu a pokusím se v něm něco změnit).
Při práci v týmu ovšem tohle nabývá dalšího rozměru - budete totiž muset číst kód i po ostatních. V lepším případě budete každý pracovat v oddělené části aplikace - pak je jen nutné mít opravdu dobré rozhraní mezi jednotlivými částmi. V horším, jako v našem projektu, bude každý dělat všechno. Potom je opravdu důležité, aby všichni měli podobné standardy úrovně kódu. Jeden jediný člověk, který nemá tuhle mentální zábranu psát špatný kód, nebo dokonce špatný kód vůbec nepozná, může znechutit práci celému týmu. Věřte, že opravovat každý týden jednu a tutéž prasárnu zase na novém místě je dost na nervy.
Žádnou dobrou poučku v tomhle případě v rukávu nemám - poznat dobrého programátora není snadné. Takže jen zopakuji, co už každý dobře ví - nepodceňujte výběr svých spolupracovníků, nepovažujte za ztrátu času podívat se na úroveň zdrojových kodů z dřívějších projektů každého potenciálního kolegy. Vězte, že opravdu lze narazit na člověka, který projekt nejen nikam neposune, ale dokonce ho může brzdit a táhnout zpátky. A hlavně pamatujte, že ani titul Bc. z Matfyzu není zárukou kvality (i když tohle se mi píše těžko a dlouho jsem tomu odmítal uvěřit).

Vedoucí týmu

Týmy na softwarový projekt jsou podle pravdiel vedené některým z vyučujících z fakulty. Neslibujte si ale od tohodle příliš - dobrý vedoucí vám pomůže s administrativou kolem projektu a komunikací s projektovou komisí, občas na vás dohlédne, ale nebud mít čas ani motivaci dělat o moc víc. Skutečný vedoucí týmu bude muset být jeden z týmu. Je důležité, aby to byl člověk, který má autoritu, zkušenosti, vůli i rozum na to, aby tohle stádo matfyzáků vedl. Musí to být člověk, který si dokáže nechat poradit, dokáže vést diskuzi, ale dokáže taky určit autoritativně, co se jak bude dělat, a dohlédnout na to, aby to tak bylo. Musí dokázat trpělivě vysvětlit podstatu chyby některého z kolegů z týmu, ale taky pořádně ho seřvat za její opakování příště. A ostatní z týmu musí uznávat jeho právo tohle všechno dělat.

Poslední měsíce projektu

Další papírová poučka, jejíž platnost si právě ověřuji v praxi, říká, že prakticky u každého programátora a projektu přijde chvíle, kdy to člověka prostě přestane bavit. A stejně jako dokáže jeden špatný programátor demotivovat celý tým, dokáže to i jeden člověk, kterého to přestalo bavit. S tím se bohužel asi nedá nic dělat, ani se proti tomu nijak bránit. Je tedy hlavně nutné s tím počítat - vězte, že ten moment přijde, ujistěte se, že i ostatní to vědí a dohodněte se, že až to nastane, budete to řešit. Jak, to nevím, to je jeden z problémů, který v současné době má náš projekt. Ale je nutné alespoň, aby všichni o problému věděli a je jakmile nastane, je nutné o něm začít mluvit - jedině pak se dá vyřešit.

Náš projekt

Mám-li zhodnotit náš projekt z pohledu 7 měsíců po zahájení a 2 měsíce před dokončením, řekl bych, že jsem si podle povětšinou naprosto špatných kritérií vybral celkem dobrý projekt.
Zadání je víceméně úměrné těm 9 měsícům, není na něm nic složitého, ale díky pěknému návrhu jsem se leccos naučil a není to tupá práce. Pěkný návrh mě motivuje k práci a projekt mě v celku baví. Je v jazyku PHP, což je můj oblíbenec. Zadavatel projektu nás platí, ne málo, ne moc, ale jak jsem psal - jde tu hlavně o pocit, že "z toho aspoň něco mám" - a ne "jen" až po 9 měsících podpis v indexu.
Pokud jde o náš tým, zdá se, že jsem dopadl ještě slušně: v pětičlenném týmu si se dvěma ze zbývajících čtyř celkem vyhovujeme.
S vedoucím našeho týmu si vyhovujeme, zdá se, vzájemně a téměř bez výhrad. Druhý mi sedí "většinou" - některé jeho zvyky a postupy mi pijí krev, ale jde většinou o věci nepříliš zásadní.
Nad prací třetího kolegy hlavou střídavě obdivně kývám a nevěřícně kroutím. Tenhle člověk s dobrými nápady je bohužel často až katastrofálně nedůsledný. Navíc je těžké s ním koordinovat práci, protože nedokáže příliš dobře komunikovat.
No a čtvrtý z týmu je bohužel chodící ukázka toho, že existují lidé, kteří pro projekt znamenají ne nulový, ale opravdu záporný pokrok. Nedá se říct, že by to dělal úmyslně - opravdu se snaží pomáhat a produkuje spoustu kódu. Bohužel ale mizerné kvality. Ve výsledku jsem jen já strávil opravami jeho kódu asi víc, než bych strávil jeho napsáním z nuly. Jedinou chybou toho člověka je, že při vybírání mezi rycholstí a kvalitou programování si zvolil rychlost. A že nepozná, když píše špatný kód. Kombinací usilovaného přemlouvání k lepší sebekontrole, trpělivého vysvětlování chyb a mnoha zlostných e-mailů se nám podařilo jej aspoň trochu usměrnit, přesto doufám, že je tohle poslední projekt, na kterém s ním spolupracuji. Je to zrádné především proto, že ten člověk to nedělá úmyslně - nicméně to nemění nic na faktu, že je velkou zátěží nejen pokud jde o čas spotřebovaný na opravy jeho chyb, ale hlavně pro motivaci.

Portál dosvetaprace.cz (23.08.2007 0:42, #95)

Portál dosvetaprace.cz je projekt webové aplikace, která má sloužit učitelům na středních školách jako učební pomůcka při výuce předmětu Úvod do světa práce. Jde o komerční projekt vycházející z nedostatku výukových materiálů k tomuto předmětu, který je poměrně mladý a navíc na středních školách povinně vyučovaný.

Já a čtyři mí spolužáci z matfyzu na projektu pracujeme v rámci povinného matfyzáckého předmětu Softwarový projekt. Projekt byl vypsán v březnu tohoto roku, termín odevzdání je někdy koncem roku (limit je 9 měsíců). Současná deadline ale není dána projektovou komisí MFF, ale začátkem školního roku - velká část aplikace proto musí být hotova už zanedlouho.

Projekt ještě zdaleka není u konce a je tedy ještě trochu brzy hodnotit užitečnost Softwarového projektu jakožto povinné součásti výuky, zatím ho ale vmímám (po počátečním odporu) převážně kladně. Je to můj první komerční projekt a první projekt takového rozsahu. Za těch pět měsíců jsme stihli udělat spoustu věcí špatně, ověřit si v praxi hromadu pouček o tom, co a jak nedělat, a zjistit, co všechno může takový projekt zkomplikovat. A ano, občas jsme taky přišli na nějaký dobrý nápad a dobrý nástroj, který nám zjednodušil práci.

Protože je to komerční projekt, získáváme kromě zkušeností i celkem slušně zaplaceno. Ale i když to bude znít falešně - ačkoliv jsou peníze dobrou odměnou za čas strávený nad projektem, v této chvíli si těch zkušeností cením víc.

Velká část těch praktických zkušeností, které jsem získal, je teoreticky podchycena ve dvou (trochu zapadlých) matfyzáckých přednáškách, Dokonalý kód a Softwarové inženýrství (materiály k první jsou dostupné na stránkách přednášejícího Davida Majdy, nějaké podklady k druhé přednášce, byť trochu chaotické, lze najít na stránkách Profinitu). Škoda, že oba předměty byly až v letním semestru, v době, kdy náš projekt už žil. Mohli jsme se pár chybám vyhnout.