phpFashion

Vyplatí se jít na školení Jakuba Vrány?

Prapůvodně měl být na tomto místě ohlas na školení Jakuba Vrány Konfigurace a výkonnost MySQL. Chtěl jsem psát o tom, že ačkoliv mě Jakub dopředu varoval, že téma konfigurace MySQL není gór moc kůl, obavy se ukázaly jako liché, neboť prakticky každou vlastnost demonstroval na živých příkladech a tím držel posluchače ve střehu. Jako skvělý prezentační nástroj se přitom ukázal Adminer. Až jsem měl pocit, že si ho vyrobil speciálně k tomu účelu, protože s phpMyAdminem by tak ladně demonstrovat některé rysy MySQL nešlo. No a pak tu mám několik drobností, které bych školení vytkl, nicméně…

…Nicméně hlubší rozbor tohoto konkrétního školení vynechám. Jednak proto, že ho Jakub aktuálně nenabízí. (Přesněji řečeno nabízí řadu jiných školení a máte poslední šanci se na ně přihlásit, první z nich je totiž už zítra). A také proto, že více čtenářů bude zajímat odpověď na úvodní otázku.

Začnu obecně: aby pro vás školení mělo přínos, musí dojít k určité konjunkci hvězd:

• přednášející musí tématu výborně rozumět
• přednášející musí umět školit
• přednášející musí mít školení dobře připravené
• a vy si musíte vybrat správný kurz (a ptát se)

Že neříkám nic objevného? Kéž by. Divili byste se, kolik firem posílá lidi na školení k pánům nikdy-jste-o-mně-neslyšeli, jsem-o-kapitolu-před-vámi nebo říkají-mi-uspavač-hadů. Není lepší jít na doopravdické školení? Obzvlášť pikantní je, když se na takovém doopravdickém školení objeví osoba ze známé-školící-firmy, aby se to naučila, bo za týden to sama školí 🙂

Jak je na tom Jakub Vrána, jsou jeho školení doopravická? Nepopiratelně je významná osobnost PHP scény, jeho jméno najdete dokonce v dokumentaci. Navíc disponuje schopností přednášet, jeho výklad je srozumitelný a působí přirozeně. A když jsem z něj ve svých školitelských začátcích mámil know-how, shodli jsme se na tom, že jednomu kurzu věnujeme téměř rok příprav. Splňuje tedy všechny tři body. Čtvrtý už je na vás. Když ho splníte, tak vězte, že se školení rozhodně vyplatí.

Při psaní tohoto článku zemřelo jen zanedbatelné množství zvířat a žádný Davídek nebyl podplacen.

Jak funguje zálohování disků „za chodu“

Na zálohování jsem si pořídil úžasný prográmek Drive SnapShot. Umí zálohovat celé disky, má pouhých 160kB a funguje nejen pod Windows , ale i pod DOS. Což se náramně hodí, pokud potřebujeme obnovit zhroucené Windows. A hlavně: umí provádět rozdílové zálohování, archívy šifrovat (AES, 128bit) a poté je mountovat jako další disk! Vřele doporučuji vyzkoušet.

Tento prográmek (stejně jako jemu podobné: Norton Ghost, Acronis True Image) dokáže uložit přesný obraz disku, jaký existoval v okamžiku spuštění. Vždycky mě ale zajímalo, jak zálohování on-fly vlastně funguje. Vždyť celá operace nějakou chvíli trvá. Od minut až po hodiny. Přesto program vytvoří přesný obraz disku, ať už s ním během zálohování dělám cokoliv. Jak je to možné?

Vše se točí kolem vyspělých operačních systémů na bázi NT. Tedy třeba Windows Vista, nikoliv však zastaralých 95/98. Při spuštění zálohování přikáže aplikace operačnímu systému, aby uložil všechna data, která si drží v paměti, na disk. Poté se napojí na diskový ovladač, aby mohla monitorovat každý přístup na disk. A zahájí kopírování pěkně sektor za sektorem.

Jakmile se objeví požadavek na zápis na disk, a to v místě, které ještě nebylo zálohované, tak tento sektor přednostně zazálohuje a pak teprve zápis povolí.

V tom je celý trik. Jakmile odstartujeme zálohování, můžeme na disku jakkoliv řádit, instalovat či mazat programy, chytit virus. Záloha bude vždy obsahovat konzistentní podobu disku v okamžiku spuštění. Chytré, co?

