Bez titulku

PEP8 a můj názor na něj

Dovolil jsem si napsat krátký seriál o Pythonu, kde jsem v prvním díle nedodržel kompletně PEP8. A to byl přesně důvod pro to, aby se rozjela smršť hádek. Některé komentáře byly trochu až drsné. Nesnažil jsem se s nikým hádat a další díly ještě přepsal, aby ukázky vyhovovaly PEP8. Nechci to však nechat být bez vyjádření.

Pokud PEP8 neznáte, možná bude dobré si ho v rychlosti proletět, aby bylo jasné, o čem je řeč. Je k nalezení na adrese http://www.python.org/dev/peps/pep-0008/.

PEP8 dobrý, ale…

Je velmi dobré se držet nějakého stylu, aby byl kód čitelný. A to není pouze jen tak. Na toto téma je velmi zajímavá přednáška Programming Style & Your Brain by Douglas Crockford, na kterou doporučuju se podívat (odpusťte mi, že odkazuju na přednášku, kde se používá JavaScript, když mluvím o Pythonu). Což je také důvod, proč si myslím, že je dobré, že Python něco takového má.

Jenže. Jenže podle mne to je až příliš konkrétní. Opravdu si myslím, že to je až příliš, protože spousta lidí to teď vidí jako něco, co se musí přesně do pontíku dodržovat. A když se to náhodou nedodrží v nějakém bodě, hned rozhořčeně píší do diskuze, jak je to špatné, když se to nedodržuje. Nebojí se pak ani říct, jak je to nečitelné či bijící do očí.

Aby mě náhodou někdo nepochopil špatně – konvece na názvy private či protected metod, pojmenování args a kwds, nemixování mezer a tabů, nepsat mezery navíc uvnitř příkazů, … vítám a vyžaduju. O tom žádná, to se musí. Bez těchto konvecí by v tom byl pěkný bordel.

Mě jde o něco jiného – o drobnosti. Například jak psát názvy nebo maximální šířka řádku.

Jak dodržuju PEP8

PEP8 se mi líbí a vyhovuje mi, takže PEP8 dodržuju až na pár drobností:

• U názvů metod a proměnných používám camelCase (první písmeno malé), 
• nebojím se použít (pokud to zlepší čitelnost) i 80. znak na řádce (klidně i pár dalších),
• a pokračující řádky dělím trochu jinak; místo:

  def long_function_name(
          var_one, var_two, var_three,
          var_four, var_five):
      # ...

  používám (pokud zahrnu i změnu v názvech):

  def longFunctionName(
      varOne, varTwo, varThree,
      varFour, varFive,
  ):
      # ...

A podle mého názoru to není prohřešek. Něco jiného by bylo, kdybych například mixoval tabulátory a mezery nebo před public metodu psal podtřžítko.

Co jsem se dozvěděl z komentářů

Na mé mírné úpravy jsem se dozvěděl velmi zajímavé názory!

Když jsem u názvů metod použil camelCase, dozvěděl jsem se, že z toho „docela bolí oči, že to není JavaScript“. Jestli používá hodně tříd, tak ho docela lituju.

Nebo jiná perlička: „Za camel case normálně sekám ruce. To proto, že rozlišovat identifikátory pouze na základě velikosti písmen je zaručená cesta do záhuby a zdroj zcela zbytečných chyb.“ Při psaní tříd v Pythonu dle PEP8 pozor na ruce!

Dokonce jsem se dozvěděl, že nedodržovat PEP8 je „základní chyba“. No nevím, za použití camelCase mi ještě interpret ruce neutrhl. Dokonce ani nezobrazil žádné varování. (Ani žádný jiný jazyk.) Asi to nebude tak horké, jak se tvrdí…

Myslím, že tohle málo stačí pro to, abych ukázal, jak směšné takové diskuze jsou.

Týmové konvence jsou důležitější

Mnohem důležitější, než dodržování PEP8, je dodržování domluvených konvencí v týmu. Jelikož pracuju v Seznamu, tak někdo nezapomněl do diskuze přispět s odkazem na Python klienta pro API Skliku (prostě nějaký Python kód ze Seznamu), aby ukázal, jak (ne)dodržujeme PEP8 (pro zasmání ostatním diskutujícím) a že vlastně já to nemám tak strašné. Jiný diskutující se toho chytl a smál se. Samozřejmě, jak jinak. Docela bych rád viděl jak oni dodržují PEP8 v jejich zaměstnáních.

U malých a hlavně neprofesionálních firem se to nedělá, u těch ostatních je však bežné, že se na začátku (ať už projektu nebo firmy) stanoví nějaký coding style a ten se dodržuje, aby byl kód jednotný. A je úplně jaký bude; důležité je, aby s ním souhlasili všichni zúčastnění.

Například (což je i důvod zmíněného posměchu) v Seznamu na konci tříd, metod, cyklů, … používáme komentáře #endclass, #enddef, #endfor, … Já osobně tyto komentáře (u svých věcí) nepoužívám a k čitelnosti mi to nepomáhá (ale ani neubírá). Tento coding style se tu však zavedl a používá se. Jsou tu i vývojáři, kterým to přijde přínosem. Takže v práci tyto komentáře píšu a nemám s tím žádný velký problém.

