Programování je vlastně skoro jako vaření

Už je tomu pár let, co jsem napsal poměrně zdařilý článek srovnávající platformy Windows a „Linux“. Už pár měsíců se mi hlavou honil způsob, jak podobným způsobem běžnému smrtelníkovi popsat programování popř. obecně vývoj software. Píši proto tento článek, který by měl snad každému tátovi, každé babičce a dokonce i kdejaké knihomolce, která o programování ví asi jako křováci v Africe o Terrym Pratchettovi, co to vlastně to programování je.

Úvodem: programování vs. vývoj software

Na úvod mi dovolte jedno malé rozseknutí. Asi nikoho nepřekvapí, že jak programování, tak vývoj software jsou činnosti, na jejiž konci jsou počítačové programy, popř. software. Rozdíl mezi programováním a vývojem software však přece jen nějaký je.

Vrátíme-li se do kuchyně, můžeme říci, že programování je něco jako vaření, zatímco vývoj software příprava večeře. Příprava večeře obvykle obnáší vše od nákupu surovin, jejich přípravy (např. omytí zeleniny, rozmrazení masa), přes samotné vaření, až po úklid kuchyně a následně servírování.

Velmi podobně, vývoj software je proces, který se sestává z mnoha podkroků, mezi které patří například volba vhodných technologií, vytvoření zázemí (spuštění vývojářských serverů, instalace vývojových prostředí), přes samotné programování až po nasazení do provozu, uživatelské testování a údržbu.

V tomto článku se budu zabývat pouze samotným programováním, poněvadž fakt, že je s tvorbou software nějaká práce navíc asi nikoho až zase tak moc nepřekvapí. Naopak, programování je něco, co trápí nočními můrami už i leckteré studenty středních škol.

Vařila myšička omáčičku …

Máme tedy nachystány suroviny a jdeme vařit. Vezměme si učebnicový příklad: nějaká, téměř libovolná, omáčka. Rajská, koprovka či jakákoliv jiná. A, z druhé strany, takový typický elektronický obchod, e-shop. Ono bohužel i toto srovnání není úplně fér, vzhledem k tomu, že uvařit – byť sebepoctivější – omáčku nezabere víc, než pár hodin, zatímco nad e-shopem programátor může strávit dobrých pár týdnů. Pro ilustraci nám to ale bude stačit.

Když vidím, jakej jsem programátor, tak se bojím jít k doktorovi do kuchyně.

Jak takové vaření obvykle vypadá? Zde je první důležitý moment, protože stejně tak, jako se každá omáčka dá udělat jednoduše, rychle a obyčejně, tak i počítačový program se dá zkonstruovat méně či více propracovaně. Je rozdíl, jestli vaříte omáčku jako rychlou večeři nebo ke svátečnímu obědu pro celou rodinu. A stejně tak, e-shop prodávající jeden produkt s minimem dodatečných funkcí může být určitě vytvořen daleko snáze než propracovaný interaktivní systém s obrovským počtem uživatelů.

Jíška a vývar

Pokud omáčku budete začínat jíškou, bude vhodné si nejdříve jíšku připravit. Pokud ji budete zalévat vývarem, bylo by vhodné si nejdříve „uvařit“ vývar. Je tedy vidět, že i ve vaření se často setkáme s tím, že pro uvaření jednoho pokrmu je třeba mít uvařený nějaký/é další. Obdobně, pro vytvoření e-shopu je vhodné si nejdříve naprogramovat (samostatný/é) modul(y) – například pro připojení k databázi, přihlašování uživatelů, propojení se skladem a podob.

Stejně tak, jako se vývar dá nahradit bujónem, dá se obvykle propracovaný samostatný programový modul nahradit něčím jednodušším. Pokud si však vývar opravdu uvaříme, můžeme si část zamrazit a použít někdy příště. V oblasti vývoje software toto mívá mnohem větší význam – software se totiž nedělí ani nemrazí, ale prostě kopíruje. Takže „vývar“, který programátor jednou „uvaří“ může používat prakticky donekonečna.

Proto je víc, než jasné, že každý programátor se snaží tyto znovupoužitelné programové suroviny vytvářet jak jen to jde. Ve velkém množství případů však tyto suroviny ani nevytváří sám, ale – prostě si je koupí (popř. stáhne, pokud jsou zdarma). Na tom vlastně také není nic překvapivého: Kdo by se dnes doma mlel se strouhankou? Nebo si doma vyráběl vlastní majonézu?

Eintopf? Nein, danke!

Mimochodem, dnešní programování se dělí na dva hlavní (znepřátelené) směry: funkcionální a procedurální. Podíváme-li se na to pohledem přípravy omáčky, tak funkcionální programování vypadá asi takto: Programátor si nejdříve velmi pečlivě přichystá vše potřebné pro přípravu omáčky. Tedy jíšku i vývar, obě důkladně ochutí tak, aby s nimi pak při samotné přípravě omáčky měl minimum práce a současně nehrozilo, že mu výslednou omáčku zkazí. K tomu pak už jen přidá něco na ochucení omáčky, velmi jednoduše to smíchá dohromady a má zaručeno, že omáčka bude velmi pravděpodobně poživatelná.

Oproti tomu omáčka vařena procedurálně vypadá jako takový jeden velký eintopf. Procedurální vaření totiž připomíná spíše přípravu kouzelného lektvaru. Procedurální přístup znamená provádění jednotlivých dílčích kroků postupně za sebou. V praxi tedy jeden hrnec, do kterého se postupně přisypávají jednotlivé ingredience. I vývar by se nějak prapodivně měl vařit v hrnci, ve kterém se zvesela převaluje právě usmažená jíška. Postupným přidáváním dalších surovin by na závěr vznikla požadovaná omáčka.

Je jasné, že takovýto přístup je v praxi naprosto nepoužitelný. Funkcionální programování se zde zdá mnohem použitelnější. Z různých důvodů se však neprogramuje ani funkcionálně (protože to by například znamenalo, že jíška by se musela uvařit v kompletně svém vlastním hrnci a pak se zbytečně přelít do hrnce na omáčku), ale oba tyto přístupy se kombinují.

Málo slaná, co?

