foglcz's posterous

So this week was a blast.

Tak tahle věta asi nejlépe vystihuje týden, který jsem právě měl. Nadupaný, krátký, produktivní a všeobecně skvělý.

Read the rest of this post »

Tak jsem se dneska rozhodl, že pojedu na Nette Brain Cloud Beta.. Jakožto starý vlakový cestovatel jsem se rozhodl, že vyzkouším regiojet. A vyplynula z toho velmi zajímavá tapeta na twittru.

Read the rest of this post »

Málokdy říkám ne. Ale říct NE je umění, které vede ke spokojenému životu. Nemůžete fungovat jako slibotechna - resp. můžete, ale buď si poserete reputaci, nebo se z toho poserete sami. Jak by řekla moje srí lanská máma: Been there, done that.

Read the rest of this post »

Seriál jedeme k úspěchu je psaný z osobních zkušeností - situace zde popsané jsem buď zažil nebo prožívám, a při jejich řešení používám metody, na které jsem dostal doporučení od bohatších a úspěšnějších kolegů.

Read the rest of this post »

Sobota 12. listopadu 2011, 18:10
Článek, který měl dnes vyjít, byl původně o něčem úplně jiném. Události uplynulého týdne mne ale donutili napsat něco jiného, něco, co mi dává mnohem větší smysl.

Read the rest of this post »

Seriál jedeme k úspěchu je psaný z osobních zkušeností - situace zde popsané jsem buď zažil nebo prožívám, a při jejich řešení používám metody, na které jsem dostal doporučení od bohatších a úspěšnějších kolegů. Prvním krokem je změnit způsob myšlění, a dnes budu psát o tom, jak je důležité přijmout zodpovědnost za všechno co děláme - ale i to, co neděláme.

Read the rest of this post »

Seriál jedeme k úspěchu je psaný z osobních zkušeností - situace zde popsané jsem buď zažil nebo prožívám, a při jejich řešení používám metody, na které jsem dostal doporučení od bohatších a úspěšnějších kolegů. Prvním krokem na cestě k úspěchu je ale zjištění, že za naši současnou situaci si můžeme sami.

Read the rest of this post »

Za těch pár let co jsem spolupracoval s majiteli Venture Capital jsem se naučil pár věcí, které budu rozebírat dle nálady, postupně a obecně. Podnikání a úspěch v životě obecně (ne jen materiální) je založen na několika principech a radách, které jsem v životě dostal. Dnes se ale budu věnovat něčemu jinému, a sice tomu, co pro mě úspěch znamená a o čem to vlastně je.

Read the rest of this post »

Abstract
Momentálně dělám na projektu, jehož jméno ani koncept ze zřejmých důvodů ještě nemohu pustit do světa - říkejme mu pracovně GT. Koncept je veskrze jednoduchý. a přirovnejme to k autům. Člověk si závodně jezdí a chce veškeré své časy trackovat, včetně toho, kde jezdil, kdy jezdil atp. Pro realizaci tohoto všeho máme poměrně hodně objektů, které je potřeba ukládat - základním cílem projektu totiž je, aby uživatel měl své statistiky, kde uvidí v grafech jak se mu časy zlepšují, které okruhy má nejraději, které kombinace okruhů (resp. kdy jezdí do boxů atp.) preferuje a jak se postupně zlepšuje.

Předpokládaný počet uživatelů systému je v řádech desítek tisíc. Každý uživatel má jezdit třikrát do týdne. Kromě toho existuje nástavba pro učitele řidičů - každý učitel může najednou učit více řidičů, sledovat jejich statistiky a tak. Veškerá data, tedy každý závod na každém okruhu pro každého uživatele musí být ukládána a agregována do grafů a statistik.