V komentářích jsem našel také toto: „(…) respektuji konvence jazyka/prostředí, ve kterém dělám. Opačný přístup znamená, že jsem tam vetřelcem.“ Já na to říkám: Dodržováním konvencí jazyka mohu být vetřelcem pro tým, který má zavedený jiný coding style.

Sečteno podtrženo

Jděte se bodnout s tím z čeho vás bolí oči a za co sekáte ruce.

Jelikož to ale stejně neuděláte, budu příště na servrech, jako je Zdroják, dodržovat PEP8, ať máme všichni klid. Ve svých projektech budu ale nadále dodržovat svůj coding style a v práci budu nadále psát #endarticle.

Tipy jak se zlepšit v angličtině

Minulý měsíc jsem byl v zahraničí naučit se mluvit dobře anglicky. Sice stále neumím anglicky plynule, jak by se mi líbilo, ale stejně jsem za krátkou dobu udělal výborný kus práce. A stačilo mi pár jednoduchých triků o které se chci s vámi podělit. (Pokud se chcete naučit jiný jazyk, místo angličtiny dosaďte jakýkoliv jiný jazyk. Téměř vždy to bude platit.)

Dříve jsem byl v angličtině špatný, protože jsem si myslel, že jsem špatný. Jeden měsíc v zahraničí toho moc nového nenaučí. Opravdu ne. Mě to ale dalo hodně. Zjistil jsem totiž, že jsem se předtím pouze bál angličtinu použít, protože jsem se bál, že udělám nějakou blbou chybu a někdo se mi bude za to smát.

Když jste však v zahraničí a kolem sebe máte pouze anglicky mluvicí lidé a potřebujete se nějak domluvit, prostě něco řeknete. A buď už vám budou rozumět a pomůžou a nebo se jednoduše na vás udiveně podívají a tím máte příležitost svůj problém říct znovu nebo trochu jinak. A tím udiveným pohledem se vám neposmívají ani vám nechtějí utrhnout hlavu.

Takže tip číslo jedna, jak se učit angličtinu: nebát se angličtinu použít.

Kdyby se náhodou ale někdo smál, tak se s ním jednoduše nebavte. Je to blbec.

Ve škole moc čechů nebylo, takže češtinu jsem zaslechl málokdy. Zato francouzky mluvících tam byli tři pr...desítky. Podobně na tom byli japonci. Bylo hezky vidět, jak se většinou tito studenti spolu nejvíce kamarádí a po škole si povídají svým jazykem. Tohle je velmi častá a velká chyba.

Na jazykový kurz do zahraničí jedu přece proto, abych byl donucen daný jazyk používat a naučil se ho co nejvíce. Přijet, vyhledat kdo umí jazyk, který taky umím, jsou podle mne vyhozené peníze. To si mohu rovnou najít levnější jazykovku doma, nemusím nikam jezdit a po škole můžu normálně mluvit mým rodným jazykem.

Tím tedy máme tip číslo dvě: vyhýbat se lidem, kteří umí můj jazyk. Nebo se donutit používat pouze angličtinu, což nemusí být jednoduché.

Řekl bych, že normálně nemluvíme nějak moc často. Alespoň já. Resp. mám na mysli nějaké složité rozhovy. Ne takové ty srandičky typu „Hi, how are you?“ - „I'm good, thanks. What are you doing tonight?“ - „Probably I'll drink in my favourite bar.“, ... Jinými slovy běžně není moc možností, jak se naučit angličtinu na dobré úrovni. Pokud neumíte angličtinu vůbec, jednoduché věty vás naučí díky četnosti základy velmi rychle. Ale když už angličtinu umíte, nijak výrazně vás to neposune kupředu.

Zkusil jsem takový trik, který mi v tomhle pomohl. Každý má myšlenky a každý má své myšlenky v jeho rodném jazyce. Já zkusil po celou dobu jazykového kurzu angličtiny mít i myšlenky v angličtině. Je to namáhavé a limitující, protože samozřejmě chceme přemýšlet komplexně. Ale zkuste to a nevzdávejte to.

Navíc si představte situaci, že jste například v nějakém obchodě, něco si prohlížíte a přemýšlíte nad důvody, proč si to koupit a nekoupit a zda tady někde nemají tohle, ale s jinými parametry (například tahle košile je super, ale mohla by mít jinou barvu, velikost a střih). Najednou za vámi přijde obchodník a zeptá se, zda potřebujete pomoct. Pokud přemýšlíte v češtině, musíte své myšlenky přeložit. Pokud v angličtině, jednoduše zopakujete, co jste si před chvíli řekli pro sebe.

Další třetí tip tedy je: snažit se přemýšlet v angličtině.

Když už umíte angličtinu trochu lépe, dalším krokem jsou média. Nejprve můžete zkusit se zaposlouchat do textů vaší oblíbené písničky a zkusti dekódovat o čem to vlastně zpívají. Pokud tedy obsah už neznáte. Dále pokračovat s filmy. Nejprve s titulky a potom i bez nich. Z toho co jsem viděl naposledy můžu doporučit Hunger Games – je to nový, dobrý a rozuměl jsem všemu (= není to složitá angličtina; zkuste bez titulků).