Nedílnou součástí každého vaření je ochutnávání. (Poznámka: bavíme se o ochutnávání, ale u pokrmu samozřejmě záleží také na vůni, barvě, konzistenci, palčivosti, teplotě…) Dokážete si představit, že uvaříte omáčku a ani jednou jste ji neochutnali? Bohužel, programátoři, kteří něco naprogramují a za celou dobu si nezkontrolují, že udělali všechno naprosto správně, jsou víc než běžnou záležitostí.

Zde nám trošku nahrává funkcionální programování. Pokud smícháme ingredience, které jsme důkladně ochutnali a ověřili si tak, že opravdu chutnají, jak mají, výsledný pokrm nám nezkazí. Naopak, při čistě procedurálním vaření vlastně až do poslední chvíle nemáme něco, co by stálo za to ochutnávat („není ta jíška s vývarem a kořením málo slaná?“).

Zkrátka a dobře, ochutnávání je pro vaření klíčové – a stejně tak i pro programátory. Chybička (nebo obecně cokoliv, co nezvykle ovlivní chuť) se totiž může stát vždycky. Tři malé místo dvou velkých cibulí, nezvykle silný česnek, či obvyklé „ups, asi mi trošku ujela ruka“.

Pokud se nám zdá omáčka málo slaná, dosolíme ji. Pak ji, pochopitelně, přesolíme, takže ji musíme doředit. Pak ovšem musíme přidat další koření, protože by byla slabá. Zkrátka, při každém takovém ochutnání často zjistíme, že je s omáčkou něco špatně a je potřeba to spravit. Tomu se v programování říká testování a ladění. Problém s testováním a laděním, s věčným ochutnáváním a dochucováním, je však ten, že se může opakovat velmi dlouho a pořád to není ono. Ve výsledku nám tak může vzniknout nějaký nepoživatelný paskvil, který tak akorát „za stálého míchání lijeme do hajzlu“. Bohužel i programátor se často setkává s tím, že pořád není spokojen, pořád to není ono, a tak neustále upravuje a upravuje, až mu nakonec stejně nezbude nic jiného, než to celé smazat a začít nanovo.

A to ani neříkám, že když jídlu něco schází, dá se docela snadno určit co. Sůl, koření, zahustit. Ale programátor má dost často jen informaci „je to dobrý“ a „není to dobrý“. Teprve studiem toho, co tam všechno nasypal může vyhodnotit, co asi udělal špatně.

Supermáma

Při programování se občas setkáme i s dalšími pojmy, které najdete i v kuchyni. Například synchronní a asynchronní programování. Pokud byste vařili synchronně, a věřte mi, že to tak občas určitě děláte, znamená to, že než se vám dokončí určitá část vaření, do které není potřeba zasahovat, tak stojíte u sporáku a čekáte. Až se voda ohřeje, až se máslo rozpustí, až to vychladne. Prostě stojíte a čekáte.

Oproti tomu, asynchronní programování znamená, že dáte vařit vodu, a jdete dělat něco jiného. Až bude voda uvařená, vrátíte se k ní. Logické, ne? No, bohužel, pro programátora je snažší si počkat. Už jen proto, že v momentě, kdy se voda dovaří, tak dost možná může být přerušen z nějaké činnosti, u které by neměl být rušen. Člověk při vaření na to myslí, ale – programátor za počítačem má poměrně omezené možnosti.

Spoustu legrace si také každý programátor užije při paralelním programování. Tedy, že v kuchyni není sám. Velmi často se totiž poštěstí, že se lidí po kuchyni potuluje více. A zkuste se ubránit situacím typu: „Cože, tys tu omáčku taky solil?“, „Ale já ten nůž potřebuju teď hned!“, nebo „Teď, teď jsem si tu solničku sem položil. Kdo mi ji vzal?“. Opět – v kuchyni docela humorné situace, avšak pro programátora noční můra. Omáčku osolí sotva špetičkou soli – a je přesolená. Nebo chce něco ukrojit a zjistí, že nůž na stole neexistuje. A hledejte chybu, kterou jste nezpůsobili vy.

Noční můra každého programátora? Kdyby Láďa Hruška začal programovat …

Obdobně, jako v kuchyni, i většina programátorů občas používá tzv. „hacky“. Tedy něco, co je naprosto nepřípustné, ale – ono mu to prostě extrémně zjednoduší práci. Mezi takové „hacky“ patří například zahušťování omáčky moukou namísto jíšky, nahrazení vývaru bujónem či tomatové omáčky kečupem. Ano, přesně tak, takový Jirka Babica. (Opravdu si nedokážu představit, jak by vypadal jako programátor.) Jsou to prostě věci, kterým se každý slušný programátor snaží vyhýbat jak jen to jde. Bohužel, ne vždy to jde (nebo je to vyloženě nutné).

Dobrou chuť!

Pomalu se blížíme ke konci, omáčka je téměř hotova, poslední přisolení, zamíchání a je hotovo. Můžeme servírovat, chutná skvěle. Náš e-shop je hotov a může být spuštěn. Někdo nám ale hned první den píše, že se do něj nedá přihlásit. A další. A další. Jak je to možné? Jednoduše – i ta omáčka, která nám chutnala (nebo to s ní naše chuťové pohárky prostě vzdaly a začaly našemu mozku tvrdit, že je opravdu skvělá), nemusí chutnat všem. To se tak bohužel stává. U programátora to může být tím, že po všem tom ladění a testování je prostě jen něco úplně obyčejně přehlédl. A nebo – prostě je tam něco, mezi židlí a klávesnicí, co způsobilo, že to funguje jen jemu a nikomu jinému.

Věřím, že mé srovnání programování s vařením někomu nemusí být po chuti. Je fakt, že by se dalo najít hned několik disciplín, kde se to k sobě hodí asi jak vegan a řízek. Nicméně, stále platí, že i programování, obdobně jako vaření, je prostě věda. Opravdu velká věda. Avšak pro programátora je i docela obyčejná omáčka práce na dlouhé týdny či měsíce. Tak tedy dobrou chuť všem programátorům!

Generátor vánočních koled

Vánoce. Ten skvělý čas, kdy se všichni radují, veselí, slaví – a jsou šťastní. Co jiného jim také zbývá?