Proč opustit Subversion (SVN)

Řada projektů opouští populární verzovací systém Subversion a přechází na jiný. Jaké jsou důvody?

K používání Subversion (SVN) mě přiměl kdosi v počátcích vývoje Texy. Do té doby jsem „verzoval“ archivováním složky s kódem do RARu před každým větším zásahem. A něco sofistikovanějšího by bodlo. Veřejnému repositáři jsem odolával, protože mi připadalo, jako by mi někdo koukal při programování pod prsty. Zkusil jsem proto lokální SVN server s už tehdy skvělým GUI TortoiseSVN a rychle si na nový styl práce zvykl.

Teprve mnohem později jsem začal používat veřejné SVN. Pokud si odmyslím nezpochybnitelné komunitní výhody, jako je spolupráce více vývojářů a přidaný rozměr pro chápání kódu (čas), nepřineslo to z hlediska jednotlivce nic pozitivního. Nešlo pracovat offline, dříve okamžité operace trvaly dlouhé sekundy. Jakákoliv chyba byla navždy zvěčněna v historii repositáře. Zjistil jsem, že během vývoje dílčích částí zase verzuji RARem a Subversion mi přestal pomáhat.

Oči mi otevřel až Karmi, když mi ukázal, že kromě centralizovaných repositářů, jako je SVN, existují i distribuované (DVCS), které všechny zmíněné problémy řeší. Jsou umístěny lokálně s celou historií, takže nepotřebují internet a reagují bleskově. Lze v nich zkušebně rozvíjet několik vývojových cest. Ty slepé smažete, správnou pustíte na „centrální“ repositář. Úžasné! A tím výčet výhod nekončí.

Přejít na distribuovaný verzovací systém mi vyplynulo jako nutnost.

Jaký distribuovaný systém zvolit?

Karmi propaguje Git, který současné úložiště mých projektů Google Code nepodporuje. Nabízí však alternativu v podobě systému Mercurial (HG). Kromě těchto dvou je ještě slyšet o Bazaar. Který z nich zvolit? Jak se liší?

Pustil jsem se do důkladné rešerše a zjistil, že dobrat se odpovědi není vůbec snadné. Protože Subversion ve prospěch distribuovaných systémů opouští čím dál více projektů (jen PHP nyní slavně přešlo na SVN, hehehe), narazil jsem na tyto analýzy:

• Chosing a distributed VCS for the Python
• Analysis of Git and Mercurial by Google

Z obou je cítit bezradnost a ačkoliv volba padla na Mercurial, důvody nesouvisí s objektivní kvalitou systémů. Navíc za poslední půl rok se hodně změnilo a zmíněná absence GUI pro Windows v případě Gitu je dnes naopak jeho předností (tj. už má skvělé GUI).

Z dalších úvah jsem vyřadil nejmladší a nejméně populární Bazaar a podíval se zblízka na Git s Mercurialem.

Git

• obrovský a komplexní projekt (možná až zmatený a nesrozumitelný)
• umožňuje zasahovat do historie, mazat slepé větve
• domovem je mu Linux, na Windows to není úplně ono
• napsaný v C a shell skriptech
• import i export SVN včetně historie
• hosting: Github.com (mnohem lepší než Google Code)
• GUI nástroj: TortoiseGit (vypadá přesně jako TortoiseSVN) a GIT Cheetah
• dokumentace (český překlad, začátečníkům nesrozumitelná)
• cheat sheet

Mercurial

• malý a chytrý (ovládáním podobný SVN)
• nelze zasahovat do historie
• výborně funguje na všech platformách
• napsaný především v Pythonu
• import SVN včetně historie
• hosting: Bitbucket.org (mnohem lepší než Google Code)
• GUI nástroj: TortoiseHg (jen se vzdáleně blíží TortoiseSVN)
• dokumentace (anglická, ale čtivá a srozumitelná)
• cheat sheet

Na rozpacích

Od začátku mi byl sympatičtější Mercurial, protože mám raději malé, šikovné a promyšlené věci, než molochy (nejen ve frameworcích). Lépe funguje na Windows (import SVN repositáře je 70× rychlejší než na Git). Podporuje jej Google Code.