Nakonec nějaké třešničky. Jako první třešnička je četba v angličtině a druhá je nastavit si technicku do angličtiny (počítač, mobil, tablet, televizi, webové účty, cokoliv). Popravdě tu druhou třešničku bych doporučil jako první krok při výuce jakéhokoliv nového jazyka, ale to je pro silnější osoby.

A to je celé. Tohle málo mi pomohlo se během krátké doby posunout v angličtině z úrovně B1 na úroveň B2 (osobně mám pocit, že to bylo z úrovně A2 na skoro úroveň B2). Abyste byli taky úspěšní, stačí se snažit a nevzdávat se (což platí všude, nejen při studiu angličtiny). Shrňme si to: nebát se angličtinu používat, při kurzu se vyhýbat čechům, snažit se přemýšlet v angličtině a konzumovat obsah v angličtině.

Hodně štěstí!

Sublime Text: Téměř ideální IDE

Už je to nějaký pátek, co jsem narazil na IDE Sublime Text. Moc mě ale nenadchnul a tak jsem si dál používal Komodo IDE, protože jsem byl štastný držitel licence. A taky protože přeučovat se něčemu novému stojí čas a tím i peníze.

Firma ActiveState naštěstí nespí a díky tomu už (bohužel) nemohu svou licenci použít pro nejnovější editor Komodo IDE 7, které přináší spoustu vychytávek. Takže nadešel čas se na Sublime Text podívat blíže a rozhodnout se, komu přispěju svou troškou na další vývoj špičkového editoru.

Hned zprvu musím říct, že jsem ho testoval jen doma na menší práci, protože se nemohu v práci zdržovat kvůli nesžití mých prstů s editorem. Tím jsem nemusel narazit na všechny vychytávky a mouchy. Ale teď už se pustím do popisu, co mě nadchlo a co nikoliv.

V tolika souborech, aby se pra…

Určitě to znáte. Je potřeba něco vyvíjet a jelikož jste „Clean Coder“, tak máte vše rozdělené do menších souborů. Bohužel se občas stane, že se některé soubory (v různých adresářích) jmenují úplně stejně. Ve svém oblíbeném editoru si otevřete několik souborů, z toho budou tři stejného názvu. Ze začátku víte, který je který (vždyť jste je teď otevřeli a seřadili), ale za chvíli už nevíte. A hledáte a hledáte.

Hodně srandovní je pozorovat kolegu, který má jEdit. Tam se taby rozmísťují do řádků a všelijak to samo přeskakuje.

Přesně tohle se vám se Sublime Text nestane. Po otevření souboru sice zůstane v záložce pouze jméno souboru, ale po otevření jiného souboru se stejným názvem, se u obou záložek zobrazí navíc cesta k souborům, aby se daly od sebe rozeznat.

Horší to je při otevření velmi velkého množství souborů. Sublime Text taby zmenšuje a tím se tam vejde méně a méně textu. Naštěstí nemívám otevřené velké množství souborů, aby by mi to vadilo, ale někomu to vyhovovat nemusí.

Jak se ta metoda jenom jmenuje

Jednou za čas se mi stane, že otevřu soubor a teď si nemohu vybavit, co to vlastně hledám. Tak prostě scrolluju. Až narazím na to, co hledám.

Něco takového se se Sublime Text dělá velmi hezky. A efektně. Po pravé straně je (defaultně, lze vypnout) zobrazen panel s náhledem celého zmenšeného souboru. To jsem ještě nikde jinde neviděl! Výborná věc. Sice to nepoužiju tak často, ale pro fotografickou paměť to je eňo ňuňo.

Jen dva prstíčky tam strčíme…

Poměrně častá situace (u mne) je, že potřebuju jen do některého souboru nahlédnout na nějakou informaci a pak ho zavřít. Případně ještě něco zkopírovat, třeba název objektu, metody, …

V jiných editorech musím soubor opravdu otevřít a pak opravdu zavřít. Se Sublime Text nikoliv. A nevymýšlím si! Po (jednom) kliknutí na soubor (v editoru) se ihned zobrazí. Ale není otevřen v tabu. Pokud překliknu jinam, tak není v žádném seznamu otevřených souborů a musím ho případně znovu najít ve stromové struktuře. V tomto stavu mohu v souboru klidně cokoliv označit a zkopírovat a stále nebude otevřen. Funkčnost je dotažena tak daleko, že jakmile začnu editovat, tak se mi soubor už opravdu otevře. Úžasné.

I don't care

Když jsem poprvé viděl funkci, která skrývá kusy kódu, které mě zrovna nezajímají, byl jsem nadšen. Dnes už to tolik nevyužám, protože Komodo IDE nabízí dělat si záložky a v rámci jednoho souboru jednou klávesou přes ně skákat. Navíc editory s tím docela otravují – je to designově ošklivé a někdy kód skrývají blbě, že to spíš obtěžuje (například skryjí i následující mezery po metodě). Takže to vypínám.