A o tom to je. Vánoce jsou vlastně taková docela kýčovitá záležitost. Nezdá se vám to? Všechny ty výzdoby, pohádky, dárky, písničky, atmosféra, filmy.

Podívejte se třeba do televizního programu: pohádky, rodinné komedie, romantické filmy. Mrazík, Sám doma, Láska nebeská? Ano, to je jen malý výčet toho, čím se vás televizní stanice snaží naladit na vánoční vlnu. To vše k Vánoční atmosféře zcela jistě patří. Ale – co mě už pár let překvapuje, šokuje a já nevím, co všechno, tak jsou rádia.

Asi to přišlo ze západu. Nebo se to zrodilo někde v hlavě některého z tuzemských hudebních producentů: máme tu letní hity, tak proč nenapsat nějaký vánoční? Ten nápad se docela ujal, a tak každoročně vznikne pár nových zaručených vánočních hitů. Pokud jste o nějakém hudebním interpretovi dlouho neslyšeli (nebo se mu naopak v poslední době daří a rád by své popularitě trochu napomohl), je docela pravděpodobné, že před Vánoci o něm určitě uslyšíte. V lepším případě o hudebním interpretovi. V tom horším se jedná o herce, moderátora či nedejbože politika.

Vzhledem k tomu, že rádia moc neposlouchám, tak informace ohledně nového vánočního hitu Vánoc 201x ke mě doputují zpravidla pouze pomocí sociálních sítí. Co si tak vzpomínám, z posledních let tu máme Vánoční čas od skupiny Nightwork, Štědrý večer nastal od XindlaX či dokonce parádní funky hit Santa Claus od bláznivé kombinace Gunčíková, Jandová, Suchánek a Genzer. Dokonce koukám, že i redakce rádia Evropy 2 si opět pro letošní Vánoce nazpívala svůj song. Chválu nebo naopak kritiku těch uměleckých děl ponechám odborníkům a jen dodám, že Hudební masakry by ve svých análech jistě vyhrabaly spousty daleko horších exemplářů.

A přesně v ten moment mě to napadlo. O čem to k čertu vlastně chtějí pořád zpívat? Ježíšek, cukroví, dárky, radost, purpura. Stromeček. Dobře, ještě kapr. A cukroví. Tak moment, to už tu bylo? Dobře, nejsem sice textař, ale – nemohu se zbavit pocitu, že takovéto „koledy“ jsou prostě pořád o tom samém.

A v ten moment mě napadlo, jestli by nešla práce takového textaře nahradit počítačovým programem. Tak jsem to zkusil a – no, posuďte sami:

Generátor vánočních koled (online)

Pokud by vás zajímalo, jak takový elektronický textař funguje, prostě a jednoduše za sebe skládá víceméně náhodné verše. Samozřejmě, nic není je tak. Verše se musí rýmovat a také mít nějaký rytmus (resp. alespoň stejný počet slabik v každém verši).

Zajímavější je, jak se generují jednotlivé verše. Základní idea spočívá v tom, že každý verš popisuje nějakou činnost. Tuto činnost může provádět určitá skupina osob/věcí. Například děti mohou psát dopis Ježíškovi, rodiče pít punč a zvířátka ležet u krbu. Verš se tedy sestavuje tak, že se vybere některá z těchto aktivit a k ní se pak už jen vybere některý z aktérů. V případě, že je tato kombinace moc krátká, tak se tam doplní pár slov typu: „zase po roce“ nebo „dnes celý den“.

náhled
Koleda s číslem 80147628.

Trochu odborněji řečeno, můžeme tak mluvit o (probabilistické) formální gramatice typu 2, tedy bezkontextové. Pochopitelně, s určitými restrikcemi, takže to čistě bezkontextová gramatika není. Nicméně, celá idea generování veršů je na principu gramatik od počátku založena.

Kdo by měl zájem, celou aplikaci mám nahránu na openshiftu, takže si ji (když mi dáte klíč) můžete naklonovat, nebo si ji proklikat přímo v testovací produkci pod touto adresou: xmasgen-martlins.rhcloud.com na clusteru někde v Kalifornii. Tímto bych chtěl také poděkovat studentskému spolku UP Crowd za hosting v Česku a koncekonců také za propagaci.

Tak vám přeji hodně zábavy při generování a hlavně zpívání (byť nepředpokládám, že by některé z koled snad byly zpívatelné) vygenerovaných koled. A samozřejmě Veselé Vánoce a štastný nový 2017 rok k tomu!

Prokletí informatika

Právě jsem se vrátil ze zkoušky. Dopadla – jak to tak u mě většinou bývá – víc než úspěšně. Místo bujarých oslav si však (opět) říkám, jestli je to vlastně v pořádku.

 

Než se však pustím do vyprávění toho, co se vlastně stalo a proč už v sobě nemám třetího panáka, dovolte mi jednu důležitou poznámku na úvod.

V názvu článku stojí „informatika“. Lidé, kteří mě znají, tak ví, že já mé spolužáky či kolegy rozděluji na ty, kteří jsou „informatik“ a na ty, kteří jsou „student informatiky“ (popř. „absolvent informatiky“). Tento na první pohled nenápadný rozdíl je však prakticky fatální.

Většina lidí si totiž myslí, že když studují (nebo již dostudovali) informatiku, stali se z nich informatici. To je však velký omyl. Vezměte si sebe – kolik z vašich spolužáků ze střední, kteří školu skutečně vystudovali, to skutečně umí (a případně dělá)? Když se zamyslím já, tak z mých spolužáků ze střední, elektrotechnické průmyslovky, se elektrotechnice věnuje možná tak polovina. Zbytek třídy, ač na to mají papír, bych jako elektrotechniky rozhodně nikdy nenazval.

A s informatiky je to podobné. Znám spoustu lidí (netvrdím, že přímo mých spolužáků; vzhledem k tomu, že nás aktuálně studuje 6, tak bych prakticky musel být konkrétní, což bych nerad), kteří studují informatiku stejně jako já a přitom informatiky nejsou. Ano, určitým způsobem třeba umí programovat, zadaný úkol nějak vyřeší, ale když se jich zeptáte, proč to řešili tak a tak, nebo jestli je třeba jakože nenapadlo použít to, co nás učili dva roky zpátky, tak neví. Neví, neznají, nenapadlo je to, už si to nepamatují.