Jenže svět je složitější. Příklad: Mercurial má srozumitelnější příkazovou řádku, podobnou té v SVN. Jenže stejně ho budu ovládat pomocí GUI. Tam naopak (dnes) vede TortoiseGit, který jako by z oka vypadl TortoiseSVN, zatímco TortoiseHg je hodně jiný a slabší. Ale tím, že je jiný, umožňuje commitovat tzv. hunks. Což se mi skutečně často hodí. Nicméně s distribuovaným repositářem přichází jiný styl práce – budu i poté potřeboval hunks?

Mercurial čísluje revize, Git používá 40 místný hash. Preferuju samozřejmě číslo, ale není to jen pozůstatek SVN uvažování?

A tak by se dalo pokračovat dále. Nejsem zatím schopen říct, který ze systémů více vyhovuje mým potřebám. Jediná možnost je oběma věnovat několik dní času a zkusit s nimi pracovat. Co však můžu říct s naprostou jistotou je, že SVN chci opustit.

Jak penetrují mladí chlapci?

Mladí chlapci se musejí vymezovat proti autoritám. Mají to v popisu práce. V diskusi neváhají nedostatek zkušeností nahradit sebejistotou a drzostí. Fakt hloupé to začíná být ve chvíli, kdy vlastně jen nahrazují.

Marian Koubala alias Emco se poměrně ostře pustil do Jakuba Vrány pod článkem o bezpečnostním auditu serveru Na volné noze. Na věci je pikantní, že Marian Koubala je Jakubův konkurent, neboť provozuje službu komerčně nabízející bezpečnostní audity webových aplikací.

Obdivuju Jakuba, s jakou trpělivostí se nechal penetrovat mladistvým script kiddie, já bych ho asi smazal hned v zárodku. Jakub je v tomto směru až hyperkorektní a jsem přesvědčen, že si tak poškozuje své jméno. Když totiž diskusi přečte neodborník, nemusí mu být úplně zřejmé, kdo je tady vlastně za diletanta. Čtenář potřebuje vodítko a proto vznikl tento článek.

Takže vězte: Marian Koubala alias Emco je úplně mimo. Patří do sorty tzv. „bezpečnostních odborníků“, kteří tohoto sice hodně načetli, jenže při čtení vůbec nepřemýšleli. Vědí o spoustě útoků, ale nemají páru o technickém pozadí a neví, jak jim skutečně čelit. Na argumenty nejsou schopni reagovat jinak, než odkazováním na (dle jejich názoru) autoritativní zdroje, tedy v tom lepším případě, v tom horším se uchylují k osobním útokům. Dokážou však udělat výborný první dojem a ohromit množstvím znalostí. Že jsou jejich rady kontraproduktivní, se nemusí hned zjistit.

Emco script

Ale zpět k diskusi. Emco upozorňuje na útok upload null byte, který prý souvisí s nastavením direktivy magic_quotes_gpc a prý znemožňuje kontrolu nahraného obrázku na základě jeho přípony. Diskuse poté kráčí ve výše popsaných šlépějích, takže o upload null byte útoku nebo direktivě magic_quotes_gpc se od něj nedozvíme vůbec nic, zato se dočteme, že Jakub je blázen, stahovačný (sic!), líný hlupák a tak vůbec ;)

V jedné chvíli však Emco neprozřetelně utrousí moudra a podělí se o kus PHP kódu. Ten by měl demostrovat zmíněný null byte útok, vtipné však je, že prakticky na každém řádku je nějaká chyba. Od méně závažných po naprosto fatální bezpečnostní díru:

if (strtolower(substr($HTTP_POST_FILES['obrazek']['name'], -4, 4)) == ".jpg") {
	$path= "upload/".urldecode($HTTP_POST_FILES['obrazek']['name']);
	if($ufile != none) {
		if(move_uploaded_file($HTTP_POST_FILES['obrazek']['tmp_name'], $path))
			echo "Obrazek byl uspesne nahran na server";
		else
			echo "Obrazek se nepodarilo nahrat na server";
	}
} else
	echo "Neplatny format obrazku";

Jen bodově:

• pole $HTTP_POST_FILES bylo zavrženo už v roce 2001, jeho použití mě docela překvapilo
• neověřuje existenci prvku $HTTP_POST_FILES['obrazek']['name'] a může tak generovat neošetřené E_NOTICE
• neověřuje, že prvek $HTTP_POST_FILES['obrazek']['name'] je řetězec a může tak generovat neošetřené E_NOTICE (viz <input type="file" name="obrazek[]">)
• urldecode() nemá v kódu co dělat. Pokud budete uploadovat soubor nazvaný třeba 70%absinth.jpg, na straně serveru byste dostali 70«sinth.jpg
• urldecode() je místo, kde se zcela uměle vytváří díra „upload null byte“
• podmínka if($ufile != none) pracuje s nedefinovanou proměnnou $ufile a nedefinovanou konstantou none
• kód neřeší situaci, kdy $ufile == none, ať už je tím myšleno cokoliv
• ke složce upload přistupuje relativně, takže se může chovat velmi nepředvídatelně
• ale hlavně: dovoluje přepsat jakýkoliv jpg na webovém serveru, tedy i mimo adresář pro upload! (např. %2e%2e%2fobr.jpg)
• kvůli uměle vytvořené „upload null byte“ díře dovoluje přepsat jakýkoliv soubor na webu (např. .htaccess%00.jpg)

Všechny tři řádky obsahující konstrukci echo se zdají být bez problému. Gratulujeme!

Na závěr bych Marianovi vzkázal jeho vlastní slova: chtel bych videt hlupaky, co ti za to tvoje bezpecnostni skoleni plati bezmala 5 000,– Kc. venuj se dal php a neprodavej lidem falesny pocit bezpeci v podobe amaterskych bezpecnostnich auditu… A firmám, které uvádí ve svých referencích doporučuji, aby si nechaly udělat audit také jinde.

Kosmetické HTML

V některých rodinách panuje zvyk před odjezdem na dovolenou celý byt vygruntovat. Proč? To kdyby se k nim vloupal zloděj, aby si nepomyslel něco špatného. Do stejného pytle patří kodéři puntičkářsky dbající na vzhled HTML kódu jejich stránek. To aby se jejich kód snáze vykrádal, aby je lepič na Webtrhu nepomluvil.

Sám jsem děsný perfekcionista. Takže mě žralo, že hezky naformátovaná PHP šablona:

<?php
$items = array('user', 'see', 'too');
?>

<ul>
<?php foreach ($items as $item): ?>
	<li><?php echo htmlSpecialChars($item) ?>
<?php endforeach ?>
</ul>

generuje ošklivý HTML kód:

<ul>
	<li>user	<li>see	<li>too</ul>

Jak už asi víte, v Nette Framework lze ekvivalentní šablonu zapsat pomocí přehlednějšího Curly Brackets filtru:

<ul>
{foreach $items as $item}
	<li>{$item}
{/foreach}
</ul>

Filtr má v sobě zabudovanou kosmetickou drobnost – podle určité heuristiky se snaží učinit perfekcionistické duši za dost. A vygeneruje tento výstup:

<ul>
	<li>user
	<li>see
	<li>too
</ul>

Já vím, pro mnohé z vás je to detail, ale pro nás chronické puntičkáře zásadní feature ;)

p.s. jsou situace, kdy jde o velmi praktickou vlastnost, pokud třeba generujete plain text nebo Texy kód, kde na formátování a správném odřádkování hodně záleží

p.s.s. tahle feature má nulový vliv na rychlost generování stránky

Hackeři vám zaútočí na web

Co chvíli je hlášena bezpečnostní díra na dalším významném webu (Alza, Mapy.cz, BontonLand). Nebo je díry zneužito. Zkuste si vyhledat slova XSS zranitelnost a pochopíte, proč je Cross Site Scripting (XSS) dnes jednou z nejrozšířenějších a nejnebezpečnějších děr.

Záležitost nepříjemná pro provozovatele webů a snad ještě víc pro dodavatele. Může poškodit jméno, může dojít na pokuty, žaloby, nebo jen pokazí vztah s klientem. Jak se proti XSS bránit? Tzv. escapováním řetězců. Bohužel naprostá většina odborníků v tom plave. (Nechci být netaktní a někoho se dotknout, snad jen řeknu, že z „československých IT celebrit“ znám asi jen jednoho člověka, který se ve věci do hloubky vyzná.) Tudíž i články o této problematice na známých webech jsou, řekněme, nepřesné.