Řešení č. 0: tabulky pro jednotlivé classes
Ačkoli se zdá tento postup jako nejjednodušší, počítejme chvilku. Máme 10.000 uživatelů, každý závodí 3x týdně, což je 30.000 řádků v tabulce závodů za týden. Za rok tedy nasbíráme 1 560 000 záznamů. Máme zkušenosti s dotazy, které probíhali (ano, optimalizovaně!) nad 300.000 záznamy a joinovali 4 tabulky. Databáze byla nechutně pomalá, situace, kdy dotaz trvá 2 i více vteřin nejsou neobvyklé. Řešení jsme tedy zavrhli jako nepoužitelné.

Řešení č. 1: ukládat objekty do BLOB-u
Data jsme stejně měli ve strukturovaných objektech, nebyl tedy důvod je neukládat serializované (__sleep & __wakeup, někde ISerializable) přímo do databáze s tím, že se lazy-loadují - tedy se z databáze načítají až ve chvíli, kdy je skutečně potřebujeme. ISerializable byl implementován v některých případech pro to, že jsme je ukládali v rámci json notace - její parsování je v php rychlejší než serializace, a my jsme koncentrováni na rychlost celého systému.

Problém 1: Při podědění Nette\FreezableObject a implementaci vlastní __sleep metody, nedojde ke správné serializaci parent objektu a tím pádem je po serializaci objekt "rozmrazen" - viz příslušný gist na githubu. Jedná se o vlastnost PHP, která je "samozřejmá" pro lidi, kteří s tímto přijdou do styku :-)

Problém 2: max_allowed_packet! Není problém ve velikosti BLOB-ů nebo případně longblob-ů, problém je s maximální velikostí paketu, který putuje mezi databází a phpkem. Objekty se nám tak nedostali do databáze celé - prostě proto, že se nevešly do packetu. Máme vlastní servery, nebyl by problém hodnotu zvýšit -- ale rád programuji na maximálně restriktované konfiguraci jak PHP tak databáze, abych měl jistotu, že vytvořené aplikace budou běhat všude. BLOB-y jsme proto zavrhli.

Řešení č. 2: Permanentní úložiště na disku
A tohle se zdálo být jako "to ono" co jsme hledali. Prostě data budeme ukládat na disk, když budou potřeba, lazy-loadnou pro ten daný request.

Jak vyřešit "safe" ukládání, konkurenční chování? Safe stream zněl jako odpověď. Dokud jsme nepotřebovali začít budovat index dat dle tagů (v daném případě jsme měli 3 cesty, jak se k datům dostat) - tabulka v databázi, která by toto řešila, se nám příliš nelíbila (viz řešení #0), zkoumali jsme proto, co všechno můžeme použít. A hledání jsme ukončili při najití Nette\Caching\Storages\FileStorage a Nette\Caching\Storages\FileJournal. Tagy totiž přesně řeší to, co potřebujeme - akorát jsou použity v daném případě výhradně k mazání cache, my podle toho data potřebujeme "vytahovat". Journal toto řeší, nicméně metoda, která vyhledává dle tagu, je private - a to Vám nepomůže ani svěcená voda. Museli jsme tak celou class zkopírovat.

Toto řešení se nám líbí, protože v kombinaci s LazyLoadingem a optimalizací, kterou Nette Cache prodělala (včetně úžasného btree indexu) je rychlé, a bezpečné. Pro jistotu jsme akorát doplnili do clean() a remove() metod násilný return - aby to někdo, někdy v budoucnu omylem nepromáznul. Je rovněž důležité data ukládat mimo "temp" adresář, aby nedocházelo v budoucnosti k problémům s dalšími programátory - ale jinak si myslím, že docela pohoda :-)

Disclaimer: Gist budu nadále upravovat dle toho, jak bude potřeba, ukládání cache klíče přímo do tagů mi nepřijde úplně ideální...

Gist se změnami v classách je zde: 

To jsme si takhle do firmy kupovali ssl certifikát.

You are prohibited from using your Certificate (...); and (iv) for use as control equipment in hazardous circumstances or for uses requiring fail-safe performance such as the operation of nuclear facilities, aircraft navigation or communication systems, air traffic control systems, or weapons control systems, where failure could lead directly to death, personal injury, or severe environmental damage.´

.. a sakra!