Před téměř deseti lety se mi už stávající špagetové programování v PHP nelíbilo. Sháněl jsem něco, co by mě umožnilo psát udržovatelnější aplikace. Dospěl jsem k tomu, že MVC framework je určitě ta správná cesta, ale psát nějaký svůj vlastní jsem zavrhl hned od počátku. Na to prostě nemám. V té době přicházelo v úvahu myslím CakePHP a právě začínal Zend Framewok. Je zajímavé, že o Symfony v té době moc slyšet nebylo. Začal jsem tedy se Zend Frameworkem, říkal jsem si, že Zend bude to správné řešení, když za ním stojí taková firma, která má zájem o samotné PHP. PHP samotné bylo někde kousek za 5.2. Se Zend Frameworkem to šlo dobře. Dokumentace a podpora ze strany Zendu a komunity byla už od počátku výborná. Na Internetu se začalo objevovat spousty návodů, článků.

Pak jsem nastoupil do firmy, kde se místo Zend Frameworku používalo Nette v nějaké úplně ranné verzi, ještě stažené ze SVN nebo bůh ví odkud. Proti tomu, co jsem znal ze Zendu to byl poměrně velký krok zpět. Bylo to dáno hlavně tím, jaká to bylo ranná verze. O nějaké podpoře jako bylo u Zendu se nám nemohlo ani zdát, v podstatě jsme se pořád jen přehrabovali ve zdrojácích a zkoumali, jak co funguje. Koncept komponent jsme v té době ještě ani pořádně nechápali, používali jsem v podstatě jen presentery a šablony a v nich dokonce nějaký svůj šablonovací systém. Takže funkčně mi to přišlo i dost za tím, co bylo aktuálně v Zend Frameworku.

Takhle to vypadalo asi tak nějak do doby, než se Nette přesunulo na GitHub. To jsme teprve pořádně pochopili koncept komponent a přešli na Latte. To nám přineslo možnosti, jaké v Zendu nebyly, nebo se v něm dosahovaly velmi těžko. To bylo někde okolo vydání Nette 2.0. O Zend už jsem se prakticky přestal zajímat, jednak bylo jasné, že technologicky jsou na tom oba frameworky dost podobně a pak jsem ani neměl příliš času navíc, přišli rodinné a jiné životní peripetie.

Zhruba nějak v té době se začalo více mluvit o Symfony, které se na poli frameworků začalo stávat hvězdou. Jeden z důvodů byl možná ten, že poměrně rychlo začalo adoptovat Doctrine jako modelovou vrstvu a vůbec se stavělo k integraci různých dalších částí od jiných frameworků celkem pozitivně. Ostatní frameworky šly spíše svou vlastní cestou a pokoušely se o nějaká vlastní řešení pro modely. Nette nebylo výjimkou, vymýšlelo vlastní databázovou vrstvu, testovací framework atp.

Pak přišla doba dependency injection a její nástup do PHP, potažmo frameworků. Tady opět udalo krok Symfony, Nette přišlo až později, kdy se z velké části nechalo právě Symfony inspirovat.

Dnes je situace taková, že v tom, co Nette umí, je technologicky v podstatě srovnatelné s konkurencí. Navíc si ponechalo celkem unikátní vlastnosti, které jinde nenajdete, zejména třeba právě komponenty, šablonovací systém Latte. Hodně pomáhá Tracy, která i bez IDE dokáže udělat práci s laděním aplikace poměrně pohodlnou a výrazně tak zlepšuje efektivitu práce v PHP. Teoreticky by tak Nette mělo být na špičce v nástrojích a frameworcích pro PHP, ale není to tak.

Světu PHP dnes jednoznačně dominuje Symfony, následováno Laravelem, pak možná Zend a dalšími. O Nette moc nezavadíte. Přitom práce např. s některými částmi Laravelu bez možnosti dependency injection je když ne přímo problematická, tak minimálně až moc magická. V Čechách je to přitom přesně opačně než ve světě, tady Nette zatím pořád dominuje. Ale i u nás doma se začínají karty obracet. O tom dále.

