Právě dnes uběhne 121 let od narození sira Karla Raimunda Poppera.
Člověka, který měl na mě větší vliv než kdokoli jiný v mém životě a proti kterému jsou i živí lidé jen stíny z podsvětí. A na jeho památku vyvrátíme některé nesmysly, které se o jeho učení šíří.:)

Dole byste měli vidět screenshot příspěvku, který jsem chtěl použít jako zadání „napište, v čem text Popera dezintepretuje“.

Už jsem tady kdysi popisoval dezinterpretace principu „intolerence vůči intoleratním“. A tady máme další nádherný příklad zaštiťování se autoritou, i když autor komentáře Popperovo dílo nezná, nebo se s ním seznámil v příručce typu „jak věrohodně předstírat na večírku znalosti o evropské filosofii“. Nebudu vás ale trápit a tvrzení nekompatibilní s Popperovým učením odhalím sám.

(Zase jde o typ článku, který se před mnoha lety objevoval i na tomto blogu. Jestli vás tato témata zajímala, pokračuje prosím ve čtení článku.)

Pythonista, který čte knihy pro začátečníky a dokáže poznat, která je dobrá. Najde se tu někdo takový? Asi ne, ale přesto se zkusím zeptat.
Pro synka Míšu (13 let) bych chtěl doporučit nějakou pěknou knihu o Pythonu. Asi raději v češtině, čímž se výběr dost zužuje.

Kniha by měla nenásilně vysvětlit.
1) Základy programování v Pythonu.
2) Základní datové struktury a kdy je použít.

A jniha by měla fungovat jako základní referenční příručka, která je vždy po ruce. I Míša ví, že na webu je dost tutorialů, ale nějaká kniha s výkladem, kde zazní "proč", a ne jen "jak", by pro něj mohla být přínosná.
Míša se naučil v Pythonu "nějak" programovat a s pomocí knihovny PyGame napsal pár her. Létající objekty, raketky, autíčka.

Programuje dost živelně a rychle, což není na škodu, ale přišla doba, kdy:
1) Bylo by dobré, aby viděl i někde jinde, že není nejlepší pokaždé celý kód narvat do jedné funkce. Výkřik "Tak jsem něco napsal. Pojď se, taťko, podívat, jak jsem to zase naprasil." sice výborně utužuje naše vzájemné vztahy, ale z posledního proifovaného kódu mě už přece jen bolely oči. Příklady v knize by ale neměly působit uměle - refaktorizace už tak malé funkce do ještě menších funkcí jen kvůli tomu, že to tak autorovi přijde správné a nepoučený čtenář snese hodně.

2) Nějaký základní výklad datových struktur. Posledně Míša vytvořil piškvorky na ploše 3x3, ale jak jsem později zjistil, plocha 3x3 byla v malování vytvořený statický obrázek :), na který potom vykresloval kolečka/křížky, příznak, jaký čtverec je aktivní atd. Když jsem po něm chtěl, aby vykresloval "nekonečnou" plochu, nebo alespoň čtvercovou plochu o velikosti zadané uživatelem, dostali jsme se právě k tomu, proč je pro reprezentaci stavu tohoto typu hry vhodné (dvourozměrné) pole a proč se nedá vše v programu řešit konečným množstvím ifů, několika tucty špatně pojmenovaných proměnných a enumerací fixního počtu "vítězných" stavů.

3) Výklad by neměl svou suchopárností potlačovat právě tu radost z "prasení" kódu a objevování. Neměl by dogmaticky tvrdit, že se pokaždé programuje právě jen takto a nikdy jinak. Naopak, měl by ukazovat, že k výsledku vede mnoho cest a že programování je aktivita v otevřeném světě, kde jen úplní hlupáci postupují po vyznačených cestičkách a v ruce nesou bibli momentálně platných zásad, pravidel a konvencí, protože se bojí, aby je kolegové-inkvizitoři při code review nezačali křižovat, místo toho, aby dodali po všech stránkách originální, problém skutečně řešící a technicky brilantní řešení. Výklad by ale měl nenásilně sugerovat, že je dobré pravidla perfektně znát, než je začnu z důvodu vyššího projektového dobra porušovat. Výklad by neměl ukazovat OOP/FP na místech, kde OOP/FP ničemu neposlouží a jde jen o samoúčelné hrátky typu "júúú dekorátor a heč, znám i monády a chrstnu ti je do tváře v každé kapitole, i když jsem jejich princip sám nepochopil".

