Odborná konference PHPCE 2017, která se konala na začátku listopadu v nádherném polském Ossa Congres & Spa centru, nás v mnohém velmi příjemně překvapila a obohatila o nové poznatky v oblasti programování.
1. Přednáška Nikola Poša: Journey through "unhappy path" - Dealing with exceptional conditions
Zachytávání nečekaného chování určité aplikace dá i v současnosti zabrat nejednomu zkušenému programátorovi. Pro jednodušší odstraňování nečekaných situací je proto dobré znát několik nápomocných zásad, které nám přitom usnadní práci. Některé z nich si nyní představíme:
-
Do not accept or return null
Toto pravidlo nám říká, že nikdy nesmíme akceptovat ani vracet zpět hodnotu označenou jako null. Nezískáme z ní žádné relevantní údaje a pro pozdější odstraňování problémů tak představuje nepoužitelnou hodnotu.
-
Every module/component has to have its own exception
Každý modul či komponent by měl vracet vlastní typ chybového hlášení, což nám následně pomáhá lépe identifikovat zdroj problému i samotný problém. Zároveň platí, že ne vždy je vhodné zobrazovat dané chybové hlášení uživateli.
-
User marker interface
Pokud chceme, aby bylo možné poskytovat a zpracovávat extra data, je dobré používat rozšířené třídy výjimek (exceptions).
-
Encapsulate via named constructors
Pro vytváření specifických chybových hlášení zase můžeme používat jmenné konstruktory. Je to dobrý způsob, jak při stejné chybě vrátit stejný popis chyby s použitím co nejkratšího kódu. Zároveň nám to spojuje výjimku a logiku vytváření chybových hlášení do jednoho zdrojového kódu.
-
Save/provide extra content, Collect as much data as possible
Při každém chybovém hlášení je dobré, pokud dokážeme zaznamenat co největší množství relevantních údajů, které nám později umožní pohodlnější zpracovávání výstupního chybového hlášení a jednodušší identifikaci samotné příčiny chyby.
-
Create central error handler
Doporučujeme také používat centralizované error handler-y, jako jsou například následující:
- Whoops
- Booboo (už není aktivně vyvíjený)
- wecodein/error-handling
Uvedené error handler-y se dokážou pěkně postarat o korektní vypsání detailů chybového hlášení, naformátování výstupu chybového hlášení a a v poslední řadě i o jednodušší a pohodlnější odstraňování chyb.
2. Alain Schlesser: Uncommon (Ab) Uses of Composer
Z této neméně zajímavé přednášky jsme si odnesli množství relevantních informací, přičemž bychom chtěli upozornit zejména na následující zlepšováky. Composer lze označit za vysoce flexibilní nástroj určený pro správu různých balíčků. V současnosti ho už používá většina vývojářů. Jeho podstatou je správa závislostí mezi jednotlivými balíčky, vytváření optimalizovaných autoloader-ů a umožňuje i správu balíčků z decentralizovaných zdrojů. Composer však dovoluje použít i mnoho dalších rozšíření, které si přiblížíme níže:
Pomocí tohoto rozšíření lze po běhu composer-a aplikovat dodatečně definované patch-e. Platí přitom, že tyto musí být zadány ve formátu odkazu na *.diff soubor. Je výhodné ho použít, pokud potřebujete modifikovanou verzi balíčku, ale nechcete kvůli tomu vytvářet vlastní fork a vlastní balíček.
Výhodou uvedeného rozšíření je, že nám umožňuje definovat vlastní namespace pro instalované balíčky pomocí composera a tím pádem použít více verzí téhož balíčku.
-
Keep up to date
Keep up to date je nastavení pro composer, v rámci kterého lze pro určité balíčky vynutit při spuštění composer-a update. Využití je například pro udržování aktuální geolokační databáze.
Toto nastavení podporuje vytvoření tříd, které dokážou spravovat a sledovat git hook-y při každém spuštění composera.
Boilerplate představuje rozšíření, které nám i v BUXUSe umožňuje vytvářet nové balíčky z predefinovaných šablon - BUXUS moduly.
Composer nám v poslední řadě umožňuje používat svou funkcionalitu pomocí externího skriptu. Funguje to tak, že při spuštění externího skriptu jsou volány definované součásti composera.
Mezi vzděláváním jsme se samozřejmě i najíst něčeho museli - jedno autentické, prudce amatérské, mobilním telefonem fotografované foto našeho skvělého uičkářského týmu :-)
3. Holger Woltersdorf: Async PHP requests & reactive responses with php-fpm
Představme si nyní situace, že potřebujeme vygenerovat několik faktur pomocí PHP. Pokud chceme jen pár kusů, server s tím nemá žádný problém. Pokud bychom však potřebovali vygenerovat například 1.000 nebo 10.000 kusů, při této práci se už náš server celkem solidně zapotí. Co s tím dá dělat a jak zachránit server před potenciálním přetečením RAM nebo 100% vytížením? Na zrychlení zpracovávání requestů na serveru lze využít více způsobů, které jsou běžně dostupné i na internetu a patří mezi ně například pthreads, pcntl nebo Gearman.
- Pthreads je rozšíření určené pro PHP a používané pro běh multi-thread aplikací. Pthreads však běží v cli na serveru a není proto vhodné pro asynchronní zpracovávání.
- Pcntl je další z řešení, které by potenciálně přicházelo do úvahy, dostupné je však jen na ne-Unixových platformách.
- Gearman je na druhé straně služba na serveru, která dokáže spravovat paralelní zpracovávání procesů, díky čemuž lze dosáhnout vyššího výkonu a rychlejších odezev servera. Pro implementaci je zároveň potřeba mít další php knihovny, komplexnější infrastrukturu kódu a mnoho dalších nastavení na serveru. Z pohledu funkcionality je to dobrá volba, existují však i jiná řešení.
- PHP-FPM je služba na serveru, pomocí které lze spravovat skupiny procesů (tzv. pools) s různými nastaveními. Mezi mnohé výhody PHP-FPM patří například i cachování částí kompilovaného kódu, které lze sdílet mezi pooly, díky čemuž se odlehčuje paměť servera. Jedním z možných nastavení je dále množství poolů, což nám umožňuje zpracovávat přijaté požadavky současně a tím snížit zatížení servera. Jeho výhoda spočívá například i v tom, že jakmile už pool neobsluhuje žádný request, tento zanikne a tím v podstatě šetří paměť konkrétního servera.
Na internetu jsou již dostupné i různé PHP knihovny vhodné pro asynchronní zpracování pomocí PHP-FPM. Jednu z aktivně udržovaných knihoven lze najít na hollodotme/fast-cgi-client. Jejím autorem je mladý německý programátor Holger Woltersdorf. Pomocí tohoto rozhraní tak lze zpracovávat více požadavků současně a umožňuje i paralelní tříděné a netříděné zpracovávání requestů. Tříděné zpracovávání následně spočívá v tom, že najednou lze zpracovávat více requestů, které se končí vždy v pořadí, v jakém byly iniciovány. Netříděné zpracovávání procesů spočívá v tom, že nemusíme čekat na konec předchozího requestu v pořadí a requesty jsou zpracovávány v rámci nastavení php-fpm. Díky tomu lze dosáhnout rychlejší odezvy servera a celkového šetření systémových prostředků.