Sublime Text na to jde dobře a hezky. Šipky pro code folding zobrazuje jen tehdy, když najedu myší nad sloupec s čísly řádků. A kód skrývá tak, jak se má. I když teď bych raději ty záložky. :)

Když jsem u toho zobrazení jen když potřebuju – podobně funguje zobrazování bílých znaků. Většina editorů umožňuje zobrazovat mezery a tabulátory jako nějaké puntíky a šipky. Je to super věc, ale nikdy jsem to neměl zapnuté natrvalo, protože to je s tím velmi nepřehledné.

Sublime Text zobrazí mezery a tabulátory normálně (jako prázné místo). Ale po označení textu se tyto bílé znaky zamění na zmíněné puntíky a čáry. Inteligentní.

Příjemné na pohled

Každý správný editor musí mít podporu schémat. A každý takový editor musí mít minimálně jedno tmavé schéma. Jinak to nikdy nemůže být můj editor. Koukat několik hodin denně do monitoru nelze se světlým pozadím. Prostě bez tmavé ani ránu.

Původně jsem si oblíbil schéma Oblivion v Geditu. Toto jsem se snažil dostat i do Geany. A povedlo se. Potom jsem si oblíbil v Komodu schema Dark, které se mi líbí nejvíce do dnes. Ale až Sublime Text je editor, který má tmavé schema nasteveno defaultně; potěšilo. Dokonce i poměrně hezké. Ale žádný strach – Sublime jich má spoustu na výběr, i netmavých!

Z nuly na sto km/h pod sekundu

Sublime Text je rychlý. A to hodně!

Ještě jsem nikde jinde neviděl takovou rychlost. Možná tak u obyčejného Geditu či Notepadu. Jenže ty neumějí to, co Sublime Text. Ostatní editory se s ním v rychlosti nemohou vůbec srovnávat. Například raději jeden řádek upravím ve vim-u, než abych zapínal Komodo (které startuje třeba 20 sekund). Sublime Text naběhne téměř okamžitě.

Rychlost není pouze při zapínání editoru, ale všude. Například rychlé otevírání souborů, vyhledávání, nahrazování, … A nejlépe s klávesovými zkratkami CTRL+P/R/G. Vyzkoušejte si. ;)

Správný programátor zvládne multitasking

Taková třešnička: pomocí CTRL + klik lze vkládat více kurzorů. Tím lze editovat několik řádků najednou. Taková blbina, ale hezká. Někdy se to může hodit více, než hromadné nahrazování. A hlavně, kdo může v jiném editoru psát více kódu najednou?! :)

Ale…

…i tak to nebude můj hlavní editor. Ani doma, ani v práci. Proč? Inu, protože má i své nevýhody. První, taková drobnost, je správa projektů. Vygeneruje to víc, než jen jeden soubor (dva), a to je moc. Nemám rád, když to zaplní pracovní adresář „kravinama“, které nezačínají tečkou. Akorát se to motá pod nohama. Ani pak nevím, který soubor mám otevřít. A každý projekt se mi otevírá v novém okně.

Dál mi vadí, že si do postranního panelu se seznamem souborů musím adresář ručně přidat. Nemohu listovat z home či z root adresáře, jako v Komodu či Geditu a kdekoliv jinde. To mě docela zklamalo.

Při vyhledávání metod (pomocí zkratky CTRL+G) se sice rychle filtrují výsledky, ale pokud mám v souboru dvě třídy a oba mají metodu se stejným názvem, tak nerozeznám která je která. Komodo IDE to má vyřešené lépe – vypís zobrazí jako stromovou strukturu a nadřazený objekt neskryje.

(Ne)verzujeme

Zatím to byly drobnosti, které by šly překousnout, ale co mi opravdu vadí a přes co nejede vlak, je podpora verzovacích systémů. V Komodo IDE jsem si zvykl na rychlé zjištění stavu souboru, na rychlý náhled diff-u, na rychlý pohled do historie souboru.

Zde nic takového není. Našel jsem pouze nějaké rozšíření, které umí zjistit stav souboru a zobrazí nějakou konzoli, kterou mohu zavřít tak, že kliknu v menu na otevřít konzoli (páč klávesová zkratka nefunguje) a poté kliknu na zavřít konzoli. Jinak se toho nezbavím. A neumí to commitovat, neumí to zobrazit historii, diff. Nezobrazí stav souboru ikonkou v tabu ani v postranním panelu se seznamem souborů. A to je velká škoda!

Možná, pokud to někdo nestihne udělat přede mnou, bych si zkusil napsat vlastní extension pro Sublime Text pro podporu verzovacích systému. Se stejnou funkčností jako je má Komodo. Pak to bude super.

Takže

Suma sumárum to je velmi povedené vývojové prostředí. Vidím velkou šanci, že opustím mé oblíbené Komodo IDE a přejdu na Sublime Text. Vychytávek je opravdu spousta a určitě ho všem doporučuju minimálně zkusit. Ale já s jeho nasazením ještě posečkám.