Tito lidé prostě o informatice, no, dobře, nechci říkat, že neví nic, ale – z jejich práce je patrné, že prostě nejsou informatikové. Chodí do školy, učí se na zápočty a zkoušky, ale je vidět, že tomu, co se učí důkladně nerozumí a hlavně – neumí to použít v praxi. Takový člověk informatiku pouze studuje, nic víc. Jo – a samozřejmě na ni nadává. Že se musí učit teoretické nesmysly a zbytečnosti, které mu budou v praxi k ničemu.

Tak přesně o těchto lidech tento článek není. Tento článek popisuje smýšlení někoho, kdo na přednáškách přednášejícího neposlouchá, kdo na přednáškách slova přednášejícího hltá po kilech. Mluvím tu o člověku, pro kterého zabývat se teoretickou informatikou není odporná zbytečnost a ztráta času, ale něco zajímavého. Něco natolik zajímavého, že se nebojí tomu obětovat část svého volného času.

Takto nějak se vidím já. Přiznávám, že tato představa je poněkud idealizovaná, ale to koneckonců nevadí – ani já nejsem dokonalý informatik. Dobře, ale říkáte si, co je na tom tedy tak špatné?

No, první věc, která nejspíš napadne každého, je těžká integrace do praxe. Člověk zvyklý na přednášky a hluboké dumání nad rozličnými teoretickými problémy zpravidla velmi těžce nese fakt, že najednou nejhlubší problém, který ho čeká, je zjistit, proč zákazníkovi aplikace spadla.

Ale o tom jsem nechtěl mluvit. Toto totiž zjevně trápí kdejakého studenta či absolventa vysoké školy. To, proč píši tento článek pramení přímo z podstaty informatiky, resp. jejich aplikovanějších podob.

Jedním z úkolů informatiky totiž je něco, čemu já souhrnně říkám „teorie programování“. To je, zjednodušeně řečeno, sada informatických disciplín, které nám ukazují, jak by se mělo programovat. Pochopitelně, znalost teorie programování je jeden ze základních předpokladů každého informatika. Každý informatik totiž pak nejen, že něco nějak naprogramuje, ale je si vědom toho, co a jak vyřešil, že jeho řešení je nejlepší možné a pokud není, tak dokáže přesně popsat proč.

Pořád si říkáte, co je na tom špatné? Ukážu názorně: Informatik je postaven před úkol vytvořit jednoduchou databázovou aplikaci. Něco jako telefonní seznam nebo tak. Nu, aplikaci si kompletně navrhne, vytvoří si malý databázový framework, sadu GUI komponent a důmyslný systém jednotkových testů. Na závěr vše spojí dohromady a po dvou týdnech má hotovou perfektní aplikaci.

Když před tentýž úkol postavíte neinformatika, založí si projekt, vloží třídu, otevře hlavní metodu, do ní nabuší příšerné množství kódu, aplikaci spustí, prokliká a má hotovo. Za jedno odpoledne. I s pauzou na kafe. Hodinovou.

A na to, že to celé funguje jenom nějakým zázrakem a že se každý bojí v té aplikaci cokoliv změnit, protože je mu jasné, že by okamžitě odkráčela do křemíkového nebe (a ještě cestou sestřelila nějaké dopravní letadlo, prostě jen tak), se nikdo neptá. Obzvlášť v komerčním prostředí, kde každá minuta je drahá. A rozdíl třinácti a půl dne je v tomto případě značný.

Tuto situaci si asi dokážete představit. Ale pointou tohoto příběhu dvou programátorů není příšerná práce neinformatika, ale – naopak precizní práce informatika. Tady je totiž krásně vidět, že informatikovi naprosto vůbec nezáleží na tom, na jak rozsáhlém projektu pracuje, on je precizní vždy.

I když si jen píše v excelu vzoreček pro výpočet počtu sazenic na záhon, naprosto automaticky dokumentuje a testuje. A výpočet si dělí na dílčí kroky. A tak podobně. Prostě dělá vše, co je mu jakožto informatikovi vlastní.

A v tom je ten problém. Informatik je totiž takový detailista, puntičkář, chcete-li. Nedokáže se od toho odprostit. Ve všem musí mít dokonalý systém. A pokud ne, celé to zahodí a raděj to udělá celé znovu. Co naplat, že ztratí dva dny práce. Nedokázal by se smířit s tím, že vyprodukoval něco, co není podle jeho představ. Co se mu na 100% nelíbí. Co není ideální.

Tohle všechno stojí čas. To věčné zdokonalování, vylepšování, uhlazování. A vždycky se objeví nějaký další problém. Takže kus práce zahodit a zase znovu.

Zprvu je to skvělé, člověk má radost, jak se jeho dílo posouvá stále více a více kupředu. K dokonalosti. Ale časem začne sledovat, jak vždy, když má cíl na dosah, tak mu o kousek uskočí. A to začíná být frustrující. A únavné. A celé to skončí zpravidla tím, že to prostě vzdá a je nucen se spokojit s výsledkem, který rozhodně není dokonalý. Pořád je 1000x dokonalejší než to, co by vyplodil kdejaký neinformatik, ale – není to ono.

Takže zpravidla člověk, i když projekt zdárně dokončí, je totálně vyčerpán – jak fyzicky, po nekonečných dnech a nocích za počítačem, tak psychicky – žít s tím, že po tak usilovné práci a takovém množství času projekt stejně nedotáhl do konce. Ke kýžené dokonalosti.

Jedinou útěchou tak pro něj může být, když se zjeví problém. Neinformatikovo veledílo totiž v takovém případě havaruje a z neinformatika se stává hromádka neštěstí, zatímco informatik na to byl připraven a problém tak vyřeší velmi snadno. Toť teorie. V praxi se – bohužel – vždycky se objeví něco, s čím ani sebelepší informatik nepočítal a hromádka neštěstí se stává z něj. Podařilo se totiž najít (další) důkaz toho, že jeho dílo skutečně není dokonalé.

Takže zatímco neinformatikové si žijí ten svůj život smířeni s tím, že hold občas budou muset řešit nějaký ten problém, život informatika je jeden velký problém. A to je problém. Prokletí.

 

