15.06.2021 12:02 Martin Kolář pro Vzhůru dolů píše o nástroji, který u vývojářů není právě populární. Přesto se bez Google Tag Manageru na většině dnešních webů nedá obejít. Po rychlém úvodu si v textu vysvětlíme, proč je GTM tak důležitý a proč by se vývojáři neměli vzdávat zodpovědnosti za správu značek na svých webech. Základním účelem správců značek je snadná správa značek . V případě webu jsou značky defakto kusy javascriptového kódu. Video: GTM očima marketéra a vývojáře Martin Kolář a Marek Pěntoň vysvětlují, proč by vás Google Tag Manager měl zajímat. → YouTube kanál V textu se budeme zabývat Google Tag Managerem . Kromě GTM existují i další správci, například Adobe Experience Platform, IBM Digital Data Exchange, Ensighten, Salesforce Data Management nebo Tealium. Několik základních pojmů Pojďme si na začátek vysvětlit pár pojmů, se kterými se můžeme v GTM potkat. Záměrně uvádím anglický i český název: Tag - Předdefinovaný či vlastní kus kódu, který se provede při splnění nějakého pravidla. Trigger - Značky spouštíme nad nějakými pravidly. Ty mohou velmi připomínat javascriptové eventy . Variables - Naše proměnné v rámci GTM kontejneru dataLayer - Definovaná datová vrstva, do které můžeme pomocí funkce dataLayer.push vkládat data. Kontejner - V něm máme všechny ty značky, pravidla a proměnné. Celý kontejner můžeme exportovat nebo importovat a pracujeme s ním jako s balíkem informací. Workspace - V řeči vývojářů by kontejner byl takový Git repozitář a workspace pak byla větev. Workspace je dobrá věc pro práci v týmu. Publikace - Vytvoření verze a nasazení - takový merge request a deploy. GTM spravuje značky, ale nic neměří Než se pustíme do vkládání GTM na web, je nutné si říct, že Google Analytics != GTM. Analytics jsou dostupné v GTM jako předdefinovaná značka. Můžete tedy použít GA mimo GTM, nebo GA v rámci GTM. Spuštění měření při tahání GA v rámci GTM může být pomalejší, ale rozdíl asi nepoznáte. Obrázek: Schéma vztahu sebu, datové vrstvy, Google Tag Managera a jednotlivých značek. GTM centralizuje správu dat o používání stránky. Pokud jen pomocí Analytics měříme počty návštěvníků a v GTM nemáme nic dalšího, je to zbytečný kód navíc. Pokud ale budeme do GA posílat události a v GTM mít více značek - tadá, tady to dává smysl! Jak vložím GTM na svůj web Na stránce tagmanager.google.com použiji nebo si vytvořím účet a pod účtem si vytvořím kontejner. Po jeho pojmenování a vybrání, že jde o webovou stránku, mi GTM ukáže i samotné nastavení na webu. Jde o 2 kódy, první je javascriptový a ten vkládám do hlavičky webu, druhý je ve značce a slouží pro případy, kdy návštěvník má z nějakého důvodu vypnutý JavaScript. Takhle vypadá kód pro instalaci GTM do stránky. Ani po vložení se ale ještě nic neměří. Mohlo by se zdát, že už máte svoje GTM na webu, ale soubor gtm.js se vygeneruje až poté, co ve svém GTM odešlete první verzi svého kontejneru. Může být prázdný, ale musíte ho odeslat. Do té doby vložený script vrací chybu 404. Výhody GTM Co nám jako vývojářům tedy GTM může přinést za výhody? Pojďme se na některé z nich podívat: Centralizace dat Díky datové vrstvě si můžete sjednotit všechny marketingové nástroje na jedno místo - do GTM. Nestane se, že váš markeťák nebude tušit, který ty kousky kódu potřebuje a které ne. A hlavně - neděláte si nepořádek v kódu marketingovými scripty. Rychlá změna kódu Potřebujete rychle přidat kus JS kódu tak, aby se dostal ke všem? Ideální situace, v GTM máte za minutku hotovo. Rozhodně to není trvalé řešení, tak na to prosím myslete. Částečná automatizace procesů Tohle „rychlo-přidání“ kódu můžete využít i pro automatizaci. Související Google Analytics: jak přidat web Google Analytics: pro vývojáře Google Search Console Máte třeba levnější tarif Hotjaru? Nevadí, nastavte si spuštění jen první 2 dny v měsíci. Nasadili jste novou věc a chcete vědět, zda funguje? Tadá! Stačí v GTM kliknout a až zjistíte, jak se věci mají, zase to vypnete. Ušetření práce vývojářů A když už máte dataLayer - markeťáci a designéři netrápí vývojáře nasazením každého nového trackovacího nástroje. Stačí jej přidat v GTM a druhý den můžete sbírat data. Jenže tady přichází ta věc… Sdílená zodpovědnost Už asi chápete, že GTM nemůžeme nazvat marketingovým nástrojem – přeci jen většinu věcí dělá JavaScript a který markeťák ho umí? Ale taky ho nemůžeme nazvat frontenďáckým nástrojem – mnoho frontenďáků například netuší k čemu je nutné na webu mít Facebook Pixel. Takže zodpovědnost je zde sdílená: Frontend zodpovídá za to, že všechny ty kódy správně fungují, nic nerozbijí a spouští se ve chvíli, kdy jsou potřeba. Marketing by si měl ohlídat, zda mu do GA apod. nástrojů chodí správné data a správu těchto dat dlouhodobě obstarat. No a pokud je na jedné z obou stran problém, například s rychlostí, musíte ho řešit týmově. Ono to totiž, a teď se obracím na markeťáky, není o kopírování kódů do značek. A frontenďáci - pro vás zase GTM nemá být magie. Vaším cílem je mít web rychlý, funkční a měřitelný. U GTM je dobré vzájemně komunikovat a být spolu v kontaktu. Jasně, je těžké někomu vysvětlit, že jQuery na webu fakt nemáte, ale jako frontenďák taky asi netušíte, k čemu jsou transakce v Analytics… Značky Zopakujme, že značka je kód, který GTM provádí. Abychom si to zjednodušili, pojďme si rozdělit značky podle možných autorů: Předdefinované od Googlu - ty jsou zcela bezpečné. Značky třetích stran - Google je schvaluje a zdrojové kódy jsou veřejně dostupné, ale myslete na to, že: „Google žádným způsobem nezaručuje funkčnost, kvalitu a obsah služeb a aplikací zajišťovaných těmito šablonami.“ abychom citovali z nápovědy. Vlastní značky - ať už kus HTML kódu, obrázek nebo vlastní šablonu. Využití značek už tu zaznělo - většinou jde o marketingový nástroj nebo kus javascriptového kódu. Ty mohou spouštět nahrávání obrazovky, chaty nebo třeba Sentry. Takto vypadají značky v Google Tag Manageru. Kdy se ty značky ale spouštějí? Spouštění - triggery Této části asi na první dobrou neporozumí markeťák, ale frontenďák už určitě tuší, že si budeme hrát s tím, kdy kterou věc spustíme. Důležitá otázka: Kdy tu značku sakra zapnout? Pokud se bavíme o značkách, které chceme spustit na každé stránce, máme 3 možnosti: Zobrazení Model DOM je připraven Okno načteno Události nastávají přesně v tomto pořadí. Asi tušíte kdy přesně, ale radši si to ještě projděme. Zobrazení nastane ihned, jak je GTM funkční. Vhodné to tedy je pro analytické nástroje jako GA. DOM Ready využijete pro scripty, které potřebují už celý DOM a není je potřeba spouštět co nejdříve. Okno načteno je vnitřní událost, která se spouští až ve chvíli, kdy se přestane nějaký obsah stahovat. Ideální pro nějaké chaty a další blokující nekritický JS. Mimo tyto eventy můžete používat také události na kliknutí, odeslání formuláře, posun stránky, viditelnost prvku apod. Vlastní kapitolou jsou pak vlastní eventy, které se posílají přes dataLayer. Můžete si tak například do datové vrstvy poslat událost „prohlédnutí obrázku“ a v GTM ho nějaký způsobem zpracovat do analytických nástrojů. Pravidla – kdy se spouští která značka? Datová vrstva, dataLayer Už jsem tu mnohokrát zmínil pojem dataLayer. Jeho dokumentaci pro GA4 případně pro Universal Analytics je dobré si pročíst. Ve zkratce se jedná o vrstvu, do které posíláte data. Co uživatel viděl, kam kliknul, co si vložil do košíku… Následně můžete tyto data dále v rámci GTM uložit do GA a dalších analytických nástrojů. Tzv. „push“, kterým se toto ukládání děje, potom může například na na detailu produktu e-shopu vypadat takto: dataLayer.push ; Vysvětlíme si to: event - jakou událost v GTM spouštíme. view_item - předdefinovaná událost pro měření prohlížení produktů . ecommerce - data pro ecommerce vrstvu. items - předdefinovaná struktura dat pro GTM. V takovémto kódu může samozřejmě vznikat leckerý problém, který ovlivní rychlost webu. GTM a rychlost Může být web rychlý i s GTM? Ano, jde to. Jde jen o to, co si do Tag Managera dáte, jak si ho budete hlídat a jak se o něj budete starat. Můžeme si říct pár základních pouček: Vypínejte značky, které nepoužíváte - nenechávejte zapnutý např. Hotjar, pokud uživatele aktivně nesledujete. Nastavte správné spouštění značek - jak jsem psal výše: myslete na to, kdy se která značka má spustit. Ne všechno potřebujete spouštět hned - i když ten spouštěč s názvem „Zobrazení“ zní tak krásně… Vybírejte značky podle reálný dopadů. Není totiž chat jako chat. Dobře a kvalitně měřte aplikace třetích stran, případně webu jako celku. Jednoduše pak zjistíte, co přesně web z ničeho nic zpomalilo. Když už manažer značek může rozbít rychlost, nemůže rozbít také něco jiného…? Bezpečnost a GTM Na závěr jedna důležitá, ale zároveň ignorovaná věc. Bezpečnost. GTM vám možná už i jako vývojářům teď zní jako super nástroj. Dejte si ale pozor, kdo k němu má přístup. Ona totiž vlastní značka s kódem… …udělá přesně to, co si myslíte. Ano, asi toto nenastane, ale krásně to vypovídá o tom, jak moc opatrní u udělování přístupů musíte být. A taky jak moc je důležité, abyste se jako vývojáři o manažery značek zajímali a sledovali je. Pokud dáte přístup správným lidem, předdefinovaným i komunitním značkám můžete věřit. Google jejich bezpečnost řeší a upozorní i na to, k čemu mají značky přístup, takže se snad můžeme spolehnout, že se v průběhu času nezmění na tajného sledovače našich uživatelů. Závěrem Jak už jsem napsal, GTM je dobrý sluha, ale zlý pán. V rukou jen markeťáka, nebo jen frontenďáka může být nebezpečný. V rukou obou těchto oborů to může být skvělý nástroj, který vám ušetří spoustu nervů. O GTM by se toho dalo napsat ještě spoustu dalšího. Například jak na vlastní šablony značek, jak na práci s proměnnými, verzování a workspaces… Pokud vás zajímá více, přihlaste na naši marketingo-frontendovou sérii webinářů o GTM na gtmskoleni.cz.
08.06.2021 22:16 V květnu letošního roku proběhne ve vyhledávání Googlu aktualizace zvaná Page Experience, kde mají nový význam ukazatele uživatelského prožitku, včetně metrik rychlosti webu zvaných Core Web Vitals. Související Mýty o rychlosti Téma „Rychlost webů“ Podle všech vyjádření z Googlu, které jsem měl možnost číst, nepůjde o velký revoluční posun a pokud nemáte obzvlášť pomalý web, asi se nemusíte bát. V každém případě se ale mít rychlý web vyplatí. Důvody jsem kdysi sepisoval na blogu, ale detailněji také na PageSpeed.cz. Kromě možných výhod ve vyhledávání k nim patří vliv na obchodní výkonnost webu, včetně konverzního poměru. → Toto je rozšířená verze textu, který vyšel v newsletteru ze Vzhůru dolů. V následujícím seznamu tipů jak zrychlit web nemám ambici být obsahově vyčerpávající. Spíše připomínám metody, které jsou relativně nové, které se mi osvědčily při práci pro klienty, a o kterých jsem psal na Vzhůru dolů. Obsah Dobře měřte Metriky? Sledujte hlavně Core Web Vitals Lazy loading dejte skoro všude Nepoužívejte CDN pro kritické zdroje Preconnect pro kritické zdroje Preloadujte, ale šetřete s tím Využijte nové formáty obrázků: AVIF, WebP Držte layout Předpokládám, že základy znáte. Že zmenšujete datový objem, snižujete počet requestů, máte nasazené HTTP/2 a neděláte moc velké blbosti. Pojďme už na ten seznam. 1) Dobře měřte Nezapomeňte, že skóre nástroje Lighthouse neudává rychlost webu. Jen zhruba indikuje, kolik problémů na webu máte. V různých oborech vrací různá čísla a většinou nedává smysl usilovat o stoprocentní hodnocení. Lighthouse Performance Score je užitečný ukazatel, když víte, jak jej číst. V opačném případě je to jedna velká kulatá past. Dívejte se na jednotlivé metriky a snažte se je vylepšit, zejména ty důležité – Largest Contentful Paint a Total Blocking Time se podílejí na polovině celkového skóre. Lighthouse Performance Score je fajn, ale důležitější je vidět jednotlivé metriky a filmový pás vykreslování. I to však Lighthouse nebo PageSpeed Insights nabízejí. Když už používáte tyto jednoduché nástroje, dívejte se na data od uživatelů z Chrome UX Reportu. „Data pole“, metriky přímo od uživatelů Chrome pro konkrétní stránku a jejich shrnutí pro celou doménu – v „Origin Summary“. Rychlost webu je vždy nutné posuzovat v širším kontextu a ten vám jednorázový test neukáže. Náš nástroj pro měření rychlosti webu – PageSpeed.cz vám k už uvedenému přidá pohled na vývoj v čase: Porovnání rychlosti úvodních stránek prodejců elektroniky, konkrétně vývoj Lighthouse skóre v čase. Čím je v grafu vyšší, tím lépe. Zdroj: Test na PageSpeed.cz Pro vývojáře je pak podstatné umět používat DevTools v prohlížeči, protože žádný checklist, žádný článek vám nevyřeší konkrétní problémy na konkrétní stránce. Jednomu z největších omylů kolem #RychlostWebu říkám „checklistová optimalizace“.Práce podle kontrolních seznamů je důležitá, ale velké posuny skoro nikdy neudělá. Pro dobré optimalizace potřebujeme chirurgicky přesně najít problémy. A taky vymyslet jejich efektivní řešení.— Martin Michálek February 19, 2021 Vývojáři a vývojářky, naučte se používat Chrome DevTools, zejména nástroje Performance, Network a Lighthouse, naučte se tam číst, co brzdí rychlost vašeho webu, co ovlivňuje konkrétní metriky. → Tip: Záznam z webináře Ladíme rychlost v Chrome DevTools. 2) Metriky? Sledujte hlavně Core Web Vitals Metrik rychlosti je opravu hodně, pro různé projekty a různé účely se hodí různé ukazatele. Postupný vznik událostí při vykreslování stránky. Raději než na Lighthouse skóre se v prvé řadě se zaměřte na Core Web Vitals získané od uživatelů – alespoň z Chrome UX Reportu. Ony totiž určují, jak si povedete v signálech Page Experience v Googlu. LCP – největší vykreslení obsahu. Asi nejdůležitější metrika, protože udává rychlost načtení. Mám o ní také video. FID – prodleva prvního vstupu, tedy zhruba jak moc máte pokažený javascriptový kód. Obvykle je na webech v pořádku, protože v rámci Core Web Vitals je nastavená málo přísně. V syntetických měřeních sledujte TBT. CLS – kumulativní posun layoutu. Nová a poněkud zmatená a matoucí metrika. I o ní jsem natočil hodinové video. Jednotlivé metriky Web Vitals a jejich doporučené hodnoty. Teď, když jsme se naučili základně měřit a sledovat správné metriky, můžeme přistoupit k technickým metodám, které nám v posledních letech rozšířily kufřík s optimalizačním nářadím. → Tip: Záznam z webináře Jak správně měřit rychlost webu?. 3) Lazy loading dejte skoro všude Líné načtení pro nebo opravdu pomůže. Sníží datový objem stránky, vylepší prioritizaci zdrojů. Odložené načtení ušetří to data a může zrychlit vykreslení stránky. Je to dostupné už skoro ve všech prohlížečích, takže stačí přidat atribut loading: Je to možné nastavit i pro vkládané rámce: Zatím to nepodporuje Safari, ale tam nic použitím nativního líného načtení nerozbijete. A v moderních prohlížečích by byla škoda použít javascriptovou knihovnu k něčemu, co prohlížeče zvládají samy. Líně ale nenačítejte zdroje důležité pro první viewport a už vůbec ne elementy, které jsou označené jako „LCP prvky“. → Tip: O líném načtení mám hodinový webinář. 4) Nepoužívejte CDN pro kritické zdroje Díky přechodu Chrome na partitioned cache, přestaly CDN dávat smysl pro sdílení zdrojů mezi weby. Jak to bylo dříve a jak je to teď. Schéma partitioned cache v prohlížečích. CDN může být v mnoha případech užitečná, například pro distribuci obsahu do různých koutů světa. Pokud tedy máte zahraniční projekt. Ovšem vzhledem k výše uvedenému ale nedává velký smysl stahovat z CDN zdroje webu kritické pro první vykreslení obsahu , jako například tento: https://cdn.jquery.com/jquery.latest.js 5) Preconnect pro kritické zdroje Včasné připojení pomocí může stránku urychlit, pokud už jsou kritické zdroje uložené na jiných doménách. Nepoužívejte to ale na všechny domény, kde jsou uložené zdroje stránky, jen pro zdroje kritické pro vykreslení první obrazovky. Například u analytiky to většinou smysl nedává. Tohle vypadá fajn, ale je to zjednodušené. V rámci „navázání spojení“ prohlížeč dělá tři úkony: DNS lookup, TCP handshake, vyhodnocení TLS . 6) Preloadujte, ale šetřete s tím může opravdu hodně pomoci, hlavně s metrikou LCP. Jenže zpravidla řeší problém, který vznikl špatným nakódovaním stránky. Přednačíst můžete například řezy fontů podstatné pro vykreslení LCP prvku: Ale může to přinést problémy nové. Daleko lepší je přirozeně optimalizovat frontu stahování a spouštění prvků ve stránce, například odložením načtení zdrojů, které nejsou kritické. Přemýšlejte, než přednačtení nasadíte. Je to hack a může to být past. → Tip: O preload mluvím na videu z webináře o metrice LCP. 7) Využijte nové formáty obrázků: WebP a AVIF Formát WebP už můžeme používat ve všech moderních prohlížečích. Jděte do toho. Nejsnadnější způsob nasazení je pomocí značky : Experimentujte také s famózně úsporným AVIF, který ještě ale nemá tak širokou podporu v prohlížečích. AVIF překonal nejen JPEG, ale i WebP a to v každém jednotlivém obrázku. Zdroj Daniel Aleksandersen, Ctrl.blog. Pokud vám metrika LCP ukazuje na obrázky, převodem do WebP, případně do AVIF si můžete hodně pomoci. → Tip: O obrázcích máme video „WebP, AVIF nebo JPEG?“. 8) Držte layout Optimalizace pro metriku Cumulative Layout Shift vyžaduje, abyste asynchronním prvkům jako jsou obrázky nebo externí zdroje drželi prostor v rozvržení. Stahovaný obrázek rozbije layout stránky raz dva. U obrázků je to už poměrně snadné. Prostě vždy vyplňte atributy width a height u značky : Jinde pomůže nová metoda s funkcí aspect-ratio nebo starší triky. → Tip: O metrice CLS mám také video z webináře a lidé říkají, že je bezva. Kam dál? Hledáte ještě další tipy? Na blogu PageSpeed.cz jsme vydali checklist pro optimalizaci rychlosti webu. Je k dispozici jako stránka nebo PDF a obsahuje opravdu, ale opravdu hodně tipů. Sledujte Twitter: @pagespeedcz nebo si na PageSpeed.cz udělejte test rychlosti webu a my vám jednou měsíčně pošleme vaše aktuální čísla a tipy na tři nejdůležitější články. Seznam možností jak zrychlit web je teoreticky nekonečný. Tento seznam proto publikuji s vědomím, že zde najdete jen ty nejdůležitější body, které jsem v posledním roce v klientské praxi řešíval. Budu jej ale průběžně rozšiřovat, takže tipy v komentářích nebo diskuzi nad uvedenými tématy opět vítám. Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .
04.06.2021 23:01 Container Queries jsou něco jako Media Queries, jen pro konkrétní komponenty, nikoliv pro celou stránku. Jde o něco, co samozřejmě v CSS chceme a při vývoji webů opravdu hodně potřebujeme. Webdesign je totiž stále více o komponentách, nikoliv o stránkách. Container Queries přistály v Chrome Canary. Je fakt mazec, jak jde ten vývoj rychle.https://t.co/pLFKHnBs55— Martin Michálek April 1, 2021 Před lety to ale ještě nevypadalo dobře. Provázely to různé problémy a hlášení o „nemožné implementaci“. Napsal jsem o tom podrobný článek na blog a prohlásil, že to asi nikdy nedostaneme. Jsem rád, že jsem se spletl. Po letech vývoje do Chromia přichází experimentální implementace, která by toto dovolovala. Vezměme tuto krátkou ukázku: main, aside .media-object @container } Stručně vysvětlíme: Vlastnost contain s hodnotou size tvoří zapouzdří prvek do samostatné jednotky, která zde poslouží jako rodič pro container query. Klíčové slovo @container je jako @media, jen necílí na šířku viewportu, ale šířku rodiče. Jak to otestovat? Potřebujete Chromium 91.0.4459.0 . Jděte do vlaječkového nastavení: chrome://flags. Povolte možnost „Enable CSS Container Queries”. Demo: Bram.us: https://cdpn.io/bramus/debug/LYxNpeE Una Kravets: https://codepen.io/una/pen/LYbvKpK?editors=1100 Více informací: Bram.us: Container Queries are coming to Chromium! Piccalil.li: Container Queries are actually coming Jen prosím pozor, implementace je označena jako experimentální a zatím ani není potvrzená od CSS Working Group ze standardizační organizace W3C. Od možnosti takové věci používat jsme ještě pořád daleko. Ale vypadá to velice nadějně! Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .
01.06.2021 00:31 Martin a Robin si s produktovou a interakční designérkou Evou povídali o přechodu k freelancingu a rovnou do zahraničí, dále je zaujala témata jako herní design, navrhování pro rozšířenou a virtuální realitu a další. Uvidíte sami. Přejeme vám příjemný poslech. MP3 ke stažení Host: Eva Kuttichová Eva je produktová a interakční designérka na volné noze. Pracuje pro americké startupy a jako nezávislý konzultant aplikací pro globální firmy. Spolupracovala na aplikacích jako je Surge, Zoe a Dot to Dot, které mají mají dohromady přes 20 milionů stažení. Eva: Web, LinkedIn, Instagram, YouTube O čem si povídáme? Robinův tip: Placené boilerplaty: Bedrock a Remix. Martinův tip: CSS vlastnost image-set přichází do Firefoxu, jde o obdobu srcset v HTML. Představení Evy Evina práce v STRV Co je to „produktový a interační“ design Přechod z firmy na volnou nohu Jak na volné noze Eva získává klienty Toptal, Upwork a Fiverr: platformy pro freelancery Práce na dálku s americkými klienty, kteří dbají na osobní vztahy Jak funguje práce produktového designéra na dálku AR/VR/xR: Design pro virtuální, rozšířenou a míchanou realitu Jak se navrhuje pro AR/VR: herní enginy Unity 3D, Unreal Engine, Reality Composer od Apple Knížky a čtení: Sapiens, Josef Müller-Brockmann, 100 Things Every Designer Needs to Know about People Sociální sítě - kde a jak budovat svojí kariéru - LinkedIn, Instagram, YouTube Work/life balance: jak to má Eva, Martin i Robin Aktuální tip: Poku uvažujete o vstupu na mezinárodní freelance scénu, využijte akce Frontendisti.cz ve spolupráci s portálem Freelancing.eu. Partner: SUPERKODERS SUPERKODERS jsou brněnská, ale v tuto chvíli plně vzdáleně fungující vývojářská firma se silnou specializací na frontend. Mají ale přesahy i do backendového vývoje nebo třeba konzultacím k performance. SuperKodéři momentálně hledají reactisty, PHP vývojáře nebo projekťáka. Pokud s nimi chcete pracovat např. pro Český rozhlas, Masarykovu univerzitu, DronPro, mrkněte se na superkoders.com/jobs. Děkujeme za podporu!