Podle mě je to pořád o tom samém, jak jsem už psal před 7 lety. Za tu dobu se nepodařilo najít žádný model, který by Nette dal jasný výhled do budoucna a záruku současného stabilního stavu, což je to, co firma potřebuje, když si volí na čem postaví svůj produkt. Všechno si pořád dělá z velké části David Grudl jako hlavní autor sám a nikoho moc nepustí ke slovu, všechno pak začíná a končí na tom, co posvětí on a co ne. K čemu se nějak zásadně nepřihlásí, to tak nějak skomírá na okraji. Za tu dobu se nepodařilo okolo frameworku vybudovat nějaký ekosystém firem, přispěvatelů, školení, autorů komponent. Osoba autora sama o sobě je podle mě také dost kontroverzní a problematická, což také adopci frameworku nepomáhá. Když autor opakovaně vyhlašuje - mám být někde ale jsem někde úplně jinde a v neidentikovatelném stavu - tak pokud je někdo takový tím, kdo je jediný zodpovědný za osud frameworku, tak takový framework si dost možná nezvolím do firmy pro svůj nový produkt. A je celkem jedno, jestli ty hlášky jsou myšleny jako humor nebo ne.

Existuje sice Kdyby, Nextras jako sady komponent. Jsou srazy Posledních sobot, ale nějak to Nette nepomáhá k tomu, aby se prosadilo mimo svou hlavní doménu, což jsou freelaceři a web agentury. Už jsme viděli několik pokusů o to řešit různé komerční způsoby podpory, placené verze atp. Všechno vyšumělo, což opět posiluje chápání frameworku jako one man show a bere mu body při rozhodování o budoucím frameworku pro firemní projekt.

Hlavní problémy, které jsem Nette vytýkal - nedostatečná dokumentace, špatná zpětná kompatibilita, nepředvídatelnost budoucího vývoje - se podařilo vyřešit jen částečně. Hodně se toho zlepšilo, zejména dokumentace je už alespoň nějaká. Ale je na tom hrozně vidět, že tohle jsou oblasti, které autora nebaví, nedělá je tedy rád a nevěnuje jim pozornost, jakou zasluhují. Jediné, co ho baví je programovat a vymýšlet nová vylepšení frameworku. Bohužel nikdo ale do poslední chvíle pořádně neví, co zrovna vymyslí, kdy to vymyslí a kolik toho tím rozbije. Poslední aktualizace - verze 2.4 - měla být původně jen malá aktualizace s ohledem na budoucí dopřednou kompatibilitu a vyklubal se z toho ohromný interní update, který např. komplet překopal Latte, takže pokud má někdo svá vlastní složitější makra tak se bude asi dost divit.

Jak jsem napsal na začátku, sám se aktuálně nejen od Nette, ale i od PHP samotného chystám minimálně na nějakou dobu vzdálit. Ohlížel jsem se na trhu práce a je vidět sílící trend, že větší projekty často staví na Symfony, případně Laravelu jako základu a z Nette využívají tak možná Tracy, občas DI. Takže Nette ztrácí body už i v Čechách, kde je tradičně nejsilnější. Pokud se tedy Nette za chvíli nemá smrsknout na pár šikovných nástrojů, které jsou sice fajn, ale dá se bez nich obejít, tak by to chtělo něco s tím udělat.

Pořád si myslím, že bez komerční podpory, tedy zaštítění nějakou firmou, se Nette neobejde. Je celkem jedno, jestli firmu založí nějaká skupina lidí okolo frameworku, nebo se toho ujme nějaká stávající firma, která má do Nette hodně nainvestováno. Jisté je, že se do toho bude muset zapojit i sám autor. Je ale velkou otázkou jak. Manažerskou a řídící roli evidentně dělat nechce. Pokud to ale bude dělat někdo jiný, tak z Davida by se v podstatě měl stát zaměstnanec, který se bude muset podřídit tomu, co chce management a držet se něčeho, na čem se s managementem minimálně shodne. Něco takového si ale moc nedokážu představit, že po těch letech "zábavy" s programováním bude schopen dělat.

Nedávno jsme se na Twitteru mohli dočíst, že Nette konečně po letech hledání čeká něco nového, tak se nechme překvapit jestli to Nette pomůže zabránit v pomalém vyklízení dalších pozic nebo ne.