Pokud podpora verzování je důležitá i pro vás, pak upozorním, že do 15. března je Komodo IDE 7 ve slevě. Jak nová licence, tak upgrade ze šestky.

Komunikace je důležitá

Nedávno jsme měli v práci opravdu kritickou situaci. Nasazovali jsme nový release aplikace a při tom se vloudila chybička. Ta nic ošklivého sice neprovedla, ale naneštěstí za ní následovala další, která kvůli té první už ano. Zničehonic jsme se dostali do pěkné ošklivé situace, ze které se nešlo dostat zpět. Aspoň ne jednoduše a bez újmy. I přesto, že jsme se pečlivě připravovali a promýšleli různé scénáře…

Co se dalo dělat. Muselo se to prostě dokončit a dostat do co nejlepšího stavu. Zůstali jsme tedy v práci o „něco“ déle a snažili se to dát do pořádku. Byla to rušná noc a po pár hodinách spánku i krušné ráno. Vlastně ještě několik dalších dní. Nic příjemného.

Proč to ale píšu – po každé takové situaci se snažím ohlédnout zpět a najít chyby, kterých jsem se dopustil. Po takové situaci jsou totiž vidět nejlépe mezery, které je potřeba eliminovat. A těmto chybám se příště, pokud možno, vyhnout velkým obloukem.

Ohlédl jsem se i nyní a našel u sebe nedostatek v komunikaci. Ne, že bych měl problém mluvit nebo tak podobně, ale spíš problém se přesně vyjádřit. Aby když popíšu hrníček na kávu, tak aby si spolukonzultant představil přesně ten samý hrníček jako já.

Hodně dobře problém dvojznačnosti popisuje ukázka z knížky The Cleaner Coder: A Code of Conduct for Professional Programmers od Robet C. Martin:

Sam (stakeholder): “OK, now these log files need to be backed up.”
Paula: “OK, how often?”
Sam: “Daily.”
Paula: “Right. And where do you want it saved?”
Sam: “What do you mean?”
Paula: “Do you want me to save it a particular sub-directory?”
Sam: “Yes, that'd be good.”
Paula: “What shall we call it?”
Sam: “How about 'backup'?”
Paula: “Sure, that'd be fine. So we'll write the log file into the backup directory every day. What time?”
Sam: “Every day.”
Paula: “No, I mean what time of day do you want it written?”
Sam: “Any time.”
Paula: “Noon?”
Sam: “No, not during trading hours. Midnight would be better.”
Paula: “OK, midnight then.”
Sam: “Great, thanks!”
Paula: “Always a pleasure.”

Later, Paula is telling her teammate Peter about the task.

Paula: “OK, we need to copy the log file into a sub-directory named backup every night at midnight.”
Peter: “OK, what file name should we use?”
Paula: “log.bakckup ought to do it.”
Peter: “You got it.”

In a different office, Sam is on the phone with his customer.

Sam: “Yes, yes, the log files will be saved.”
Carl: “OK, it's vital that we never lose any logs. We need to go back through all those log files, even months or years later, whenever there's an outage, event, or dispute.”
Sam: “Don't worry, I just spoke to Paula. She'll be saving the logs into a directory named backup every night at midnight.”
Carl: “OK, that sounds good.”

Ukázku zvěřejňuju s laskavým svolením autora 

Jak je z ukázky dobře vidět, oba se domluvili, oba byli spokojení, ale každý si to představil jinak. Sam, stejně jako zákazník Carl, měl na mysli zálohu každého dne, ale Paula to pochopila jako zálohu jen za poslední den. Bylo by velmi nešťastné, kdyby na to přišli až v produkčním nasazení.

Proto je potřeba se takových situací vyvarovat. Asi nejlépe to jde s akceptačními testy, jak posléze popisuje ve zmíněné knize Robert C. Martin. O těch se ale nebudu rozepisovat – přečtěte si knížku, anebo si akceptační testy vyguglete. Chci ukázat, jak může jednotlivec pomoct v obraně proti nejednoznačnosti (bez nutné aktivní účasti dalších lidí).

Poměrně jednoduše to lze pomocí odlehčených akceptačních testů. Například zrovna dnes jsem něco takového udělal: potřeboval jsem si ověřit, že vývoj nové funkcionality souhlasí se zadáním. Jednoduše jsem si proto přivolal zadavatele a poprosil, zda se může podívat na polotovar. Zda je to takhle OK. Ještě, že jsem to udělal! Nebyla tam nějaká drobná nejasnost, ale poměrně zásadní. Upravovat to později by mě stálo zbytečně dost času navíc. A hlavně firmu zbytečně více peněz.

Stále se ale může stát, že k nejednoznačnosti dojde a dělá se zbytečná práce. Proto je dobré být neustále na pozoru – hledat možné nesrovnalosti a případně si je ihned vyjasnit. Jako dobrá pomůcka si mi osvědčilo si po přečtení nebo vyslechnutí požadavku celý problém znovu projít, popsat ho svými(!) slovy, sdělit je zpět zadavateli a nechat si potvrdit, že vše souhlasí. Případně si o tom ještě promluvit.

