Skrz DEV cirkus vol. 2
Ve středu 10. 6. se v našich krásných nových kancelářích konal již 2. díl Skrz DEV cirkusu. Tématem bylo tentokrát zrychlování (mobilního) webu a obrázky.
Lint Roller? I Barely Know Her

blake kathryn
KIROKAZE
Sweet Seals For You, Always
Game of Thrones Daily
he wasn't even looking at me and he found me
🪼

Kaledo Art
"I'm Dorothy Gale from Kansas"
Cosimo Galluzzi
let's talk about Bridgerton tea, my ask is open
Cosmic Funnies
Three Goblin Art
Jules of Nature

No title available
Today's Document

ellievsbear
$LAYYYTER

Origami Around

@theartofmadeline
seen from Türkiye

seen from United States

seen from United States
seen from United States
seen from United States
seen from United States

seen from United States
seen from United States
seen from Germany

seen from Brazil
seen from Türkiye

seen from France
seen from United States
seen from United States

seen from Malaysia
seen from United States
seen from Türkiye
seen from Brazil

seen from United States

seen from United States
@skrzdev
Skrz DEV cirkus vol. 2
Ve středu 10. 6. se v našich krásných nových kancelářích konal již 2. díl Skrz DEV cirkusu. Tématem bylo tentokrát zrychlování (mobilního) webu a obrázky.
Zpracovaní obrázků na Skrz.cz
Na Skrz.cz zobrazujeme obrázky nabídek, produktů atd. v několika různých rozměrech a bohužel někdy se hodně liší poměr stran. Normální by bylo obrázky jednoduše zmenšit, v nouzi zvětšit, se zachováním poměru stran, aby se obrázek uplně nerozsypal (metoda 'resize') - to je normální přístup většiny eshopů.
Jenže … V podstatě každá nabídka má nějaky boxík a v něm je určitý pevný prostor vyhrazen pro obrázek. A prodává 'plný' obrázek, tj. obrázek bez 'whitespace' (různě barevné okraje), to je zbytečné špatné pozadí, které tam má přímo zákazník nebo bysme si ho doplňovali sami kvůli špatným rozměrům … to znamená některé obrázky je lepší raději oříznout (metoda 'crop') i za cenu, že kus obrázku chybí …
Jak (ne)násilně začít testovat
"Měli bysme začít testovat!" je motto hodně českých firem. A když "testovat", tak tím myslím automatizovaně. Ve Skrzu jsme na tom bohužel nebyli o moc jinak.
Ulrika jevila všechny známky netestovatelnosti. Jaké to jsou?
míchání business a prezenční logiky (business logika v controllerech apod.)
neseparovanost vrstev (k databázi se přes statickou třídu dibi přistupovalo všude)
a hlavně, používání statického service locatoru (třída Service a její statické metody, např. Service::Predis())
Další problémy byly, že něco jako Notice, nebo Warning, nikoho nevzrušovalo. Laděnka ukazovala přes 1000 chyb. Když jedna přibyla, nebo ubyla, to už bylo docela jedno. Hlavním problémem byly šablony ve Smarty, napsat {if $promenna} bylo mnohem snažší než {if isset($promenna)} - isset() v podstatě bylo zakázané slovo.
Tohle se muselo rozseknout.
Nová aplikace, Stella, se začala psát na Symfony DI kontejneru. Měla jasně oddělené responsibility tříd pro entity, repository, service, controllery. Takže skvělé, můžeme začít testovat!
Jenže se k tomu nikdo moc neměl.
Na začátek říkám, že rozhodně není cílem 100% code coverage. Jako rozumné se ukazuje minimálně 1 integrační test na každou stránku (akci controlleru). Proč zrovna tohle? Protože chcete vědět, že když tady něco zrefaktorujete, že se všechny stránky alespoň vyrenderují. I kdybyste změnili zásadně logiku a začali se renderovat blbosti, začali se do databáze ukládat blbosti, chcete vědět, že data tečou jako do DB, tak k uživateli.
Vznikl tedy "master test", konkrétně třída Skrz\Test\ControllersCoverageTest, která reflexí (tohle je jedno z mála míst, kde má smysl použít reflexi) projde všechny controllery, např. Skrz\Bundle\FrontendBundle\Controller\HomepageController, a zjistí, že k nim existuje třída s postfixem Test, např. tedy Skrz\Bundle\FrontendBundle\Controller\HomepageController. Třídy se projdou reflexí, v controlleru se najdou všechny metody končící Action (konvence pro Symfony akční metody), např. homepageAction, a zkontroluje se, že existuje v testovací třídě metoda testHomepageAction (používáme PHPUnit).
Avšak ani tohle nestačilo.
Proč? Nikdo si testy lokálně nespouštěl. Takže "master test" byl věčně rozbitý, protože chyběly testy pro nové controllery/akce.
Další krok je nahodit CI server. Pro PHP je úplně nejjednodušší na konfiguraci PHPCI - za hodinku máte nakonfigurováno a už jedete. Když jste ve fázi, že potřebujete ostatní přesvědčit, aby testovali, na nic se nikoho neptejte. Prostě na nějakém serveru rozběhejte PHPCI, hoďte tam repozitář, a opravte testy, aby byl build zelený.
A teď přijde to kouzlo!
Zapněte notifikace, pokud někdo rozbije build. Nejdříve mohou být všichni nasraní, ale to (snad) rychle přejde a dokonce si začnou testy spouštět lokálně, aby build nerozbíjeli.
CI server je teď důležitou součástí našeho vývojového procesu. Od PHPCI jsme mezitím přešli k Atlassian Bamboo. Hledáme ale ještě další lepší řešení. Což platí pro celý vývojový proces, technologie, co používáme, a vůbec celou firmu.
WebExpo 2014
Rádi bychom se podělili o dojmy z letošního webexpa
Organizace byla super! Mělo to menší mouchy, ale celkově nás to bavilo :) Velké díky všem co se na tom podíleli!
Redesign (aka girl on girl action)
Sesedli jsme se kolem Petra s notebookem a on začal ukazovat a vysvětlovat wireframy jednotlivých stránek. Došli jsme do konce. Ticho rozsekl až Adam: "Na začátku jsi říkal, že to bude o přesunutí tohodle tlačítka sem, tohodle tlačítka tam. Ale tohle je úplně jiná aplikace!"
"A co to teda přepsat, od základu?"
"Přepsání, jsem se snad dohodli, že je mimo hru."
"Ale jak říkáš, je to jiná aplikace…"
Bylo tedy rozhodnuto, aplikace se přepíše od znova. Proč se vůbec uvažovalo o přepisu? Jako u každé aplikace, se za dobu vývoje v kódu nastřádalo množství "hacků" - prostě ty věci, aby to bylo rychle a business byl spokojen. A čím rychlejší je vývoj, tím víc se toho nastřádá. Až že se to začne podepisovat na stabilitě aplikace a rychlosti dalšího vývoje - aneb "musím tu udělat tenhleten hack, abych nerozbil ten hack, co se tehdá udělal támhle".
Naše Ex a za koho jsme ji vyměnili
Ulrika, to je kódové označení staré aplikace, byla udělána na vlastním základu, který se staral o routování, organizaci apod. Prostě vlastní garážový "MVC framework". Rozhodli jsme se, že tentokrát bude lepší jít cestou něčeho již hotového. Což se ukázalo jako problém. Existuje dobrý PHP framework, který není Symfony nebo Nette?
A poněvadž se DG Nette zřekl, že to nechá na komunitě (což se teď ukázalo, že byl jen pokus o to, jak do vývoje přitáhnout více lidí), nezdálo se dobré zakládat aplikaci na umírajícím frameworku. Symfony vyhrává na celé čáře.
Novou aplikaci (část aplikace) jsme začali nazývat Stella.
Teď ale nebylo jasné, jak dlouho budou tyhle dvě holky ještě BFFs a která by měla být tou hlavní. Buď mohla nadále Ulrika nadále obstarávat startup aplikace, obsluhu requestů, routování a teprve až pak předat řízení Stelle. Nebo naopak, začít se Symfony HttpKernelem a některé routy nasměrovat na starou inicializaci Ulriky. V Ulrice jsme znali každé zákoutí, ve stejné harmonii se Symfony/Stellou jsme ale ještě nebyli. Zvolili jsme tedy první variantu (a hlavně jsme se báli jakkoli víc sáhnout na její více jak 1000-řádkovou incializaci v "base controlleru" protože by to nejspíš dopadlo špatně)
Ulrika vznikala v době PHP 5.2, o namespacech si PHP programátoři mohli nechat jen zdát, nové odkazy na controllery se tedy daly jednoduše odlišit, že byly namespaceované. Vznikla tedy jednoduchá mezivrstva (Skrz\ControllerRunner), které Ulrika hned, jak zjistila, že se jedná o namespaceovaný controller, předala řízení. ControllerRunner podle prostředí inicializoval DI kontejner, vzal z něj controller a už všechno jelo Symfony stylem.
Pokud bych se měl rozhodnout znovu, udělal bych to přesně obráceně. A doporučil bych to tak i ostatním. Sice Symfony neznáte, uděláte mnoho fuck-upů po cestě. Ta 1000-řádková inicializace při každém requestu je pořád děsivá a nikdo na to nesahá, nejlepší čas, kdy to rozseknout, bylo tehdy. Míchat nové a staré routování přineslo mnoho problémů. Nicméně Stella funguje, Ulrika postupně ustupuje, stabilita aplikace je lepší, máme čas na více nových fičur. Nebojte se tedy postupné evoluce kódu.
Fáze 2. Ahoj Jirko, já jsem Jirka a to je Jirka
Křeštní jména se u nás vyskytují v párech. Máme dva Petry, dva Jakuby, dva Jirky, dva Ondry, jednu dobu jsme měli i dva Honzy. Pokud přijde na pohovor někdo kdo už má v týmu jmenovce, zcela vážně se ptám jestli je ochoten změnit si jméno :)
A aby toho nebylo málo, přišel Jirka třetí. U něj nám to však výjimečně vůbec nevadilo, byl to totiž Jirka Knesl.
S Jirkou jsme začali spolupracovat a rádi bychom ho znevyužívali co nejvíce to půjde. Pomáhá nám s architekturou aplikace, infrastrukturou, konzultuje s námi použití nových technologií, mentoruje… Jo a zavedl u nás scrum.
Proč? Protože jsme potřebovali překopat celé fungování týmu. Abychom se nezbláznili, pořád nás to bavilo a ještě k tomu byli co nejvíce efektivní.
Celodenní školení je věc, která mnohé může děsit, s Jirkou ale uteklo jako voda. Ani jednou za celý den se mi nestalo, že by ztrácel mou pozornost. Šli jsme po logických blocích, mezi kterými byly pauzy. Uváděl dostatečné množství příkladů, takže pokud něco někomu z teoretického popisu nebylo jasné, záhy pochopil. Po obědě zvolil volnější nástup a plynule pokračoval dál. A potom co doškolil, rozjeli jsme velkou diskusi o tom jak to naroubovat k nám, jak se poprat s konkrétními postupy, jaké jsou tedy teď následující kroky a kdo si z toho co odnesl.
Obecně tedy: Běháme týdenní sprinty, které začínají v úterý. Máme jednoho scrum mastera a prozatím jednoho product ownera (postupně přidáme další, ale ten současný bude mít vždy poslední slovo - říkáme mu osvícený diktátor). Počáteční rychlost: 2,5 hodiny osově souměrné práce ve vákuu za den. A první sprint tak začal hned druhý den. V pátek.
Tato firma je hlavně o nápadech a vývojářích
Využiju mezi čas, kdy náš dev doslova nonstop pracuje na redesignu a i když tento blog není o mně, rád bych se představil jako ředitel firmy a vysvětlit důvody, proč náš development tým musí být nejlepší. Fakt nejlepší.
Od zakázkových mini webů až po firmu
Sám jsem původně programátor. Začal jsem před 15 lety a prošel si klasickou cestou od svých hobby webů přes první zakázky ještě na dohodu o provedení práce, přes založení IČ a klasických webdesignových zakázek až později po založení vlastní firmy ještě při studiu vysoké školy.
Na začátku svých firem jsem ještě velmi aktivně programoval a víkendy trávil analýzou a přípravou zadání na další týden. Dneska už mám tým vývojářů, na který se můžu spolehnout a hlavně mám spolehlivého scrum mastera Honzu, který tým řídí s plným nasazením.
To nejde. Ale jde!
Celé této cesty nelituju a naopak si ji velmi vážím. Dala mi vhled do spousty možností, které nabízí automatizace a dobře vymyšlená aplikace. Díky tomu dokážu hledat souvislosti a hlavně překonávat bariéry, když někdo řekne "to nejde". Proto se snažím vždy hledat tu nejlepší, nejrychlejší cestu, jak dokázat, že to jde.
Development je srdce firmy
Děláme projekt, který je založený zejména na precizních a dobře udělaných algoritmech, které dokážou ve velkém množství obsloužit přes 100 tisíc uživatelů denně a každému individuálně servírovat právě ty nabídky, které by ho měly nejvíce zaujmout. Kromě toho máme mobilní aplikaci a velké reklamní plochy, kde všude fungují velmi dlouho laděné algoritmy sledující i ty nejmenší záchvěvy.
Z toho všecho vyplývá, že pokud chceme udělat posun, jak v oblasti obsahu (XML importy), tak v marketingových kampaních (např. automatizace bannerů, PPC, Facebook), tak všechno toto se sbíhá k developmentu, na kterém je převzít know-how a dovést nápad k realizaci. Ti nejlepší vývojáři jsou pro nás opravdu klíčoví. Zároveň můžeme i všem vývojářům nabídnout neustále nové výzvy, kde nemáme od koho kopírovat a musíme si to tvrdě celé postavit od nuly a vyladit k dokonalosti.
Skrz.cz sice navenek vypadá jako velmi jednoduchý web, ale uvnitř je to opravdu velmi složitá aplikace pracující se stovkami milionů záznamů real-time. V některých věcech už nyní vím, že jsme nejlepší v celé ČR. A to je přesně to, co mě na Skrz.cz baví.
Petr Kováčik - říďa Skrz.cz
Fáze 1. Git & feature branch
Z SVN jsme přeskočili na Git. Git na bitbucketu. Just like that, ze dne na den. A prali jsme se s tím. Na začátku neskutečně. Adam prohlásil, že SVN je ke Gitu jako Apple k Microsoftu. Co je tedy lepší? Intermezzo I s perličkou z pohovoru: A: a jaký je tedy rozdíl mezi Git a Subversion? B: (po minutě usilovného přemýšlení): SVN neumí ty větve, ne? Nemyslím si, že Git je lepší než SVN nebo vice versa. Jsou prostě jiné. Osobně se mi moc líbí decentralizovanost gitu. Jednou za čas jedu čtyři hodiny autobusem do asie a pokud jste už někdy zkoušeli na D1 chytat mobilní signál, tušíte jak moc velká lahoda to je. Co se větví týče, i když nemám stejný názor jako náš pohovorovaný, větve v gitu jsou prostě lepší a stejně tak práce s nimi. Druhou částí přerodu byly feature branche. V té době jsme ještě běželi na springloops a větve tedy začali pojmenovávat podle něj task/<číslo>. Protože ne všichni měli a mají přesah do všech částí projektu, code review se dělal spíše ve stylu “hele, hrabu ti do tvého kódu tak se mrkni jestli jsem tam něco nezprasil” Intermezzo II přesah? Části projektu? Vždyť zobrazujete nabídky slevomatů?!! Vlastně je dobře, že to tak vnímáte. Skrz.cz má na venek opravdu působit velmi jednoduše. Ale ve skutečnosti je to nějak takhle
(to, co je nad hladinou, je tak 10% celého projektu)
Co tedy ve Skrz.cz děláme
Skrz.cz už dávno nezobrazuje jen “slevomatí nabídky”. Dlouhou dobu umíme už i e-shopy. Spousta lidí už letáky používá jen na sušení bot a kouká na ně raději u nás. Umíme doporučit to co vám nejvíc sedne na míru. Máme mobilní appky inzerujeme kde to jen jde a všechno víceméně live.
Chcete to v číslech? OK:
3,5 mil visits měsíčně
10 mil bannerových impresí denně
Každý den přes 150 tis. mailů (personalizované)
Mobilní notifikace pípneme každý den taky na pár tisíc uživatelů.
A do toho provozujeme affil platformu pro Slevové servery
Více podrobností probíráme jen osobně - ne všechno se dá zveřejnit. Pokud budete mít super nápad, rádi si poslechneme jak a kam expandovat!
Co pro nás bylo po gitu další výzvou? Kdo nám pomohl začít stavět dev, který bude dávat smysl a bezvadně fungovat? O tom zase příště!
Tento měsíc jsme začali úzce spolupracovat s Jirkou Kneslem - programátorům netřeba představovat. Jirka bude přímo mentorovat náš tým a má za cíl zlepšit vybrané vlastnosti Skrz.cz a odstranit technologická omezení a chybovost. Už z prvních pár dní je vidět, jak obrovsky náš development tým...
Jak jsme začali sprintovat
Ne nebojte. Nebudeme na vývojářském blogu řešit běhání a ani tu teď nebudu popisovat jak že se to ten scrum má dělat. Za rok jsme vyrostli z jednoho programátora a jednoho kodéra na šestičlený tým a to už je sakra rozdíl. Na výkonu to šlo poslední dobou velmi znát, podepisovala se na nás i standardní zvyklost
"Potřebuješ něco opravit? Přijď rovnou za devem”
Všem nám bylo jasné, že je s tím potřeba něco udělat. Pokud máte podobné problémy a nevíte co s nimi, přečtěte si jak jsme se s nimi poprali my. Výchozí bod - jak jsme fungovali Tým sestával původně z jednoho vývojáře a jednoho kodéra. V červnu loňského roku jsme se rozrostli o jednoho nového programátora. O mě. A bylo třeba řešit jak se poprat se zažitým postupem já na kodéra, kodér na mě. Zpočátku se tohle řešilo tím, že jsem řešil věci, které spadaly mimo běžný provoz webu. Pak jsme ale nabrali další kluky a záhy z toho byl mnohem větší problém. Od Kuby Kulhána, který k nám přišel z Kouzelné Almary, přišel první impuls. Přejít na git a začít vyvíjet ve feature branch. Přestože by se přechod z SVN na git mohl zdát jednoduchým nebyla to až taková sranda. Zžívali jsme s ním dlouho (a ještě poříd zžíváme). Ale zpětně to beru jako výborný krok. O tom co nám dělalo problémy a jak jsme je řešili zase příště.
Proč blog vývojářů ve Skrz.cz?
Skrz.cz bych naprogramoval za víkend. Možná i o velký přestávce.
Prdlajs, doba je někde jinde. To, co je vidět venku jako zřejmá funkcionalita, je možná tak 5-10% toho, co se ve Skrz.cz řeší. Řešíme práci s nestrukturovanými daty, všechno musí být rychle, řešíme personalizaci, která znesnadňuje cache, musíme umět importovat tisíce XML feedů v co nejkratším čase, přepočítáváme pořadí nabídek v řádu jednotek minut atd.
Na toto téma bychom mohli mluvit hodiny. A právě proto budeme psát blog, necháme vás nahlídnout pod pokličku a třeba vás inspirujeme zajímavým řešením.