Problém už je v tom, jak se klasická Nette aplikace vlastně vyvíjí. Většinou jedete podle sandboxu, kde se vám hned na začátku v boostrapu nahodí Tracy a ta za vás všechny výjimky a chyby v aplikaci řeší a k nějakým chybovým stránkám se tak vlastně vůbec nedostanete. To je vývojový režim.

Pokud je Nette aplikace v produkčním režimu, tak to funguje tak, že výjimky propadnou celou vaší aplikací až na začátek, kde si Nette vyjímku zachytí a zavolá se speciální presenter - ErrorPresenter - který se o výjimky musí postarat. Ten má pak na starost i vykreslení našich 404 a 500 stránek. První a nejdůležitější věc je tedy nezapomenout na testování aplikace v produkčním režimu před tím, že ji nasadíte. Ideálně samozřejmě to mít někde v testovacím prostředí vyřešené pomocí testů. Pokud děláte typicky nějaké malé weby, tak si to prostě pamatovat a vyzkoušet. Když to neuděláte a zapomenete na to, tak můžete dopadnout dost špatně, propadnou vám tam nějaké staré ErrorPresentery, typicky ty ještě z toho výchozího sandboxu, pak jsou v nich špatné namespaces a celá aplikace skončí právě tou 500, ačkoli na vývojovém prostředí všechno funguje. Další věc je, že výchozí sandboxové šablony chybových stránek chtějí využívat společný layout a tam vám to také spadne na tom, že v layoutu používáte už nějaké společné komponenty nebo věci, o kterých ErrorPresenter také neví.

Takže jste si na to vzpomněli a jdete přes nasazením otestovat aplikaci v produkčním režimu. Nejjednodušší je změnit na chvíli ip adresu v boostrapu, např. místo 127.0.0.1, tam dát 128.0.0.1 - $configurator->setDebugMode(["128.0.0.1"]);. Jsme tedy v produkčním režimu při vývoji. Pak už jen otevřít v prohlížeči nějakou neexistující stránku vaší aplikace a … nestačíte se divit. Stránku 500 nasimulujete nejsnáze tak, že si do nějakého existující Presenteru vrazíte hned někam na začátek nějaké throw new \Exception("test");.

Tenhle produkční režim při vývoji je ale dost nepřátelský, samozřejmě nesmíte zapomenout na ty testovací výjimky, ale já jsem ještě narazil ještě na to, že v tomhle režimu se automaticky nepromazává keš šablon. Takže když v tomhle režimu ladíte vzhled stránky 404 v latte šabloně, tak pozor nato, že při její změně je potřeba ručně promazávat keš šablon.

Pozn. Podle komentářů od D. Grudla se zdá, že není třeba vůbec používat produkční režimem při vývoji. Pro vývoj error presenterů stačí nastavit v konfiguraci 'applications: catchExceptions: yes'. Pak místo toho, aby se při výskytu výjimek používalo Tracy, tak výjimky začnou propadávat do error presenterů a můžete je tak pohodlně odladit přímo ve vývojovém režimu.

Ještě více srandy si užijete při výskytu chyb ve vlastním ErrorPresenteru. To je z hlediska frameworku poměrně komplikovaná věc, když si člověk uvědomí, že vlastně řeší případ, kdy v ErrorPresenteru, který zpracovává výjimku se vyskytne výjimka. Co jsem měl možnost vyzkoušet, tak to dopadne tak, že chybu chytí Tracy, která tam i v produkčním režimu evidentně pořád někde zůstává a čeká kromě logování i na tenhle případ. Vtip je v tom, že Tracy vyhodí téměř na chlup stejnou stránku jako máte v sandboxu pro ErrorPresenter, takže na první pohled jste naprosto zmatení. V logách Tracy je naštěstí vidět, kde je problém.

K logám - to je další věc - je sice fajn jak loguje Tracy, ale co když nastane chyba přímo v Tracy, nebo logy přetečou? Přeci jen to Tracy logování se trochu vymyká tomu standarnímu formátu unix logů. Bohužel Tracy se nedrží toho, že by respektovala error_log direktivu PHP, naopak ji potlačuje. Určitě by mě přišlo vhodné, aby Tracy respektovala error_log a posílala tak chyby dále do standarního PHP logu. Onehdá jsme na to měli do Tracy nějaké patche, ale s přechodem na Sentry v produkci jsme je zrušili a do Sentry se nám podařilo prosadit změny, které logují chyby do PHP logu.