Podle zkušeností mohu říct, že tyhle dvě pravidla pomohou snížit „ambiguity“ na minimum. Bohužel to je jen pro přijímání zpráv. Opačně se musí (pro jistotu) předpokládat, že si druhá strana nejednoznačnosti nevšimne, a podle toho se vhodně vyjadřovat. A to je přesně to, co mi zatím moc nejde a na čem musím zapracovat. Snad nebude dlouho trvat a budu psát pokračování k tomuto článku s ověřenými tipy, jak na to. :)

Hello World

Každý má nějakou úchylku. Někdo sbírá céčka, někdo známky, někdo Pokémony. Někdo nemůže být bez televize, někdo si musí kupovat svíčky a někdo má úplně něco jiného. No a já si píšu (resp. začal psát) různé programovací ukázky. Takový „hello world“ všeho možného.

Zatím jsem si vytvořil jen jednoduché ukázky – Hello World a výpočet Fibonacciho posloupnosti – v různých programovacích jazycích, se kterými jsem se už setkal. Jinými slovy zatím nic zajímavého. Postupně však budu přidávat složitější ukázky a nejen ukázky jazyků, ale i knihoven (Django, Closure, …). Pro mne to tak bude cvičení, abych nezkrněl; pro někoho jiného možný zdroj jednoduše pochopitelných ukázek.

Zdrojové kódy mám na GitHub'u v repozitáři helloWorld.

EDIT: Na stránce se statistikou zastoupení jazyků je krásně vidět, jak je který jazyk ukecaný (díky tomu, že jsem všude napsal stejné ukázky). Nutno podotknout, že assembler je zkreslený, poněvadž má zatím pouze Hello World (nenašel jsem překladač pro Linux, který jsme měli ve škole, a zatím jsem nedostal odvahu v tom jiném napsat výpočet Fibonacciho posloupnosti).

Seknul jsem s vysokou. Proč?

Studoval jsem na ČVUT na Fakultě informačních technologií obor softwarové inženýrství. Kombinovaně. S touto školou je také spojen tento text a pro jiné školy zřejmě nebude platit. I když nevěřím, že to bude někde jinde lepší.

V době studijí, když jsem začal uvažovat o tom, proč mě ta škola vlastně nebaví a nenaplňuje, jsem zjistil, že důvodů je opravdu dost. Většina šla přenést přes srdce:

Například mi vadilo, že jsme v jednom semestru dostali skoro samé doktorandy. Za ten semestr jsem se toho naučil opravdu málo, protože nebyl nikdo, kdo by látku řádně vysvětlil – přeplnit prezentace textem a přečíst ho před publikem umí kde kdo. Jeden předmět (lineární algebru tuším) jsem raději vůbec neabsolvoval, poněvadž jsem se nechytal a doufal jsem, že příští rok si to vezme na starost někdo schopnější (to už se ale nedozvím).

Další věcí, co mi vadila, je přílišná upnutost profesorů na progtest (webová služba testující domací úlohy z oblasti programování). Progtest je fain. Proti němu nic nemám, mám jen problém s jeho využitím. První úlohy byly v pohodě – ty šly napsat jen jedním způsobem a tak se každý dostal ke správnému výsledku. Čím byly ale úlohy složitější, tím byl větší problém progtest překonat. A ne z důvodu, že by to bylo těžké, ale z důvodu, že jsme museli udělat přesnou kopii referenčního řešení bez žádných informací. Přičemž profesoři nehledí na to, zda to funguje, ale zda to projde progtestem.

Nedostatek informací. ČVUT má nabitý server s informacemi a studijními materiály. Pro kombinované studium udělali u každého předmětu i speciální sekci. Potuď to je OK. Bohužel ta speciální sekce byla často prázdná a některé materíály jsme dostali až po zkoušce. Kombinované studim je velmi zmatené a vlastně nikdo neví, jak by mělo probíhat. Různé pokusy organizace nejsou výjimkou.

Mohl bych sepsat další věci, které mi vadily a ke všem sepsat nejeden příklad. Ale neudělám to, protože to si musí (jak to tak vypadá) každý student přetrpět a i já jsem to přetrpěl. Přetrpěl jsem to rok a půl, než jsem dostal opravdový důvod k ukončení studia. (Ve skutečnosti jsem studia zanechal – ukončit by bylo v případě, že mě škola z nějakého důvodu vyhodila.)

Jako hlavní důvod, proč jsem opustil školu, je nucením do školních projektů, aka semestrálek. Asi si teď myslíte, že jsem blázen, že? Vysvětlím…

Nejde mi o to nědělat semestrálky vůbec, ale o to dělat něco užitečného. Profesoři si vymyslí nějaká pravidla (která musí být chtě nechtě dodržena) a zbytek ať si student vymyslí sám. Podle mého názoru to je špatný způsob. Líného studenta to stejně k ničemu pořádně nenaučí a ty méně líné to omezuje.