Koho by zajímalo, jak (nedokonale dokonale) vypadá jednoduchý překladač programovacího jazyka po dvou měsících informatické práce, mkrněte na github. Už je oficiálně odevzdán, takže jej, myslím, můžu veřejně uveřejnit.

 

Existuje 10 typů lidí …

Znáte ten starý známý ajťácký vtip? Myslím tento:

Existuje 10 typů lidí: ti, kteří rozumí binární soustavě a ti, kteří nerozumí.

A znáte také jeho upravenou variantu?

Existuje 10 typů lidí: ti, kteří rozumí trojkové soustavě, ti, kteří nerozumí a ti, kteří si mysleli, že toto je vtip o dvojkové soustavě.

Když se nad tím zamyslíte, jistě vás napadne, že tímto zdaleka nekončíme. Takovýchto vtipů může být vlastně docela dost. A to, přesně řečeno, nekonečně mnoho.

To je docela hodně, já vím. Ono i přečíst je všechny by nějaký ten čas zabralo. Nicméně, připravil jsem krátký seznam těch prvních:

Jen tyto dva

Prvních 5

Jak se píše v patičce stránky, počet vtipů, které chcete zobrazit, je dán parametrem stránky. Takže si ho můžete klidně změnit na téměř jakýkoliv (dobře, ve skutečnosti až do symbolických 64).

Vzorce, rovnice a výrazy přes internet? Pomocí mého Editoru rovnic Online!

Také už se vám někdy stalo, že po vás někdo chtěl, aby jste mu něco vysvětlili přes ICQ/facebook chat? Nějaký příklad, nebo tak něco?

Uplně vidím, jak mu tam píšete „a1 na2 + a2 na 2 / (a1 – a2) na2“, pak si uvědomíte chybu a doplníte „to a1 na2 + a2 na 2 mělo být taky v závorce“. Takhle s ním komunikujete pár desítek minut a hlava se vám div nezavaří při transformování z chatu do matematického zápisu a natož, aby jste uvažoval, co s ním a jak jej upravovat či počítat.






Tomu je nyní konec! (Fuj, zní to jak Horst Fuchs z Teleshoppingu, ale nemohu si pomoct ;-)).  Nyní přichází edrovonl, tedy Editor rovnic online, ve kterém si vcelku pohodlnně to, co jste předtím svému kolegovi posílali ručně přepíšete do speciálního jazyka (který není ninak těžký – velmi se podobá přirozenému jazyku) a vašemu kolegovi pouze pošlete odkaz na vámi zapsaný výraz/rovnici.






Jak snadné!

Tohle umí už jen Wolfram Alpha.

Nemusíte se bát, že by na vás byl edrovonl nedostačující. Je dimenzován pro potřeby jak těch nejjednodušších výrazů a rovnic (tak dobře, „měla babka čtyři jabka a dědoušek jen dvě“ edrovonl neumí :-)) tak až na úrověn základů vysokoškolské matematiky (operátory jako suma, limita, integrál, produkt, a podob.).

No a mě nezbývá nic jiného než vyvěsit odkaz na jeho spuštění:

 

Editor rovnic Online ZDE

Nejneužitečnější aplikace na světě

Na internetu se nachází spousty videí s takzvanými „naprosto zbytečnými“, „nejzbytečnějšími“, „nejneužitečnějšími“ či doslovně „nejméně použitelnými“ věcmi, jako je třeba tato:

Všechny tyto předměty mají stejnou funkci. Každý obsahuje nějaký vypínač, po jehož zapnutí se zařízení uvede do chodu a začne konat svou běžnou činnost. Jenže tou není nic jiného, než co nejrychleji onen vypínač znovu vypnout.

Když jsem to viděl poprvé, začal jsem s úžasem slintat, že takto geniální vynález musím mít. Ale nebyl čas, materiál, kapitál, podmínky a ani nějaká velká motivace – k čemu vám taky ta nejneužitečnější věc na světě taky bude, když vlastně nemá žádné užití, že?

Časem jsem však na tento magický předmět narazil znovu a zrovna jsem měl alespoň ten čas a hlavou mi problesklo: „Vždyť to půjde realizovat i softwarově!“.  A během pár vteřin jsem si zakládal html soubor a začal vzpomínat na html, css a jQerry (které jsem vlastně nikdy pořádně neuměl).

Hrál jsem si s tím asi 2 dny a tady je výsledek:

Nejneužitečnější aplikace online

A nebo v anglickém provedení:

The most unuselless app online

Moje nová hra! Bludišťovka Anny’s Lab

Když jsem se letos (rok 2012) někdy koncem června vrhl na C++ s tím, že se jej přes prázdniny naučím, ať toho nemám poté v zimním semestru moc, opět jsem plánoval jaký to větší projekt si v něm napíši. Původně jsem si chtěl reimplementovat knihovnu clmg (Common Lisp Micro Graphics) sloužící k jednoduché grafice na základě objektové struktury, kterou jsem používali v Předmětu Paradigmata Programování 2.

Logo Anny's Lab
Logo Anny’s Lab

Ale přecházet z okenního rozhraní do klasického textového terminálu není u grafické knihovny úplně to nejideálnější a tak mi z clmg zůstala jen třída Point. Poté jsem si k ní začal dopisovat další tři třídy a bludišťovka se pomalu začala rýsovat.

Pod původním názvem Labyrinth tak začala vznikat obyčejná konzolová bludišťovka pro večery na chatě, kde nemám internet, nebo na přednášky, kde internet obvykle mám, ale zase mi většinou nestačí baterie notebooku na nějaké náročnější grafické hry.

Postupem času mi název Labyrinth přišel poněkud nevhodný a obyčejný (i když se zpětně zamyslím nad názvy Drag race a Předměstí Simulátor, nebylo by to nic neobvyklého). Vzhledem k tomu, že postavička, která se v labyrintu pohybuje je reprezentována zavináčem, vznikl návrh na zakomponování nějakého jména začínajícího na ‚A‘ do názvu programu. Když jsem hledal vhodný  znak, kterým se budou vykreslovat zdi, mi ze spousty znaků, které jsem zkoušel, padlo do oka velké písmeno W, které až náramně připomíná nějakou rostlinu nebo keřík.

Naštve
Naštve