Pokud máte rozsáhlejší aplikaci, tak máte v zásadě dvě možnosti, jak ošetřovat chyby 404, obecně jakékoli jiné než 500.

• vyhozením výjimky - typicky Application\BadRequestException pro 404
• forwardováním na specifický ErrorPresenter

První možnost je jasná, vyhodí se výjimka a skončíme v našem hlavním ErrorPresenteru kde výjimku ošetříme.

Druhá možnost se používá u větších aplikacích, kdy potřebujete odlišit od sebe stránky různých "neexistujících věcí", protože každá se snaží uživatele vrátit zpět na do aplikace jiným způsobem. Typicky stránka pro neexistující produkt se bude lišit od stránky pro neexistují kategorii produktu, neexistujícího uživatele atd. Typicky se pro tyto případy použije jeden abstraktní pro specifické stránky a další specifické ErrorPresentery od něj pak dědí kvůli vlastním šablonám a případně další logice, jak navést uživatele zpět na web.

Tyto specifické ErrorPresenty jsou ale dost často zdrojem chyb, protože používají různé sidebary a layouty s komponentami, které se pak neumí vytvořit. Takže z nich padají výjimky, kterých si při vývoji normálně nevšimnete, protože jedete v klasickém vývojovém režimu.

ErrorPresentery si také zaslouží trochu více pozornosti. První věc je, že ten sandboxový, ze kterého budete vycházet, se mi zdá nějaký podivný, např. nedědí od UI\Presenter, nemá svou šablonu, jen phtml soubor a všechny 4xx výjimky posílá na další presentery. Cílem asi je mít obsluhu chyby 500 - fatální selhání aplikace - opravdu co nejrychleji a nejbezpečněji odbavené, i když ten forward rozhodně není jednoduchá záležitost. Jednodušší řešení mi přijde mít jeden klasický ErrorPresenter s renderdefault metodou, kde se podle výjimky, která přijde v parametru exception, rozhodneme pro šablonu a tu vykreslíme. Nemusíme nic forwardovat a máme k dispozici latte i pro chybu 500.

Pak je tu další nepříjemná věc, která platí jak pro hlavní ErrorPresenter, tak pro případné specifické neumějí obsloužit url pro signály. Nevím tedy jak je to v aktuálním Nette 2.4, ale v Nette 2.1 to platilo. Pokud jste v šabloně ErrorPresenteru volali komponentu, která vytvářela url pro nějaký svůj signál - nějaké latte volání {link signal!}, tak to v ErrorPresenteru skončí chybou. Je to tím, že ErrorPresentery nemají routy. Tohle je dost nepříjemná vlastnost, které se nedá moc předcházet, protože ve složitější aplikaci se šablony různě includují do sebe a lehce se tak stane, že nějaká komponenta z nějakého sidebaru probublá i do ErrorPresenteru. Řešením je např. udržovat šablony pro ErrorPresentery oddělené, aby se do nich takové komponenty nedostávaly, nebo podmínkovat kód těchto komponent tak aby typicky pro HTTP Response kódy 404 prostě url se signálem nezobrazovalo.

Na závěr doporučení pro ošetřování error stránek a tvorbu ErrorPresenterů

• Nezapomínat testovat ErrorPresentery a jejich chování. Ideálně automatizovaně.
• Produkční režim při vývoji má svá úskalí, např. se neinvaliduje keš šablon.
• ErrorPresentery neumí obsloužit url pro signály.

Z toho pak plynou další doporučení, která nám ulehčí udržování aplikace.

• Minimalizovat použití specifických ErrorPresenterů, idálně mít jen jeden hlavní ErrorPresenter. Pak se také všude dá použít jednoduché vyhazování výjimky BadRequestException.
• Mít šablony ErrorPresenterů jednoduché a samostatné, aby pokud možno nezávisely na dalších šablonách. Zabrání se tak zavlečení různých částí aplikace, které ErrorPresenter neumí obsloužit, zejména signálů, ale i různých komponent, které ErrorPresenter neumí vytvořit.