Navíc ono escapování se obvykle provádí v šabloně, padá tak na bedra kodéra. Tedy nejkritičtější místo vyžadující vysokou erudici řeší člověk nepovolaný. Jak taková věc může dopadnout? To přece víme – viz první odstavec.

Spasí vás Nette Framework

Rád bych vám představil jednu killer feature šablonovacího systému Latte v Nette Framework. Vlastnost tak zásadní, že sama o sobě je důvodem framework zvolit. Nebo klidně z něj použít jen šablony.

• čím jste větší firma, tím je pro vás vlastnost důležitější
• žádný konkurenční framework ji dodnes nemá ¹⁾

Nette Framework v šablonách escapuje automaticky. Jeho vlastnost Context-aware escaping rozezná, ve které části dokumentu se nacházíte a podle toho zvolí správné escapování.

Teď zabrousím do techničtější roviny. Jak to funguje, nejlépe uvidíte na příkladu. Mějme proměnnou $var a tuto šablonu:

<p onclick="alert({$var})">{$var}</p>

<script>
document.title = {$var};
</script>

Zápis {$var} znamená vypsání proměnné. Jenže každé vypsání je nutné ještě explicitně ošetřit, dokonce na každém místě jinak. Kodér musí (například ve Smarty) připsat příslušné modifikátory, nesmí se přitom splést a hlavně nic opomenout.

V Nette Framework není potřeba nic ošetřovat. Vše se udělá automaticky, správně a důsledně!

Pokud dosadíme do proměnné $var = 'Šířka 1/2"', framework vygeneruje HTML kód:

<p onclick="alert(&quot;Šířka 1\/2\&quot;&quot;)">Šířka 1/2&quot;</p>

<script>
document.title = "Šířka 1\/2\"";
</script>

Samozřejmě je myšleno i na situaci, když je potřeba vypsat proměnnou bez ošetření, například proto, že obsahuje text článku včetně HTML značek. V takovém případě se použije zápis {$var|noescape}.

Konec technické odbočky. Díky Latte najednou platí, že

• podoba šablony zůstala jednoduchá
• vy se nemusíte bát, že kodér někde něco opomene
• a zároveň v něm nepotřebujete mít top odborníka na escapování ;)
• práce jde mnohem snáze

Další informace o chytrých šablonách Latte najdete v dokumentaci.

Konečně je tu PHP 5.3

Přichází trošku jako opozdilec, pro kterého včera večer byla přichystána velkolepá oslava, ale dnes už se hosté rozešli domů. Před rokem a půl byl internet plný článků o klíčových novinkách v PHP 5.3, po neustálém odkládání termínů a méně příjemných změnách nadšení vychladlo.

5 – 4 – 3 – 2 – 1 DOWNLOAD!

Jaké jsou novinky? Podstatné. Vezmu to podle důležitosti:

• podpora jmenných prostorů, oddělovačem je zpětné lomítko (Nette\Web\Html)
• late static binding, statické metody konečně ví, nad kterou třídou jsou volány
• lambda funkce a uzávěry (nakonec bez podpory $this), metoda __invoke
• overloading pro statické metody via __callStatic()
• vylepšený garbage collection, který si poradí s cyklickými referencemi
• výjimky mohou odkazovat na předchůdce, getPrevious()
• nativní driver pro komunikaci MySQL a PHP (z pohledu programátora se API nemění)
• nová rozšíření ext/sqlite3, ext/phar (článek), ext/intl, ext/fileinfo, ext/enchant
• rozšíření syntaxe o zkrácený ternární operátor ?:, NOWDOC a goto (ajáj)
• magická konstanta __DIR__ nahrazující mantru dirname(__FILE__)
• obrovská řada drobných změn u stávajících funkcí (velmi podrobně u Jakuba)
• rozšířeny schopnosti parseru php.ini (ale omezena flexibilita INI parseru jako takového)
• odstraněn zend.ze1_compatibility_mode

To klíčové přijde v následujících týdnech: jak rychle se PHP 5.3 rozšíří? Vzhledem k tomu, že bylo vyvíjeno jako přirozený nástupce řady 5.2 bez zpětně nekompatibilních změn, šance na brzké rozšíření rozhodně má. Nicméně si myslím, že hostéři budou čekat, až vyjde následující setinková verze. Jako když se u Windows čekává na první service pack.