První případ: Semestrální práce má být přibližně tohoto tématu (s takovouto odchylkou) a být tááákhle moc rozsáhlá. Líný student si řekne OK a vybere si nějaké téma z daného rozsahu. Postupně svoji semestrální práci rozšiřuje a rozšiřuje, aby splnil dané podmínky o rozsáhlosti. V průběhu ho napadne bombastická fičura, kterou by mohl do své práce integrovat. Narazí však na problém a, jelikož se jedná o líného studenta, tak se raději pokusí vymyslet jiné rozšíření, které do jeho práce snadněji zapadne.

Asi je patrné, že když takový člověk (předpokládejme úspěšné absolvování předmětu) v životě přijde před skutečný problém, tak bude mít stejné problémy jako člověk, který semestrální práci nedělal.

Druhý případ: Semestrální práce má být přibližně tohoto tématu (s takovouto odchylkou) a být táááákhle moc rozsáhlá. Méně líný student si řekne OK, něco podobného jsem už dělal, použiju to. Studentova dřívější práce by plně postačila pro potřebný rozsah (i kdyby byl nutný rozsah mnohokrát větší). Profesor na něj však kašle, protože se téma odchyluje o malinko víc, než se smí, a student „by neměl stejné podmínky jako ostatní.“ Musí tedy dělat trapnou a nepoužitelnou práci jako ostatní, místo aby rozšířil svou stávající a užitečnou.

Vidíte kam tím mířím? Dělat školní projekty stojí akorát drahocený čas a nic to neznamená. Absolvováním se nestáváte lepším než ostatní, protože to mohou úspěšně absolvovat i ti horší. Bohužel jsou lidé s titulem vnímány jako ti lepší. Po mé zkušenosti lidi s titulem vnímám jako lidi, co měli čas dělat zbytečnou práci a sílu to všechno přetrpět. Minimálně u technického vzdělání, u doktorů to snad neplatí.

Před ukončením studií jsem u přátel hledal důvod, proč studovat. Něco, co by problém se Sysifovskou prací vykompenzovalo. Něco, co mi škola dá cenného za tu dřinu, krom titulu. Zjistil jsem, že nic, co bych nedostal v praxi. Snad až na obhajobu jasného, ale to zase naučí život, když se musím jednou za čas dohodnout s nějakým blb… méně vnímavým člověkem.

Pro zajímavost uvedu několik argumentů, které se mi dostaly na otázku, proč studovat:

• zajímavý achievment,
• způsob uvažování,
• analytický přístup,
• prezentační dovednosti,
• argumentační dovednosti,
• zkušenost pracovat v neznámém/nefungujícím týmu,
• a kontakty.

UML diagramy s graphvizem

Školu nemám rád, často jsem z ní na nervy, ale za jednu věc jí jsem vděčný – za předmět „Technická dokumentace.“ Díky tomu jsem se dostal k LaTeXu, graphvizu a dalším zajímavým aplikacím. Dnes chci poukázat na graphviz a možnost s ním vytvářet UML diagramy, protože na něj těžce narazíte. Neviděl jsem na něj doporučení, pokud jsem ho přímo nehledal.

Graphviz

Graphviz lze nainstalovat (na Debian-like systémech) pomocí příkazu apt-get install graphviz. Pokud máte nainstalováno, tak si zkuste vytvořit soubor (řekněme že test.dot) s tímto obsahem:

digraph G {
    A -> B
    A -> C
}

a vygenerovat z toho například PNG obrázek pomocí příkazu dot -T png -O test.dot. Výsledek je dobrý, že? Pro více informací, ukázek a dalšího materiálu navštivtě stránky projektu.

Graphviz se sám postará o rozložení prvků – jen se nadefinují prvky a vztahy mezi nimi – a jde mu to dobře! To je přesně to, co se mi na tom líbí. Když jsem potřeboval vytvořit UML diagram, tak jsem prošel spoustu aplikací, ale buď aplikace nešla zkompilovat, nainstalovat, používat a nebo měla nějaký jiný problém. S graphvizem jsem udělal UML diagram za půl hodinky bez problémů.

UML diagramy

Nebudu to zbytečně okecávat – našel jsem si a upravil „šablonu“ pro UML diagramy:

digraph G {
    fontname = "Bitstream Vera Sans"
    fontsize = 8

    node [
        fontname = "Bitstream Vera Sans"
        fontsize = 8
        shape = "record"
    ]

    edge [
        fontname = "Bitstream Vera Sans"
        fontsize = 8
        arrowtail = "dot"
        arrowhead = "none"
    ]

    user [
        label = "{User|id: int\lname: varchar\l|delete()\lcreateContact()\l}"
    ]
    
    contact [
        label = "{Contact|user_id: int\lname: varchar\lnote: varchar\l|delete()\l}"
    ]
    
    user -> contact [
        taillabel = "1"
        headlabel = "0..*"
        label = "own"
    ]
    
    contact -> user [
        arrowhead = "empty"
        taillabel = "1"
        headlabel = "1"
        label = "contain"
    ]
    
}

A to vygeneruje následující obrázek:

Myslím, že z ukázky je vše patrné a není třeba to komentovat. Souhlasím, že zápis samotných boxíků není zrovna ideální, ale raději překousnu tento zápis než bojovat s aplikacemi, které si myslí, že mi usnadňují práci s rozmístěním boxů a čar (například aplikace Dia se mi stále snaží vnucovat divné rozložení čar i když si sám řeknu, jak to má být rozložené).