A bylo jasno.  Mí skalní fanoušci navíc totiž ví, že do každého svého programu zakomponovávám nějakou osobu ženského pohlaví z mého okolí. A není proto divu, že předmětem kampaně Anny’s Lab se stala bioložka Anny pracující ve své laboratoři, které se poněkud přemnožil zmutovaný a geneticky upravený jinak úplně obyčejný trávník, který podobně jako v pohádce o Šípkové Růžence zaroste celým areálem (a vytvoří tak labyrint, kterým se musí Anny dostat ven). Od té doby jsem Anny’s Lab nenazýval jinak, než „Anča a Lenča“.

Kampaň je však jen jedna z mála funkcí, kterou Anny’s Lab nabízí. Celá hra je vlastně založená na tom, že se zvolí tzv. číslo labyrintu, podle kterého je poté labyrint náhodně vygenerován. Můžete tak hrát téměř nekonečný počet různých náhodných a pseudonáhodných labyrintů, různých velikostí a uspořádání.

Jednoduchý labyrint
Labyrint s jednoduchou strukturou

Vzhledem k tomu, že hra byla komplet vyvíjena na platformě GNU/Linux, je linuxu přímo šita na míru. Naopak na Windows s ní byly nemalé komplikace. Bohužel právě proto si nebudete moct pořádně užít hru Anny’s s použitím knihovny ncurses, kdy se hra vůbec neseká, každou klávesu nemusíte potvrzovat Enterem a dokonce se setkáte i se skromným barevným provedením.

Program používá starou knihovnu z MS DOS, kterou však na Windows za boha neseženete, zatímco na Linuxu ji nainstalujete jedním příkazem.

Střeva programu

Program je sice oficiálně psán v jazyce C++, já osbně bych spíš použil označení C/C++. Když jsem totiž chtěl načítat stisknuté klávesy bez potvrzování Enterem, vygooglil jsem funkci getch() z knihovny ncurses. Jenže tato knihovna byla určená pro jazyk C a nikoliv C++, takže většina vstupně-výstupních operací je realizována funkcemi jako printw a getch, držel jsem se standartu a kde nebyla použita knihovna ncurses, používal jsem funkce z knihovny cstdio – printf, getchar  a podob.

Čistého času jsem na Anny’s Lab pracoval něco kolem dvou a půl měsíce, kde z toho jsem ale fyzicky pracoval v průměru tak hodinu až dvě denně (to víte, prázdniny). Asi vás nepřekvapí, že nejvíce času padlo na jádro celé aplikace – metoda třídy Map na generování labyrintu.  Chtěl jsem být profesionální a najít si nějaký slušný algoritmus na generování. Tato diplomová práce věnující se přesně této problematice  mě však pouze přesvědčila, že opravdu nejlepším řešením bude úplně obyčejný hloubkově rekurzivní algoritmus typu „horník“.

První hra
První dohraná hra (17. srpna), můžete vidět tuny ladících výpisů

Nicméně pořád jsem je v reálném čase nedostal na Labyrint větší než 800×800. A bylo mi naprosto jasné proč. Ta metoda, která se starala o průchod jedním uzlem je sice na pochopení velmi jednoduchá, ale implementačně poněkud složitější. Neustálé kopírování konstantních parametrů a vytváření stále nových proměnných, jako iterační proměnná i na začátku každého volání zkrátka zbytečně žerou obrovské množství času.

Začal jsem tedy vzpomínat na cvičení z algoritmiky, jak přepsat hloubkovou rekurzi. Nejdřív jsem si ji přepsal použitím fronty na průchod do šířky, dokázal jsem generovat labyrint až do velikosti asi 12000×12000, nicméně vypadal jak hvězdice se středem ve startu. Po několika dnech intenzivního algoritmování jsem na to přišel.

Na zásobník si bude ukládat vždy čtveřici uzlů, do kterých se vydat (v pospřeházeném pořadí), také uzel, ze kterého se do tohoto „aktuálního“  došlo a ukazatel (index i), kterým z těch směrů se má nyní vydat. Pokud došel do validního uzlu, vytvořil si posloupnost s ním sousedících, spolu s ní na zásobník uložil bod, ze kterého tam došel, a index prvního z nich, načeš se do něj hned vydá. Pokud validní uzel nenašel, šel na další v pořadí (zvýšil index aktuálního uzlu o 1) a pokud další takový nebyl (byl poslední), odebere tuto celou skupinu ze zásobníku a jde o úroveň výš.

Toto řešení je taktéž celkem elegantní (obzvlášť, když je v C++ zásobník implementován ve standartní knihovně), a především velmi efektivní. Paměť mi většinu dojde, až když se snažím generovat labyrint větší než 14000×14000.

Až nebudu mít týden co dělat, nakoupím energiťáky, nachystám si rozvoz pizzy na rychlou volbu, vygeneruju si labyrint 10000×10000 a budu hrát…

Zbytek už byl celkem hračka. Až na pár drobností, jako třeba metoda, která k uzlu vrátila některý náhodný sousední uzel tak, aby ležel na mapě. Nejdřív jsem se snažil testovat, jestli není moc blízko okraji mapy, ale kraje mapy jsou 4 a navíc se můžou kombinovat (rohy), takže po asi 20 řádkách testování a ifování, jsem skončil tím, že jsem náhodně vygeneroval některý z okolích bodů (na to stačily 2 řádky) a to opakoval, dokud se tento náhodný uzel nenacházel v mapě.

Docela mě překvapilo i parsování argumentů z příkazové řádky. Když jsem si uvědomil, jako všelijaké kombinace chybných stavů můžou nastat, sáhl jsem až na dno kapsy a vytáhl výjimky a díky nim se kód rozrostl o pouhých 240 řádků.

A úplně zabilo, když jsem vlastně poprvé tvořil program rozdělený do více souborů (což jsem poněkud nešikovně dělal úplně nakonec), a vůbec to nechtělo fungovat. Nedošlo mi, že se soubory (a tedy i bloky funkcí celého programu) na sobě sice závisí, ale víceméně řetězovitě a ne každý na všech ostatních. Takže soubor s deklaracemi maker je naprosto nezávislý a tak jde zkompilovat rovnou. Na něm závisí soubor s deklaracemi všech funkcí, na něm pak definice pomocných funkcí, díky ní pak půjdou zkompilovat třídy Point a DrawabePoint, … až přes definice hlavních, „jaderních“ funkcí (a z nich ta úplně nejhlavnější – Hlavní Menu) až po samotnou funkci main.