Historie jim přitom dává za pravdu:

• PHP 5.0.0, které vyšlo s rozdílem 14 dní právě před pěti lety, bylo použitelné cca od verze 5.0.3.
• PHP 5.1.0 existovalo pouhé 4 dny a bylo nahrazeno 5.1.1, za dva týdny 5.1.2.
• PHP 5.2.0 bylo opět případem zabugované verze, kde smutnou roli sehrál Debian.

(Totiž Debian Etch má tuto verzi předinstalovanou a nepochopitelný konzervatismus správců vede k tomu, že odmítají PHP updatovat, bo „jen to, co je v Debianu, je stabilní.“)

Přeji PHP 5.3 rychlý a úspěšný nástup do světa!

Kuk na screencast

Potěším všechny začátečníky, kteří se chtějí seznámit s Nette Frameworkem. Odedneška je to mnohem snazší. Máme pro vás totiž profesionální screencast. Tedy výukové video, kde sledujete obrazovku počítače a posloucháte lektora, který vás naučí prvním krokům s frameworkem. Jde o první počin z plánované série screencastů.

Přeji vám dobrý obraz a ostrý zvuk!

• Screencast: Stáhnutí a zprovoznění Nette Framework

Ze zákulisí

Málokdo si umí představit, že za těmi 10 minutami videa se skrývají dlouhé desítky hodin práce a výzkumu. Snoubí se tu totiž celá řada disciplín, po pedagogické stránce je potřeba vést diváka od jednoduchého ke složitému a nesklouznout mimo trasu, po vizuální stránce je potřeba zaujmout, po technické stránce musíte správně zvolit a nastavit video kodek nebo vyčistit zvuk. Musím proto moc poděkovat Tomáši Vítkovi, že vytrval točit klikou a screencast dotáhl až do současné podoby. Věci, které zbývá doladit, už lze považovat za technické detaily.

A ještě zbývá přidat intro ;)

2. Nejlepší software roku: Nette Framework

Verdikt odborné poroty: Nette Framework je 2. nejlepší software roku 2009!

Nette Framework existuje ve světě open source teprve rok. Loni jej znalo jen pár zainteresovaných lidí. Je proto úžasné, jakého umístění se mu na COS 2009 dostalo. Vážím si toho a porotcům i hlasujícím velmi děkuji!

(Mimochodem, víte na jakém frameworku dnes běží server Root.cz? Ano, přesně na tom!)

Umístění je jistě motivací pro celou komunitu. Je přece fajn se podílet na jednom z nej… projektů. A zároveň skýtá výzvu příští rok výsledek ještě překonat ;) Pokusíme se o to, máme totiž velkou spoustu nápadů a plánů, jak samotný framework i jeho web vylepšit. Rozhodně se máte na co těšit!

Docela šokující čísla, že?

Zajímá vás, kolik vývojářů skutečně stojí za slavými projekty, bez marketingového mlžení? Pokusím se vyvrátit jeden mýtus, který někdy zaznívá proti Nette Framework, ale je docela možné, že vás tím připravím o iluze. Čtěte proto jen na vlastní nebezpečí 🙂

O jaký jde mýtus? Pod Jakubovým článkem o vývoji open source projektů padl komentář:

Přesně tohle (tj. velmi malý počet vývojářů) je důvod proč dělám v Zendu a ne v Nette. Nette je skvělé protože ho dělá David. Jakmile s tím přestane, tak půjde do kytek i kdyby mělo komunitu sebelepší.

Musím oponovat: projekt může zakladatele přežít vlastně jen tehdy, pokud sebelepší komunitu má. Nette Framework je svou komunitou už pověstný. Dovolím si zopakovat slova z minulého článku: podívejte se na české fórum, kde jsou desetitisíce příspěvků. Žádný jiný webový framework u nás tak aktivní a početnou komunitu nemá.

Ale vraťme se k počtu klíčových vývojářů u jednotlivých projektů. Obvyklá představa, že za každým významným projektem stojí početný tým vzájemně nahraditelných vývojářů, začala brát za své, když před dvěma lety vyšla zpráva, že projekt Thunderbird opouštějí oba hlavní vývojáři. Ano, zarážející je už to slůvko „oba“. Odchod pouhých dvou vývojářů Scotta MacGregora a Davida Bienvenu způsobil, že nad celým projektem se začala stahovat mračna.