Něco by se určitě dalo zlepšit i v samotném Nette, potažmo v sandboxu Nette aplikace na GitHubu

• Zjednodušit ErrorPresentery v sandboxu, aby měly samostatné šablony bez závislosti na layoutu, případně aby dědily od UI\Presenter jako obyčejné presentery.
• Nějak se pokusit vyřešit url na signály u Presenterů bez rout, pokud to tedy již není vyřešené.
• Zkusit vymyslet nějaké opatření ať už v sandboxu nebo ve frameworku, které by zlepšilo možnosti vývoje ErrorPresenterů.
• Pokusit se designově odlišit 500ku v Tracy a v sandboxu, aby člověk nebyl při vývoji zmatený, na co vlastně kouká.
• Zvážit, zda nechat Tracy přes vše ostatní nakonec logovat do standarního PHP logu, je to standard, minimálně administrátoři jsou na to zvyklí.
• Doplnit někam nějaké best practices pro ErrorPresentery, pokud se tedy na něčem komunita shodne, tohle může sloužit jako odrazový můstek .

Pokud použijete

if (!empty($this->configuration["payment"][$type]["isFree"])

A v konfiguraci při nějaké úpravě změníte náhodou "payment" např. "payments", tak se klidně může stát že všichni vaši zákazníci u vás dostanou najednou všechno zdarma. Samozřejmě že jim to vadit nebude ale vašeho nadřízeného to asi moc nepotěší a on vás pak asi také moc nepotěší. Váš kód bude ale naprosto v pořádku, bez žádných chyb a NOTICES. Podobných případů a situací může být nekonečně. Tohle platí stejně pro isset.

Zejména empty je v podstatě dvojitá podmínka, která se ovšem tváří navenek jako jedna, takže i když testy máte všechny empty volání pokryté, aplikace vám nakonec stejně nefunguje.

Tohle je spíše subjektivní záležitost, ale řekl bych, že nebudu sám. Kód s empty je sám o sobě čitelný, ale špatně se opravuje právě tam, kde bylo empty použité zbytečně. Zápis s empty se "tváří" jako běžná funkce a většina funkcí vrací TRUE když je všechno v pořádku a FALSE, když je to chyba. Ale u empty je to přesně naopak. Už se mi párkrát stalo, že if (empty($var)), jsem nahradil za if ($var), přitom správně je if (!$var)

Určitě se tedy vyplatí proměnné inicializovat, jak už několikrát poukazoval J. Vrána. Pak se výrazně redukuje použití empty i isset. Skoro bych řekl, že pokud je váš projekt prolezlý voláním empty, tak je něco špatně a měli by jste to změnit.

Osobně se pořád ještě uchyluji k tomu, že neinicializuji proměnné, které se použijí někde hluboko v zanoření nebo v cyklech

function getItems() {
  foreach () {
   if (.....) {
    foreach (....) {
      $items[] = $item;
    }
   }
 }
 
 return isset($items) ? $items : array();
}

Prostě proto, protože píši tak, jak se tvoří kód a neřeším nic zpětně. Zas za nějak extra velký problém to nepovažuji. Ale pokud se i v těchto případech provede inicializace před cyklem, je to určitě lepší.

Třída Presenter opravdu musí v současnosti implementovat metodu getPresenter, protože dědí od třídy Control. Najdete to dokonce i v dokumentaci o presenterech. Ale je to skutečně správně?

Třída Control představuje to, pro co se v dokumentaci a všude v diskusích okolo Nette používá slovo "komponenta", ve zkratce je to znovupoužitelná část zobrazené stránky. Právě tuto zobrazenou stránku představuje ve frameworku třída Presenter. Je tedy Presenter - zobrazená stránka - opravdu speciálním případem komponenty - své části - jak je to v současnosti? Presenter podle všeho potřebuje disponovat některými vlastnostmi komponent

• obsahovat různé množství jiných komponent, které mohou obsahovat další komponenty - stromová struktura a operace nad ní
• být vizuální - umět pracovat se šablonami a vykreslit se
• obsluhovat volání akcí představovaných signály (ale šlo by to i bez nich, viz. dále)

Naopak nepotřebuje, nebo by dokonce neměl mít, tyto vlastnosti komponent

• být obsahem jiné komponenty - představuje stránku, tedy nejvyšší kořen stromu komponent
• dohledávat nadřazený presenter (obecně svůj kořen) - pokud hledám sám sebe tak se mnou není něco v pořádku

Hlavním úkolem presenteru také není být skladem na komponenty (potažmo komponentou), jeho hlavní odpovědnost je odbavit daný požadavek. K té zmínce o signálech - presenter by obsluhovat signály nemusel, není k tomu důvod, tohle se může klidně přenechat pouze komponentám. Na druhé straně signály v preseterech zjednodušují odbavení některých - zejména nevizuálních - akcí.

Z výše uvedeného plyne, že Presenter nemá být potomkem komponenty, není jejím speciálním případem a výše uvedené společné vlastnosti má s komponentami sdílet jiným způsobem než prostřednictvím dědičnosti.

Dalším - možná trochu neočekávaným - důsledkem nevhodnosti dědičnosti presenterů od komponent je použití protected metod presenteru ve třídě Control. Takto to vypadá v metodě Control::createTemplate()

protected function createTemplate($class = NULL)
{
  $template = ...;
  $presenter = $this->getPresenter(FALSE);
 
  if ($presenter instanceof Presenter) {
    ...
    $template->netteHttpResponse = $presenter->getHttpResponse();
  }
 
  ...
}

Problematická je metoda Presenter::getHttpResponse(). Tato metoda je totiž ve třídě Presenter - potomkovi Control - definována jako protected. Ve třídě Control je možné ji zavolat, protože PHP samotné umožňuje volat protected metody potomka v předkovi.

Problém je v tom, že ve svých aplikacích dědíte své komponenty právě od třídy Control. V těchto vašich komponentách však už Presenter::getHttpResponse() nezavoláte, protože Presenter není potomkem vašich komponent.

Těžko říci, kolik toho v tomto případě jde na vrub výše zmíněné vlastnosti PHP. Jisté ale je, že pokud by Presenter nebyl potomkem Control, jeho metody volané ze třídy Control by nikdy jako protected nevznikly, musely by být public. Jako řešení je proto nutné protected metody třídy Presenter používané ve svých komponentách učinit ve svých presenterech jako public, případně si udělat drobný patch do frameworku, který se dá přežít.

Komponentový model popsaný výše je v Nette od jeho počátku a jeho změna je radikálním krokem, který znamená přepsat základy frameworku. Uvidíme, zda se tak někdy stane. Je pravda, že nějaké zásadní obtíže, které by se nedaly řešit, současné uspořádání nepřináší, takže se nemyslím, že k tomu v dohledné budoucnosti dojde. Na konci zmíněný problém s viditelností některých protected metod presenteru v komponentách je jednoduše řešitelný (změnou na public) i bez zásahu do komponentového modelu.

Abych jen nevytahoval nedostatky, je nutné zmínit, že ve verzi 2 Nette ušlo oproti předchozí verzi 0.9 pořádný kus dopředu zejména v oblasti DI a dokumentace se také podstatně vylepšila, upgrade se určitě vyplatí.

V oblasti těžby ropy a zásob obecně se nic moc nezměnilo. Jasně se ukázalo, jak strategickou surovinou je ropa zejména v souvislosti s problémy v Libyi. Libye ač malý, přesto poměrně důležitý producent velmi kvalitní ropy se stal centrem zájmu USA a zejména evropských zemí. Politické a sociální důvody uváděné jako důvod ozbrojené intervence jsou zejména u evropských států jasnou přetvářkou, protože mnohem horší a krvavější diktatura v Sýrii jim stojí maximálně za vydání rezoluce a "vyjádření znepokojení" nad chováním Syrského režimu.

V souvislosti s výpadkem produkce v Libyi se také ukázalo, že se zásobami Saudské Arábie, které jsou "krví" celé západní civilizace to může být všelijaké. Žádné zásadní navýšení produkce se po výpadcích v Libyi nekonalo. Je proto velkou otázkou, jak se produkce SA bude chovat v dalších měsících a letech. Pokud by došlo k nějakému propadu signalizujícímu peak oil v Saudské Arábii, tak by se konec dnešní západní civilizace velmi přiblížil a tyto signály už se začínají objevovat

V posledních měsících bylo vidět poměrně velké haló ohledně břidlicového plynu, který podle mnohých skrývá novou energetickou spásu a nezávislost zejména pro USA, ale i pro další země. Je to nesmysl a jen další masáž masmédií, která má zakrýt hloubku problému s energií, který dnešní civilizace neumí řešit. Břidlicový plyn je nadějí, že dopady peak oil by nemusely být tak tragické a přináší další možnosti v substituci ropy, ale určitě nepřináší žádné definitivní řešení konce éry levné energie.

Ekonomické problémy tento rok zejména v Evropě udeřily v plné síle. Nejen že se žádné ekonomické oživení nekoná, ale naopak balancujeme na kraji rozpadu Eurozóny, krachu bankovního sektory, a jiných naprosto katastrofálních scénářů. A to prosím jen 3 roky po recesi v roce 2008. Přijatá opatření nemají účinnost a dnes už snad nikdo nehovoří o tom, že v dalších letech bude po ekonomické stránce lépe. Platí to samozřejmě i pro naši zem. Zvýšení DPH a stagnace mezd povede k útlumu poptávky, krachům firem a zvyšování nezaměstnanosti. Jestli se pak ještě přidá škrcení sociálního státu, omezování počtu policistů, tak se připravme na zvyšování kriminality a násilí na ulicích.

Nejhorší je, že není vůbec jisté, co se vlastně v Evropě stane. To je pro nás jako exportní ekonomiku zejména ve vztahu k Německu zásadní. Krachy Eura by vyústily v problémy v bankách, deflaci a pokud by se bankovní sektor zhroutil o úspory přijdeme, pojištění nepojištění. Pokud ECB začne se záchrannými plány, nastoupí zvyšující se inflace, která úspory znehodnotí. Ani jedna perspektiva není dobrá.

Příchod klimatické změny je jistotou, známé jsou i velmi negativní důsledky, které ji budou provázet. Bohužel aktuální situace ve světě nepřeje vůbec tomu, aby jsme jako lidstvo mohli negativnímu působení klimatických změn čelit, zejména snižováním emisí, podporou šetrných technologií, změnám krajiny atd. Dopady změn v podobě záplav, sucha, neúrody, nedostatku potravin, obrovských migrací, budou proto velmi tvrdé a bohužel dopadnou nejvíce na ty nejchudší obyvatele planety.

Energetické a ekonomické problémy spolu do velké míry souvisí a působí spolu negativně na celou společnost. Důsledky působení těchto sil na kapitalistickou společnost vyúsťují v omezování sociálního státu, principů solidarity a zvyšují míru sociální nerovnosti. V situaci, kdy se svět blíží svým energetickým limitům, se začínají projevovat limity růstu a bez růstu není možná existence kapitalistických demokratických států tak jak je dnes známe. Změna tak bude muset dříve či později přijít. Od současných vlád a státní moci to nebude, ty jsou závislé na nadnárodním kapitálu a prorostlé korupcí a budou se jakékoli změně bránit co to dá.

Jedinou nadějí je podle mne změna k nějakým udržitelným společenstvím, která budou žít na zcela jiných principech, než co jsme zatím poznali. Tato nová společnost musí úplně redefinovat vztah člověka k zemi, přírodě a všemu živému. A to podotýkám, že nejsem žádný ekolog. Dosavadní život člověka od pravěku - kultura lidského společenství - není nic jiného než neustálý boj s přírodou, který nelze nikdy vyhrát, vždy musí skončit katastrofou. Žádná forma lidského společenství toto nezměnila ať už feudálně diktátorská, kapitalistická, komunistická a nakonec demokraticko kapitalistická. Potřebujeme poznat a pochopit vznik a průběh dosavadního konfliktu lidské kultury s přírodou a nastavit jiný řád, život lidského společenství musíme podřídit prosperitě biosféry. V této společnosti je pak možné udržet obyvatelnost Země a vstoupit do věku dospělosti a odpovědnosti.

Poslední věty jsem převzal z článku J. Šmajse, který doporučuji každému k přečtení. Nezbývá než jen doufat, že se lidé pokusí poznat svou podstatu a změnit své chování co nejdříve, čas se krátí.