4) A kdyby v průběhu výkladu autor vytvářel nějakou hru, bylo by to ideální, ale to už bych chtěl asi moc.

5) Kniha musí být pro novější verzi Pythonu.

V Pythonu nedělám. V ČJ jsem našel jen dvě knihy, které vypadají zajímavě.

Pecinovský, Rudolf: Začínáme programovat v jazyku Python 2., přepracované a rozšířené vydání. Grada.
Nejsem úplně nadšený z toho, že jde o Pecinovského, který asi přesedlal z Javy, ale třeba mám jen (odůvodněné) předsudky.

Summerfield, Mark: Python 3: Výukový kurz. Computer Press 2021.
Bohužel jde o překlad a už jsem zase narazil na to, že tyhle překlady stále dělají individua, evidentně blbější než DeepL i Google Translate, která přeloží klíčová slova jazyka ve výpisech zdrojového kódu. A neotřelý český překlad, ve kterém se objevuje slovo "madlo" a znamená Win handle, mě ve snech straší pořád.

Nemáte někdo tip? Díky.

Jak asi sami víte a vidíte, tento blog je technicky zaostalá zombie a neměl jsem zatím čas ani chuť přenést příspěvky na moderní blog engine s https.
Nedávno se ke mně od jednoho starého fanouška donesla stížnost, že na blogu se objevovalo nejen více technických příspěvků, ale také články s jinými tématy.
Kdyby moje výplody “de profundis” a z ještě temnějších míst chyběly i někomu dalšímu, kdo sem ještě zabloudí, vězte, že:

Už někdy v roce 2010 jsem netechnické články přenesl na blogovací platformu Posterous. Psal jsem o Posterous API i tady, dokonce jsem si prozřetelně s využitím Posterous API napsal nástroj, který mi zazálohoval všechny příspěvky na Posterous blogu. Asi jsem měl nějaké tušení, jak nablýskaný Posterous dopadne. Posterous totiž po krátké a těžké nemoci zesnul, budiž mu digitální země lehká. Pokračovatelem mého blogu na Posterous se stal blog “Život po Posterous” (nemusím vysvětlovat proč) s podtitulem “Parerga a paralipomena – apage vemena” (nechci vysvělovat proč, laskavý čtenář pochopí).

https://renesteinposterous.wordpress.com/
RSS: https://renesteinposterous.wordpress.com/feed/

Na blog někdy přidávám delší příspěvky z FB.
https://www.facebook.com/renestein/

Twitter cca od roku 2015 nepoužívám. To, že v panelu vpravo na tomto blogu můžete vidět vloženou timeline z Twitteru, je jen důkaz, jak dlouho se mi už nechce tento blog po technické stránce upravovat. Mea culpa, mea maxima culpa, pravidelně si trhám šat a sypu popel na hlavu, ale co se dá dělat, ani tyhle bohulibé aktivity nepomáhají a jsou zajímavější činnosti než úklid bordelu na starém DasBlogu.

P. S. Jsem také na Goodreads.
https://www.goodreads.com/user/show/4224377-rene-stein

Aktualizace 4. 12. 2012 – kurz Objektovými principy a návrhovými vzory řízený design a vývoj kvalitních aplikací 1 je zcela obsazen.

Opět bych vás rád pozval mé kurzy. Jak jste si asi všimli, tento rok “podzimní” termíny kurzů vyhlašuju kvůli různým peripetiím o něco později, takže místo podzimu se s některými z vás uvidím netradičně až v zimě. Snad to nevadí.