Na záver přidám ještě jednu ukázku – můj diagram vytvářený pro semestrální práci předmětu Databázové systémy: dbs-dot.zip.

Vkládání znaků v GTK+ pomocí hexa kódu

Jsem na Linuxu už několik let a za celou tu dobu se mi nepovedlo přijít na to, jak vkládat znaky pomocí jejich kódu. Celá ta léta to byla jediná věc, která mi z Windows chyběla – jejich vkládání znaků přes levý (možná pravý) ALT a číselný kód. Až do teď. Sice jsem nepřišel na to, jak stejný hmat rozchodit i pod Ubuntu, ale pro GTK+ prostředí existuje jiný hmat se stejnou funkčností.

Stačí stisknout naráz CTRL + SHIFT + U + hexa kód. Asi jste si to hned vyzkoušeli a zdá se vám to velmi nepohodlné, ale nezoufejte – lze nejprve stisknout naráz CTRL + SHIFT + U, pustit, vyťukat hexa kód a potvrdit ENTERem. Sice to není pohodlné, jako ve Windows, ale už se to dá používat. :)

Po pravdě jsem ale trošičku kecal – úplně o stejnou funkčnost se nejedná. Zkuste napsat zavináč. Ve Windows ho vložíte přes ALT + 64, ale zde přes CTRL + SHIFT + U + 40. Jakto, ptáte se? Je to tím, že zde se jedná o hexa kód, kdežto ve Windows se jedná o dekadický kód znaku.

Na zmíněnou metodu jsem nepřišel sám, ale našel jsem ji v komentářich na sociální síti Google+ pod postem od stránky Česky (kterou mimochodem doporučuju sledovat), kde se řešily pomlčky. Pro doplnění: dlouhá mezera (en-dash) má hexa kód 2013 a americká (em-dash) 2014.

Edit: Kolega tuto metodu vyzkoušel i v prostředí KDE, kde také funguje. ;)

Tip na hru pro Android - Fieldrunner HD

Před pár dny proběhla na Android Marketě akce, kde si šlo každý den po deset dnů stáhnout 10 aplikací pouze za 10 procent ceny. Samozřejmě jsem nabídky využil a nakoupil asi 15 různých aplikací a her; no za třicet kaček nekup to!

Všechny zakoupené aplikace či hry jsou super, ale zjistil jsem, že mi všechny ty aplikace jen tak nehybně leží na paměťovce. Až na jednu hru – ta si mě doslova získala. Jedná se o skvělou tower defense gamesu – Fieldrunner HD. Z názvu asi není pořádně slyšet, jak je ta hra úžasná, tak raději rovnou trailer:

A pokud stále nevěříte – nainstalujte si ji! :)

Apple vs. Samsung

Poslední dobou se hodně píše o tzv. patentových trollech a o sporu Apple vs. Samsung. Hned na začátku chci zmínit, že se mi nelíbí, čím se patenty staly (patenty za mě ano, ale ne tak, jak jsou dnes vnímány a používány) a že nejsem fanoušek Applu (nemám žádný jejich výrobek a ani se mi žádný nelíbí). To by bylo, teď ten spor.

Apple v Evropě zažaloval Samsung, že Galaxy Tab 10.1 vypadá velmi podobně, jako iPad 2. – Hotovo, tahle jedna věta stačila a svět se zbláznil a začaly se chrlit negativní názory vůči Applu, že si nechal „patentovat cihlu a teď bude domy stavět pouze on“, a podobně. Tak to ale, milé lidi, není. Zaprvé jsme v Evropě, kde patenty, o kterých je hodně řeč, neplatí – v tomto sporu se jedná o průmyslový vzor; a za druhé se nejedná o „placku s displejem“ ani o to, jak ta „placka“ funguje, ale o něco jiného, viz dále.

Applu se nelíbí to, že Galaxy Tab 10.1 se snaží o zaměnitelnost s iPad 2. Možná se nesnaží, ale to už je problém Samsungu, že udělal vzhledově totožné zařízení. Apple vzhledově popisuje iPad 2 nějak takto (stručně):

• čtyři stejne zakulacené pravoúhlé rohy,
• čirý povrch přes celou přední plochu bez vzoru,
• vycentrovaný display s neutrálním ohraničení,
• a tenké provední se zakulacenými hrany pro vzbuzování užšího dojmu.

Samsung se přitom dopustil toho, že ve svém výrobku Galaxy Tab 10.1 použil všechny detaily najednou. Tím je na větší vzdálenost těžké tyto dva tablety od sebe rozeznat; ještě těžší je to pro člověka, který ani jeden tablet v ruce nedržel a ani se pravidelně někochá jejich fotografiemi (například já).

Dávám tedy za pravdu Applu a přeju mu, aby tuto bitvu vyhrál!

Samsung by se měl konečně poučit a vymyslet něco svého. Vždyť i ten telefon Galaxy S byl kopií iPhonu! Dokonce to byla tak hnusná kopie, že bych si raději koupil iPhone, než Galaxy S.