Dejme to do souvislosti se zajímavými čísly, které nabízí server Ohloh. O projektu Thunderbird mi prozradil, že má úctyhodných 24073 commitů (commit je jeden příspěvek do kódu od jedné osoby). Přičemž na ty dva zmíněné vývojáře připadá 30 % commitů:

Opakuji: celých 30 % vývoje Thunderbirdu obstarali dva programátoři, jejichž odchod může být pro projekt smrtelný.

Nebudu chodit kolem horké kaše a podívám se stejnou metodikou na zoubek Zend Framework. Na obří framework, či spíše knihovnu, za jehož popularitou stojí jméno společnosti Zend a pro nějž hovoří „stovky vývojářů“ + několik „placených“. Nechme promluvit čísla:

Ano, 52 % frameworku je práce čtyř lidí. A pozor: na 2 hlavní vývojáře připadá 32 % frameworku, tedy situace je ještě malinko „dramatičtější“ než v případě Thunderbirdu. Přesto nepochybuji, že pokud ty dva vývojáře srazí tramvaj (nebo šalina), vývoj frameworku by sice na nějakou dobu ustrnul, ale bude pokračovat dál.

Zend Framework přitom patří ještě mezi ty méně ohrožené projekty. Co třeba slavné Ruby on Rails? Na grafu vidíte poměr commitů dvou hlavních vývojářů:

Pouhým dvěma vývojářům patří majorita. A ptám se: je snad Ruby on Rails odmítané proto, že by mohla Davida Heinemeiera Hanssona srazit šalina? Nebo naopak se bere jeho vize a pevné uchopení projektu jako výhoda? A obává se někdo, že ti dva nejsou placení vývojáři?

Když už brousíme mimo PHP, podívejme se na nejslavnější framework pro Python – Django:

O čtyři procenta víc než v předchozím případě. Bez dalšího komentáře.

Tak zpět do PHP luhů a hájů. Kromě Zend Framework a Nette Framewok se u nás těší největší popularitě asi CakePHP. Podle statistik jde o dílo tří hlavních vývojářů:

Ještě bych měl zmínit PRADO, kde téměř kompletní vývoj má pod palcem dvojice programátorů:

Z uvedených příkladů jde rozhodně o nejvyšší hodnoty. V tomto případě bych si už netroufl paušálně tvrdit, že by projekt pokračoval navzdory odchodu dvou vývojářů pod tramvaj – musel bych nejprve dobře znát komunitu kolem PRADO.

Ale ať skončíme pozitivně. Nakonec jsem si nechal projekt, který rozložením sil vychází jednoznačně nejlépe a tím je Symfony:

Nicméně i zde existuje dominantní jedinec, vůdce stáda, který převažuje nad ostatními.

Je vážně tak zle?

Ale vůbec ne! Pochopte prosím, že mým cílem nebylo vás strašit, ale pouze uvést do reality a demaskovat marketingové pozlátko. Raději zdůrazním, že

• jednotlivá čísla vůbec nic nevypovídají o kvalitách projektů
• nelze je použít ani jako vodítko při rozhodování

Naopak je přirozené a logické, že všechny projekty jsou dílem několika málo osobností. Tak je to na světě zařízené. A naopak, čím více lidí má právo commitovat, tím více se do kódu dostane balastu. Jak se dokáže ten který projekt vyrovnat se ztrátou vůdčích osob je vždycky nejisté. V případě Nette Framework mě těší vědomí, že konečně po 5 letech vývoje mám naději, že by se vyrovnat dokázal.

Doplnění: Karmi mi v komentářích připomněl důležitou věc, kterou jsem v článku opomněl a způsobil tak nedorozumění. Článek odkrývá skutečnost, že za úspěšnými projekty stojí vždy jen pár nesnadno nahraditelných osobností (úkolem marketingu je vytvořit opačný dojem). Je ale potřeba dodat, že u dobře fungujících open source projektů se pozice těchto osobností v čase mění. Nejprve jsou to výhradní autoři a programátoři, aby se časem přesunuli do pozice těch, kteří projekt vedou a dávají mu vizi. A třeba úplně přestanou psát kód.