Také již tradičně připomenu, že je možné si objednat inhouse (ve vaší firmě uskutečněnou) variantu těchto kurzů i se domluvit na zcela jiné osnově vystavěné z témat, o kterých něco vím a jejichž výběr naleznete na mých stránkách. Všechny dotazy k veřejným i inhouse kurzům rádi zodpovíme na emailu rene@renestein.net (můj email) nebo na emailu petra@renestein.net (Petra Steinová, která rychleji a lépe než já odpoví na dotazy týkající se organizace veřejných i inhouse kurzů).

Veřejný kurz Objektovými principy a návrhovými vzory řízený design a vývoj kvalitních aplikací 1  - kurz je obsazen

Datum konání kurzu: 10. - 12. 12. 2012

Místo konání:

Školící středisko Tutor

U Půjčovny 2
110 00 Praha 1

Po celý den máme k dispozici wifi připojení a samozřejmě také teplé a studené nápoje. V ceně kurzu jsou obědy v hotelu.

Podrobné informace o kurzu a možnost přihlásit se na kurz

Program kurzu

FAQ - často kladené dotazy ke kurzům

Veřejný kurz Základy objektově orientovaného návrhu a vývoje (UML 0)

Datum konání kurzu: 14. - 16. 1. 2013

Místo konání:

Školící středisko Tutor

U Půjčovny 2
110 00 Praha 1

Po celý den máme k dispozici wifi připojení a samozřejmě také teplé a studené nápoje. V ceně kurzu jsou obědy v hotelu.

Podrobné informace o kurzu a možnost přihlásit se na kurz

Program kurzu

FAQ  - často kladené dotazy ke kurzům

Veřejný kurz Objektovými principy a návrhovými vzory řízený design a vývoj kvalitních aplikací 2

Datum konání kurzu:  21. - 23. 1. 2013

Místo konání:

Školící středisko Tutor

U Půjčovny 2
110 00 Praha 1

Po celý den máme k dispozici wifi připojení a samozřejmě také teplé a studené nápoje. V ceně kurzu jsou obědy v hotelu.

Podrobné informace o kurzu a možnost přihlásit se na kurz

Program kurzu

Výběr z ohlasů na kurzy

FAQ - často kladené dotazy ke kurzům

Těším se na shledání na kurzu.

Dostal jsme dotaz, jak si poradit s odstraňováním chyb u starší a rozsáhlé aplikace. Když jsem odepisoval, uvědomil jsem si, že sepisuju jakési “triviální  desatero vývoje”", které se snažím už dlouhou dobu svému okolí vtloukat dohlavy. I když jde o triviální zásady, budu příště odkazovat raději na tento příspěvek, než abych vše opakoval pokaždé znovu. Jméno firmy je v textu nahrazenou souslovím “anonymní firma”.

“Zdravím,
to je na hodně dlouhý příspěvek.
Alespoň tedy:

1) Je nutné zrušit umělou hranici mezi vývojáři a testery. Žádná výměna informací přes šéfy oddělení nebo pověřené osoby.

2) Na každou objevenou chybu musí být napsán automatický test, který zajistí, že chyba neprobublá do dalších releasů. Bez toho žádné organizační opatření nefunguje. Bez napsaného testu se chyba nepovažuje za odstraněnou, ale jen za náhodou se nyní neprojevující.

3) Vytvořit malé sebeorganizující týmy odpovědné za určitou část projektu (nastálo, nebo do dalšího releasu). V čele team leader, který garantuje kvalitu. Team leader je k dispozici i testerům a řeší nesrovnalosti v analýze a systémovém designu. S dalšími team leadery řeší problémy integrace různých částí projektu. Team leader ale stále většinu času kóduje, není to embryo vychovávané pro střední management.

4) Je potřeba postupně napsat velké množství automatických testů (unit, integrační, akceptační) tak, aby se testeři věnovali hlavně novým záležitostem v releasu a aby vývojáři ani testeři nebyli obětí "ručně prováděných" regresních testů, které mají formu nikdy nekončícího debugování. Tím se i zkrátí doba, kterou "anonymní firma" nutně musí trávit opakovaným debugováním a "ručním" nalézáním příčin chyb. Automatizované testy představují práci, která se na projektech vyplatí, a navíc jde i o mnohem levnější řešení problému, než nabírání dalších a dalších testerů.