Pak už stačilo jen napsat Makefile (a dva dny řešit, proč to nelinkuje knihovnu ncurses, ikdyž ji jistojistě inkluduji), zabalit, zkompilovat i na Windows (i to byla celkem estráda) no a napsat to, co si nyní čtete.

Ke stažení

Ke stažení dodávám jak zkompilované verze pro MS Windows, tak i balíčky zdrojových kódů pro obě platformy.

Anny’s Lab Verze pro Windows 32bit (.exe)

Anny’s Lab Verze pro Windows 64bit (.exe)

Kdo má koule na labyrint 5000x5000?
Kdo má koule na labyrint 5000×5000?

Anny’s Lab je totiž distribuován pod licencí GNU/GPL a je Open Source, tedy je volně ke stažení včetně zdrojových kódů.

Zdrojové kódy Pro Windows (Přibalen soubor pro Microsoft (c) Visual Studio)

Zdrojové kódy Pro Linux (Přibalen Makefile)

Ty předkládám především pro uživatele operačního systému GNU/Linux – v programu je přibalen také Makefile a tak si jej prostě zkompilujete pomocí programu make.

Pokud nemáte nainstalovanou knihovnu ncurses, musíte programu make říct, že Anny’s Lab funkce z ncurses nemá používat a to:

Nebo zakomentováním řádku

v souboru declarations.cpp. Více o používání knihovny v souboru COMPILATION a v hlavičkových komentářích souborů declarations.cpp a main.cpp.

 

 

Paradigmata Programování 1, neboli ‚Scheme‘

Po příchodu na vysokou (tím myslím Univerzitu Palackého v Olomouci) kde, jak asi většina z vás tuší, studuji Aplikovanou informatiku. Jeden z předmětů, který se tam vyučuje, Paradigmata Programování začal asi tak nějak: „Kolegové mi říkali, že vás mám motivovat, tak jsem si tady připravl menší graf.“, řekl pan Docent Vychodil a na plátnech (tehdá ještě fungovaly oba projektory) se objevil Koláčový graf. Dle něj 75% loňkých studentů nedostalo zápočet a z těch 25%, co ho dostali zkoušku stejně udělala jen slabá polovina.

Když jsme po dvou a půl hodinách z přednášky odcházeli opravdu asi málokdo by si myslel, že by se scénář, který onen graf symbolizoval mohl naplnit. Vlastně to bylo jenom takové zvláštně zaspané počítání: třeba 10+20+30+(4*5)-1/2 by se v jazyce Scheme, o který v Paradigmatech programování šlo, zapsalo například takto: (+ 10 20 30 (* 4 5) (- (/ 2))) .

Postupně však začalo přituhovat, už na druhé přednášce začaly tuhnout úsměvy a na třetí studenti jen zoufale hleděli na prezentace (pokud ne do svých notebooků či očních víček).

Scheme je oblíbený výukový programovací jazyk. Učí se v něm programovat například studenti Bostonské univerzity, MIT, Rice University, … a také Univerzity Palackého v Olomouci.
abclinuxu.cz

Někdy kolem 22. listopadu (po dokončení HeliSim), asi týden po uveřejnění zadání, jsem si řekl, že se vrhnu ná zápočtový domácí úkol. Zmlsán kolegy, kteří si nevěděli rady ani s 5 řádkovými úkoly, které dostávali od ostatních cvičících (a posílali mi je, protože já jsem tou dobou už aktivně programoval), jsem si naivně myslel, že to také budu mít za víkend hotové.

Po dvaceti dnech, noc před termínem, jsem odesílal soubor zdrojového kódu o délce 289 řádků. Vzhledem k tomu, že se mi zrovna dvakrát nevyvedla první zápočtová písemka, musel jsem to nahnat na právě tomto domácím úkolu. Z možných 20 bodů jsem však získal pouze 13.5 bodu, neboť poslední 3 ůkoly, ty nejvíc bodované a ty, nad kterými jsem strávil asi 60% času jsem měl stejně špatně.

Ukázka programovacího jazyka Scheme
I přes mnoho komentářů je kód na hranici přehlednosti

Druhou zápočtovou písemku jsem napsal neuvěřitelně dobře, takže jsem ani nepotřeboval na opravnou – z 60 bodů jsem získal 40.5, přičemž na splnění zápočtu bylo bodů potřeba 40. Mezitím nám však řekli, že všechny zápočtové písemky, které jsme doposud psali byly proti písemné časti zkoušky med a tak jsem i já si začal říkat, že když to nedám, tak to nebude taková katastrofa.

Bohužel tak trochu nešikovně jsem si zapsal dvě nejtěžší zkoušky na 2 dny po sobě. Když jsem dal tu první, Úvod do informatiky, nemohl jsem to alespoň skromně neoslavit. Něco jsme popili, ale pak už jsem upaloval spát abych byl na Paradigmata fit. Kupodivu jsem nezaspal, a tak jsem běžel na test.

Ten, jak se poté prokázalo, jsem napsal na 96% ze 100% možných (nedivte se, na vysoké můžete bez problémů získat i 130% a to dokonce bez úplatků) a tak jsem šel (spolu s dalšími dvěma kolegy, kteří také měli víc než 71%) na kobereček k samotnému panu Docentu Vychodilovi. Ten se nás každého na něco zeptal, mě konkrétně na koerci (přetypování), a odcházel jsem s A v indexu.

Od toho okamžiku pořád někoho doučuji, učím a poučuji. Úplně nejdřív ale vznikl tento skromný manuál-příručka k jazyku Scheme, a ostatně proto vůbec píši tento článek. Mezi mými kolegy se stal velmi oblíbený, a při přípravě na zkoušky poměrně praktický.

Ale kam se hrabe nějaký student, který má A ze zkoušky na někoho, kdo má před jménem 2 tituly, a ještě jeden za ním? Tím chtěl básník říci: „Choďte na přednášky a cvičení“, jinak máte přestup z UP na ÚP v brzké době jistý.

Takže ještě jednou:

Příručka, manuál a přehled Jazyka Scheme

HeliSim – proleťte se helikoptérou přímo v prohlížeči

Projekt s pracovním označením „Helča a Simča“ je dalším z řady mých velkých projektů. I když HeliSim nepatří mezi ty největší (Drag Race a Předměstí simulátor), i tak si zaslouží úctu, že jsem si v prvním semestru na vysoké ještě stále našel čas a ze zajímavého nápadu (který jsme měl v hlavě nějaký ten týden před začátkem vlastní realizace) realizoval něco takového.

Ten onen nápad spočíval ve využití toho, že při pohybu myší nad oknem prohlížeče je volána událost onMouseMove a v objektu event jsou uloženy souřadnice polohy kurzoru. Díky tomu nebyl problém při volání této události na tyto souřadnice přesunovat obrázek s helikoptérou (jak můžete vidět ve verzi 1, kterou dodám později).

No a aby toho nebylo málo, tak jsem ještě k tomu přidal, řekl bych snad spousty, dalších funkcí, takže ve výsledku je to celkem propracované dílo. Jak se můžete v nápovědě po spuštění (nebo vyvolané klávesou H) dozvědět, můžete si změnit jak letoun, tak i prostředí ve kterém létáte.

Začalo to jako simulátor letu helikoptérou, ale zvrho se to ve filosofii „Všechno lítá, co má peří“.

Ještě bych prozradil pár zajímavostí. Celé dílo jsem tvořil na den přesně 1 měsíc (21. října až 21. listopadu). Jen pár hodin po započetí tvorby mi byl zablokován účet na facebooku, a teprve teď si zakládám nový (dokázal jsme tedy celý měsíc nejen vydržet, ale i programovat! bez facebooku). Dokončen byl – jak jsem řekl 21. 11, a to přesně jednu minutu před půlnocí.

Velmi zajímavě vypadá také samotný zdrojový soubor. Ten má včetně reklamní paty rovných 7 řádků. 95% všeho, co samotný HeliSim dělá je totiž uloženo v externím skriptovém souboru, který, což se mi taky často nestává, zdá se býti docela i přehledný. A to i přes to, že má téměř 300 řádků (288). Třešničkou na dortu, no spíš myškou při tahání řepy převeliké je pak stylopis, který se stará o to hlavní – aby vše vypadalo, tak jak má, i když má v poměru ke skriptovému souboru téměř zanedbatelnou velikost (6 řádků).

Pro ty, kteří vydrželi číst až po sem tu mám vyzrazení dvou Easter Eggů. První naleznete, pokud budete létat v létě. Pod největším stromem je malá lavička. Když se na ni podíváte hodně z blízka, uvidíte na ní někoho sedět. Kdopak to asi je? Druhý je na oplátku v zimě, kde mezi hájkem z jehličnatých stromků a heliportem (blíž k heliportu) úplně dole můžete nalést čtvereček 2×2 pixely (který je oproti bílému sněhu mírně neobvykle tmavší) majíce tento význam.

Klikni pro spuštění HeliSim 10 alfa

Pozor! server není stavěný na takovéto aplikace a tato aplikace není stavěna na takovéto servery, takže přepínání vzhledů je velmi pomalé a zdlouhavé. Řešením je verze 11, na které se již pracuje.

Neodbytná je také reklama, se kterou prostě nešlo hnout.

O Programování

Programování. S tímto slovem se na tomto webu setkáte poměrně často. Je to proto, žejá jsem magor, když jsem si vzal něco do hlavy, nemohl jsem to dostat ven. Takže díky tomu relativně intenzivně programuji už víc než dva roky a výsledkem jsou mimo různé blbůstky především Drag Race a Předměstí simulátor.

Toť jen jeden z důvodů, proč vůbec vznikl tento článek. Ale abych se vrátil zpět k programování jako takovému, pak bych tedy na základě této zkutečnosti zkonstatoval, že programování je rozhodně činnost náročná. Je potřeba se na to plně soustředit, a když už pak programujete opravdu několik hodin, obzvláště nějaký ten zapeklitý algoritmus a ten vám pořád a pořád nechce fungovat, už ztrácíte nervy, už nevíte kde by ještě mohla být chyba, tak je nejlepší se přinutit se k tomu, aby jste to pro dnešek už vzdal. Nebo druhá možnost, které já říkám vyvolat přerušení.

To znamená, že toho prostě necháte. Buďto jen třeba na dvacet vteřin, kdy se podíváte třeba na facebook / twitter / … (proto často hovořím o tom, že mít facebook / twitter / … je pro programátora velmi významná věc), můžete něco popít, pojíst ne vykonat nějakou dlouho odkládanou domácí práci. Nebo, což jsem také docela často praktikoval, na takových 20 minut si třeba něco zahrát a nebo, jak jsem řekl, prostě jít spát a pokračovat další den.

Nějaký zdrojový kód
motivační obrázek - zdrojový kód

Toto takzvané přerušení vás přivede na jiné myšlenky a pak najednou přijdete, pročtete si ten zdroják a chybu najdete již při prvním pohledu, neboť jste ji před tím prostě přehlíželi. Nehledě také na ten fakt, že programování vás totálně psychicky vyčerpá, takže už vám to ke konci prostě nemyslí.

Programování prostě není pro každého. Kromě pevných nervů a silné vůle, aby člověk vůbec něco naprogramoval, na to musí mít hlavu. Jinak se to bude velmi složitě a zdlouhavě učit. Prostě musíte mít v hlavě představu, musíte mít vymyšleno, co od programu očekéváte, ba dokonce přesně celý algoritmus, který pak zhmotníte formou zdrojového kódu už když usedáte k počítači.

Být programátorem totiž neznamená sedět u počítače a datlit příkazy, ale přemýšlet a tok vašich myšlenek ťukat do počítače. A teprve potom nechat si od něj nechat ověřit, že byly vaše myšlenky správné, a že vámi vymyšlený algoritmus funguje jak má.

Jak říkám, můžete to zkusit a jestli vám to půjde, tak budete potom řešit stále zapekliťější a zapeklitější problematiky. A při troše štěstí se z vás třeba jednou stane uznávaný programátor.