5) Nedávat žádné fixní odhady na odstranění chyb ani nikoho exkluzivně nealokovat jen na odstraňování chyb. Vývojář není a přes různé manažerské poučky ani nebude anonymní zdroj, který sebereme z jiného projektu, posadíme k aplikaci, kterou nezná, ale u které dostane befelem, že za jednu normohodinu musí odstranit 20 bugů. Tato kouzla fungují jenom v Excelu. V reálném světě vývojář těch 20 bugů neodstraní, ani když ho posadíte do open space, který  je oblepen motivačním majstrštykem vytisknutým z PowerPointu nejlepším absolventem MBA.

Pokud se objeví chyba, chopí se jí člověk, který za danou oblast odpovídá (konflikty přinejhorším vyřeší team leadeři). Vývojář neustále čte a refaktorizuje kód, pokud možno ihned také odstraňuje chyby . A jsme opět u testů - dokud ty automatizované testy mít nebudete, vývojáři do kódu raději nezasahují, protože nevědí, kde všude se změna projeví a raději neriskují další možnou příčinu pádu aplikace po nasazení u zákazníka. A psát použitelné, ne jen formální-švejkovské testy, kdy se hodnotí "jen code coverage", se musí všichni vývojáři naučit a nějakou dobu to zabere.

Mám zkušenost s 12 let starou aplikací psanou původně pro VB, poté čátečně přepsanou na .Net Framework,  která byla po 9 letech postupně obalena testy, a ani dnes sice nejde o žádnou vývojářskou lahůdku, ale pracuje se na ní beze strachu, co při každé změně v aplikaci zničíme. Nic jiného než to, co píšu výše, se mi neosvědčilo.

A pak další záležitosti jako (nutné) bonbonky:

• Neztrácet čas “mergováním” změn v něčem tak zastaralém a nepohodlném jako je Subversion. V Mercurialu (GITu) je propagace změn z vývojové větve do hlavní (a zpět) otázka chvíle. V Subversion ani TFS jsem po pár zkušenostech raději moc "branchů" nedělal.
  
• Automatické buildy spojené s již napsanými testy.
  
• Automatické nasazení nové verze aplikace, aby testeři nemuseli pátrat, kde seženou novou verzi a také, aby nasazení do produkčního prostředí neznamenalo 3denní práci party lidí, kteří se metodou pokus-omyl snaží dostat aplikaci do použitelného stavu u zákazníka.
  
• Alespoň u nováčků code review, abyste rychle odstranili jejich špatné návyky.
  
• Statická analýza kódu.

A dovolím si jednu soukromou poznámku k "anonymní firmě" - pokud možno zredukovat/vyhodit všechny těžkotonážní, neskutečně drahé a pro vývojáře zabijácké nápady se zavedením nejhorší možné formy vodopádu  - analýza->samostatný systémový design->vývoj->testy, v jehož bludném pádu se bude produkovat množství dokumentů, navíc rychlokvašenými analytiky/designery, v mizerné kvalitě a bez vazby na skutečné potřeby projektu. Analýza a systémový design jsou fáze projektu, které pomáhají jen do doby, než se jich chytí nějaký exot, který nikdy žádnou aplikaci nevyvíjel a který si myslí, že analytická práce spočívá ve štosování nahodilých myšlenek zákazníka do příslušné šablony pro use case. Což je dle mých zkušeností většina “čistých”, míněno vývojem nedotčených, analytiků na pracovním trhu.

Několik zájemců o veřejný kurz OOP a návrhových vzorů raději zvolilo inhouse variantu kurzu, proto bych vás rád upozornil,  že se můžete ještě nyní dodatečně hlásit na kurz OOP a návrhových vzorů.

Pozvánka s odkazy na podrobné informace o kurzu.