22.12.2021 12:31 Filipa nejspíš znáte jako jednoho z prvních Čechů zaměstnaných v Googlu a jako propagátora Dartu a Flutteru. V této epizodě se o obou tématech krátce bavíme. Nejvíc se ovšem ptáme na boční projekty, kterých má Filip přehršel. Ostatně – asi každý vývojář má nějaký svůj „side project“. Filip jich udělal desítky, ale podstatné je, že se mnohým povedlo prorazit. Zakázal si totiž začínat nové projekty, dokud není ten předchozí spuštěný. Je dokončování projektů dovednost, která se dá naučit? A co si z toho můžeme odnést pro svůj pracovní i osobní život? Podcast MP3 ke stažení Host: Filip Hráček Filip je expert na Dart a Flutter. A tvůrce par excellence. Vývojář her, autor blogu, známého twitterbota, YouTube kanálu a mnoha dalších bočních projektů, které se právě teď mohou stát těmi hlavními. Hledejte ho na filiph.net, LinkedIn, Twitteru nebo YouTube. O čem mluvíme? Filipův odchod z Googlu Vedlejší projekty zaměstnanců Googlu. Platí ještě 20 % času? Role „developer advocate“ v Googlu. Proč nesmí být obchodník? Filipovy vedlejší projekty jako Year Progress Jak udělat úspěšný „side project“? Finishing is a Skill Další projekty jako The Self-Improving Developer pro vývojáře, kteří nemají formální IT vzdělání Filipova hra Knights of San Francisco a Natural language generation Egamebook engine a problém různých pohledů na open source Filip na YouTube a další plány Vytváření obsahu česky Jazyk Dart a nástroj pro tvorbu aplikací Flutter: v čem jsou dneska zajímavé pro vývojáře? Ukázka: rive.app Video: část o bočních projektech Celou část o bočních projektech tentokrát vydáváme jako samostatné video: Nalaďte nás Spotify — iTunes — Google Podcasty — TuneIn — RSS podcastů. Co vás letos na podcastech zaujalo a co byste chtěli slyšet příště? Budeme moc rádi, když nám dáte vědět: podcast@vzhurudolu.cz. Hezké svátky!
17.12.2021 01:15 Už to došlo i do Česka. Od ledna 2022 bude nutné od uživatelů žádat souhlas s použitím ukládání například personalizačních a analytických cookies. Stačí když na webu máte základní analytiku, např. Google Analytics, a od konce roku máte povinnost před uložením cookies žádat souhlas pomocí takzvané cookie lišty. Pravděpodobně jste to už řešili, pravděpodobně to už máte vyřešené. Pokud spravujete velké weby, tím spíše. Já spravuju jen Vzhůru dolů a pár malinkých webů, takže jsem to nechával na poslední chvíli. Text budu tedy spíše cílit na majitele menších webů nebo ty, kteří zatím neměli potřebu to řešit. Dole v textu odkazuji na všemožné zdroje, takže to můžete dostudovat. V textu základy řešit nebudu, spíše otevřu témata, která mě zaujala a jinde jsem je nenašel. Předem říkám, že se v téhle oblasti nepovažuji za odborníka – pokud se webařinou živíte, nasazení na weby konzultujte s advokáty, experty na UX a marketing. Můj pohled je pohled „hobbíka", člověka, který pro radost spravuje pár webů, ale vývojařinou se víceméně neživí. Než se do toho pustíme, velmi rád bych zde nejprve ventiloval svůj celkový osobní dojem. On se totiž za poslední týdny dost významně změnil. Uživatelé platí soukromím za to, že my šetříme čas a peníze Ještě před měsícem jsem nechápal proč bychom měli už i v Česku všechny weby nasazovat cookie lištu. GDPR už máme vyřešené a od roku 2015 nějak i v Česku řešíme „EU cookies". Vždyť přece stačí, že uživatele informujeme… Čím více to studuji, tím více dávám za pravdu zákonné úpravě, která bude platit od ledna. Jasně, forma je fakt nešťastná. Cookie lišta je zlo. Cookie lišta je zlo pro uživatele i provozovatele, takže se těším se na normu ePrivacy, která to přesune do nastavení prohlížeče. To soukromí ale fakt musíme řešit. Nepoužívat a nešmírovat. Za analytické nástroje nechat platit toho, kdo data měří a nenechávat to na cene uživatelského soukromí lidí, kteří ani nevědí co schvalují. Představte si situaci že přijdete do obchoďáku a u vchodu vám bez ptaní dají do kapsy krabičku, která bude ukládat vaši polohu – jaké obchody jste navštívili, co jste tam dělali. Dají vám ji s úsměvem a s tím, že příště ta data použijí pro zlepšení vašeho nákupního prožitku. A že je možné, že ta data někomu prodají. Pro vaše dobro. Líbilo by se vám to? Mě ne. Ale na webu je to úplně běžné: Přijdete, dostanete cookie od Google Analytics, která sleduje váš pohyb webem. Pokud je na webu vložené YouTube video, cookie se ukládá nejen pro úpravu obsahu a reklamy nejen na navštíveném webu, ale také na YouTube a také na jiných webech. Taková komentářová služba Disqus se s tím už vůbec nemaže. V Cookie Policy přiznává jen zlomek cookies, které reálně ukládá, a rovnou říká, že data vašich uživatelů posílá i dalším stranám. To všechno proto, že na webech mocně využíváme služby třetích stran. Zvykli jsme si na to. Šetří nám to jako vývojářům a marketérům čas a peníze. Jenže nic jako komponenta třetí strany zdarma neexistuje. I ty placené mají daleko větší cenu než si myslíme. Za náš ušetřený čas a peníze platí uživatelé svým soukromím. Jejich data, informace o pohybu našim webem využíváme nejen my, ale i úplně cizí firmy. Můj postoj je silně ovlivněný studiem třetích stran, které jsem dosud běžně používal zde na Vzhůru dolů a které pravděpodobně používáte taky – Google Analytics a vkládaný obsah od YouTube, Twitteru, Facebooku… Takže – pojďme to soukromí řešit. Pojďme to řešit bez paniky a nadávání na zákon nebo EU. Pojďme vzít ty cookie lišty jako příležitost se něco naučit a zlepšit web jako celek. Jednou třeba lišty dáme pryč a zůstanou nám, doufám, weby, které více dbají na soukromí lidí. Neprodávají jejich duši, aniž by to jako návštěvníci věděli. Teď už se pustím do praktických rad, co s tím dělat na malém webu. Dávám sem svůj stav mysli. Ten rád změním, když mě na to upozorníte v komentářích. Než se do implementace na vaše weby pustíte, poraďte se opravdu s odborníky. Nutné základy Nejprve pár textů a videí, které se vám mohou hodit při studiu: Právní pohled na Lupa.cz nebo od Petry Dolejšové. Marketingový pohled od House of Řezáč. UX pohled od Ondřeje Ilinčeva. Můj pohled k rychlosti webu na PageSpeed.cz. Komplexní webinář organizovaný Pavlem Ungrem. Diskuze o cookies u Frontendistů. Než budeme pokračovat, musím dodat pár úplných základů. Jen pár. Které cookies jsou nově se souhlasem a jak zjistím, že je na webu mám? Tohle jste už asi četli stokrát, ale pro jistotu to opakuju. Pravděpodobně na webu používáte cookies nutné např. pro přihlášení nebo uložení nastavení jazyka . Touto kategorií se vůbec trápit nemusíte, dále je možné je bez souhlasu používat. Dejte si pozor na tyto typy cookies: reklamní analytické personalizační K těmto potřebujete od 1. ledna souhlas. Nástroje, které pomáhají odhalit, které cookies na webu potřebujete: CookieBot.com CookieServe.com Nejdříve dobrá zpráva – analyzovat těmito nástroje je jednoduché. A teď ta špatná. Ani na Vzhůru dolů, takže strukturou menším webu, mě to nenašlo zdaleka všechny cookies, které bych měl „řešit". Navíc jde samozřejmě o statickou analýzu webu, takže např. komponenty načítané líně nebo na akci uživatele, to neodhalí. Prostě bez zkoumání uložených cookies a čtení „Cookie Policy" dodavatelů třetích stran se myslím neobejdete. Zákon praví… Z jaké změny v zákoně vlastně celý ten humbuk vychází? Zákon o elektronických komunikacích : Každý, kdo hodlá používat nebo používá sítě elektronických komunikací k ukládání údajů nebo k získávání přístupu k údajům uloženým v koncových zařízeních účastníků nebo uživatelů, je povinen tyto účastníky nebo uživatele předem prokazatelně informovat o rozsahu a účelu jejich zpracování a je povinen nabídnout jim možnost takové zpracování odmítnout. Tato povinnost neplatí pro technické ukládání nebo přístup výhradně pro potřeby přenosu zprávy prostřednictvím sítě elektronických komunikací nebo je-li to nezbytné pro potřeby poskytování služby informační společnosti, která je výslovně vyžádána účastníkem nebo uživatelem. To je vše. Složitě napsané, ale překvapivě krátké, že? Víte co, pojďme se tedy nejprve zkusit na to celé vykašlat. „Peču na to", aneb řešení bez cookie lišty Cookie lišta je otrava. Ano, to je. Víte jaká je nejlepší cookie lišta? Žádná! Pokud máte velký web, řešil bych to, u malinkých asi nemá smysl propadat panice a nutně nasazovat lištu hned po Vánocích. Jak to riziko chápu já? Postihy za nedodržení zákona samozřejmě budou udělovány, ale úřad ÚOOU, který to řeší by se musel rozkrájet, aby řešil i menší přestupky. Osobně čekám spíše akčnost typu „česká hygiena během pandemie". U svých malých webů nebudu s cookie lištou zase tak moc spěchat a stresovat. Advokáti navíc říkají, že vás nejprve úředníci musejí vyzvat k nápravě, takže i kdyby na vás „vlítli", máte čas to opravit. Pokuty by navíc neměly být likvidační. Kontrolu provádí @UOOUCR, sankce dává samozřejmě podle uvážení, ale horní hranice je vždycky předpisem limitovaná, navíc nesmí být nepřiměřená a likvidační. Myslím, že novela pro cookies nemá speciální hranici, takže limit podle GDPR .— Petra Dolejšová December 13, 2021 Nechci tady ale nabádat k očůrávání zákona. S jeho smyslem souhlasím, svoje weby podle něj upravím. Výše uvedené mi ale dává čas a klid to dát do pořádku, když už jsem to začal řešit pozdě. Jen pro pořádek – je potřeba odlišit GDPR a nový odstaveček zákona týkajícího se cookie lišty. Píšu tady o tom druhém. Pokuty za porušování GDPR jsou myslím úplně jiná písnička. To by už ale měli mít v pořádku všichni. A dávno. Jak nemít cookie lištu a zároveň dodržovat zákon? V prvé fázi jsem u všech svých webů přemýšlel nad tímto řešením. Realizovatelné to ale je jen u těch opravdu miniaturních. Pokud potřebuji základní měření Google Analytics, cookie lištu musím mít. GA totiž přidávají cookie, kterou měří uživatele napříč webem. Pokud potřebuji jakoukoliv jinou komponent třetí strany , pak vysoce pravděpodobně cookie lištu musíte mít. Takže – nezajímá vás návštěvnost a chování návštěvníků, nepotřebujete kód třetí strany? Lištu nepotřebujete. Lze mít Google Analytics a nemít lištu? Ano, GA můžeme přepnout do Consent Mode, kdy se neukládá cookie a uživatel není sledován. analytics_storage='denied' ad_storage='denied' Ztratíte ale přehled o počtu shlédnutých stránek na jednu návštěvu a vše související. Zůstane vám např. ale přehled nejnavštěvovanějších stránek, hrubý přehled o návštěvnosti a případně i konverzích. Možnosti, jak si ponechat GA a zároveň nemít cookie lištu, tedy plnit zákon, se objevují. Nemám je vyzkoušené, takže bez záruky. První příklad je naprogramování vlastní vrstvy událostí na Google Analytics: Přejdi na GA4, použij consent API a bez souhlasu měř bez využití dat ze storage jen pomocí odpalování eventů. Pak ti stačí podle ZEK uživatele jen informovat a podle GDPR uplatníš oprávněný zájem.— Martin Kopta November 26, 2021 Druhá varianta s počítáním clienId: Koukni na https://t.co/dbplN7Q8iM Je tam popsaná varianta, kdy clientId neukládáš, nýbrž jej počítáš pro každý request zvlášť. Výhody: nemusíš nic ukládat . Nevýhody: horší přesnost, může to session více lidí spojit do jedné.— Jirka Hrazdil December 15, 2021 Taky je možné nepoužívat Google Analytics, že ano? Popularitu teď nabírají alternativní nástroje jako je Matomo nebo Fathom a další. Z toho co jsem z komentářů analytiků, kterým věřím, usoudil… Je to past. Tyhle nástroje často nepoužívají cookies, to je fajn, ale zároveň uživatele identifikují jinak, nejčastěji kombinací různých faktorů, takže fingerprintingem, což je z pohledu soukromí úplně to samé. Zdá se mi, že ani tudy cesta nevede. Co další komponenty třetích stran? Musím se přiznat, že právě tahle část analýzy, kterou jsem si dělal pro Vzhůru dolů a další menší webíky, mě přesvědčila, že soukromí na webu je fakt problém. A že dodavatelé komponent třetích stran dělají většinou vše proto, aby to problém zůstal. Pojďme si projít pár third-parties, které jsem zkoumal. Google Fonts: názory se různí. Nějakou personalizaci dělají, ale spíše na základě lokality. Ve FAQ píší, že „no cookies are sent". Vladimír Smitka ale říká, že „Google fonty sbírají data o koncovém uživateli" a tak je při přísném výkladu potřeba souhlas. Nebo si fonty stáhnout lokálně. Vložení obsahu z Twitteru: Ukládají cookies, personalizační i reklamní, tzn. souhlas by myslím standardně byl potřeba. Je to však možné vypnout a chránit soukromí uživatele, viz nápověda. Vložení videa z YouTube: Standardně souhlas potřebujete, ukládají reklamní cookies. Embedy lze servírovat z domény http://youtube-nocookie.com a cookies se neuloží dokud uživatel video nepustí. Tzn. pak není potřeba souhlas? Nevím. Vladimír Smitka píše, že ta cookieless doména je fejk. Facebook embed i Facebook pixel: Ukládají cookie jak diví a nikde jsem nenašel možnost to změnit. Komentáře Disqus: Ukládá cookies jak divý, v Cookie Policy přiznává jen část a ještě vesele prohlašuje komu všemu ty údaje cookies nepředává. A to je prosím placená služba! Zde budu muset při pročišťování webu od nepořádných služeb třetí strany začít. Můj celkový dojem? Pardon, ale asi budu blinkat… Takhle špatné jsem to nečekal. Čest výjimce, čest Twitteru. Celé moje vlákno na Twitteru, pokud by vás to zajímalo doplněné o cenné názory dalších: Jak to od ledna bude s cookie-lištou a komponentami třetích stran?Sám tomu moc nerozumím. Co si myslím, vykopnu ve vláknu a třeba mě doplníte. ⬇️— Martin Michálek December 15, 2021 Můj seznam je samozřejmě nekompletní, takže pokud jej doplníte v komentářích , budu moc rád. Dobře, teď už vím, že s vysokou pravděpodobností budu i na Vzhůru dolů nějakou lištu potřebovat. Jak to ale implementovat? Řešení souhlasu s Google Tag Managerem Martin Kolář udělal o tomto jednoduchém řešení pěknou přednášku: Martin ukazuje řešení vhodné právě pro jednoduché weby a vlastní implementaci lišty. Veškeré komponenty třetích stran je ale nutné vložit právě přes Google Tag Managera: window.dataLayer = window.dataLayer || ; function gtag gtag ; V GTM se pak nastaví souhlas pro konkrétní kategorii v nastavení kontejneru. Více je v přednášce. Přes Google Tag Manager je pak možné i nastavit nesouhlas se vším, nechat přes nastavení GTM pak např. Google Analytics běžet v Consent Mode a uživatele netrápit cookie lištou. Řešení pro cookie lištu třetích stran Toto jsem zatím neřešil, proto zde využiju možností získaných od kolegů CookieConsent: Malý plugin i s ukázkovým kódem od Vladimíra Smitky. Complianz : Dan Střelec píše: „V základu je zdarma, nasazení cca 1 hodina práce . Pokud potřebujete ukládat souhlasy, je třeba placená verze . Větší řešení jsou například Cookiebot: V ČR velmi populární. Dan Střelec: „Neplacená verze je pouze do 100 stránek/web, od 500 stránek/web stojí €9/měsíc.". Nebo velmi robustní OneTrust , Didomi nebo Funding Choices od Google. Cookie lišta a rychlost webu Na blogu PageSpeed.cz jsem psal o trablech z pohledu rychlosti webu, které může nasazení cookie lišty způsobit. Svoje jsme si užili s OneTrust, Didomi i Google Funding Choices. Nicméně vždy jsme nalezli cestu k optimalizaci. Pravidlo číslo jedna? Načtěte tu lištu co nejdříve: Mezi vývojáři se rozšířil mýtus, že vykreslení obsahu typu cookie lišty se musí odložit co nejvíce to jde. Nejde přece o hlavní obsah stránky. Jde ale o jednu z velkých chyb, které můžete při implementaci lišt udělat. Co dál? Osobně budu pro Vzhůru dolů hledat co nejjednodušší řešení, které mi umožní splnit to, co zákon káže. Je už skoro jisté, že minimálně na nějaký čas zde cookie lišta bude viset. Po počáteční negaci beru ale celou věc kolem cookies od roku 2022 za velkou příležitost brát oblast soukromí uživatelů našich webů daleko vážněji. Tento text budu postupně doplňovat, ale moje znalosti jsou samozřejmě omezené. Neváhejte mě doplňovat do komentářů nebo e-mailem. Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .
08.12.2021 21:45 Deksriptor size-adjust definuje změnu velikosti pro znaky písma a pro metriky spojené s tímto písmem. Cílem je upravit vykreslení písma v prohlížeči. To se může hodit například pro sjednocení rozměrů systémového písma s parametry webového fontu. Nebo pro detailní ladění textů v malých komponentách typu tlačítka. V textu se budeme zabývat nejen samotným size-adjust, ale také příbuznými vlastnostmi jako je například ascent-override. Mají podporu v Chrome i Firefoxu a na Safari v tomto případě nemá smysl čekat. Skuhrání nad optimalizací fontů Optimalizace načítání a vykreslování fontů je při práci na rychlosti webu jednou z komplikovanějších oblastí. Ne, že bychom neměli dostatek možností optimalizace, ale je jich hodně. Stejně jako různých možností, jak je pro různé designy a různé projekty vhodné fonty vykreslovat. Načítání fontů je asynchronní a tak se i dále budeme potkávat s weby, na kterých to kodérky a kodéři nevyřešili dobře. Fonty se načítají pozdě. Po načtení finálního fontu se obrazovka razantně překreslí... Je to otrava. Deskriptor font-display vyřešili první důležitou věc – umožnil nastavit vykreslování jinak než, aby prohlížeč vždy tři vteřiny čekal na stažení webfontu a raději nevykreslil nic. V poslední době se vývojáři a s nimi například i autoři Google Fonts přesunuli k nastavení font-display:swap, které zajistí, že prohlížeč vždy vykreslí text – buď systémovým písmem a v momentě načtení pak i webfontem. V určitých situacích je to vhodné řešení, ale aplikovat to všude je samozřejmě špatně. Představme si například situaci, kdy dochází k překreslení ze systémového písma na výrazně odlišné písmo. Velmi často pak dojde k posunu obsahu pod ním a ke zhoršení metriky Cumulative Layout Shift . Tyhle trable by mohly vyřešit vlastnosti, které se vám chystám představit. Deskriptor size-adjust Jak už jsem psal, deskriptor size-adjust prostě zvětšuje konkrétní znaky. Přidáte ho k deklaraci písma a zvětší znaky pokaždé, když tento typ písma použijete: @font-face V ukázce používám písmo Arial, dostupné prakticky na všech zařízeních, a to pomocí předpisu o preferenci lokálního písma – local . Zvětšuji jeho velikost o 13 % – size-adjust:113% a tuto nově vytvořenou rodinu pojmenovávám Arial-Size-Adjusted pro případné použití kdekoliv v CSS. Jak se size-adjust liší od font-size? Je to jednoduché – size-adjust zvětšuje konkrétní glyfy, tedy znaky. Boxík, do kterého se písmo vykresluje, zůstává dále stejně vysoký. Všechny metriky spojené s tímto písmem budou po použití size-adjust zvětšovány daným procentem. Na obrázku je vidět efekt dvou deskriptorů: size-adjust nejprve o 13 % zvětší znaky, ascent-override pak posune znaky ze základové linky o 81 % výše. Vybral jsem hodnoty, které nejsou razantně jiné, takže to na obrázku zase tak dobře vidět není, takže mu prosím věnujte trochu více pozornosti než obvykle. Důležité je, že šedivý rámeček, tedy vykreslovací boxík textu zůstává pořád stejně vysoký, takže vám písmo neovlivní prvky kolem. V důsledku změny pomocí těchto deskriptorů jsou ovlivněny i všechny hodnoty odvozené z písma – například CSS jednotky ex a ch atd. Vypočítaná velikost písma – a tím i všechny hodnoty, které se od ní odvozují, jako jsou jednotky em – však zůstává neovlivněna. Použití k zabránění nechtěných posunů layoutu O vlivu překreslování webfontů ze systémových písem na CLS jsem už psal. size-adjust a podobné vlastnosti je možné využít pro zabránění tomuto efektu. Upravujeme si Arial k obrazu svému. V obrázku se nejprve podívejte na třetí obrazovku. To je finální stav – nadpis vykreslený populárním písmem Montserrat. Na první obrazovce je vidět neupravený Arial, zde použitý jako výchozí písmo. Jeho velikost ale přesně neodpovídá Montserratu, takže při stažení a překreslení do webfontu nastane posun obsahu pod ním a metrika CLS vyskočí na hodnotu 0,2, což už je přes povolenou hodnotu. Na druhé obrazovce využívám Arial upravený tak, aby velikostí zhruba odpovídal Montserratu. Díky úpravám se pak stránka může pyšnit nulovým CLS. Jaký kód jsem zde přesně použil? @font-face Asi vidíte, jak jsem pomocí size-adjust a ascent-override upravil nastavení tučného Arialu. Vzniknuvší rodinu písem jsem pak pojmenoval Montserrat-fallback. Celý kód i se stažením Montserratu z Google Fonts a deklarací písma pro nadpisy bude vypadat takto: @import url ; @font-face h1 V živém CodePenu si to můžete opět zkoušet a různě ohýbat. Kalkulátor pro napasování systémových písem ke Google Fonts Ptáte se, jak jsem došel k procentuálním hodnotám z ukázky výše? Pomohl Malte Ubl. Jeho kalkulátor nazvaný „Automatic font matching" myslím může ušetřit práci i vám. Kalkulátor Automatic font matching: industrialempathy.com/perfect-ish-font-fallback Jde o automaticky generovaný seznam fallbacků pro všechny písma obsažené v Google Fonts. Brána v potaz je zde jen podobnost z pohledu velikosti písma a z pohledu metriky CLS. Doporučuji ale při výběru a nastavování systémových písem zohlednit i estetické a účelové hledisko. Pro pořádek ještě dodávám už dlouho existující nástroj Font style matcher, který dělá podobnou věc - snaží se sjednotit styl systémového písma se stylem webfontu. Problém zde ale je v tom, že styly se, na rozdíl od deskriptorů jako je size-adjust aplikují na obě písma a je nutné si s tím poradit například detekcí načtení webfontu JavaScriptem. Deskriptory pro úpravu výšky řádku písma Projděme si ještě všechny deskriptory, z nichž jsme načali jen první: ascent-override – specifikuje posun nad základní linku písma descent-override – posun pod základní linku písma line-gap-override – zvětšuje mezeru mezi řádky nahoře i dole Spolu se size-adjust patří do „font-display modifiers“ , o kterých psal Simon Hearne, který také vytvořil testovací CodePen. Odkazy pro další studium Smashing Magazine: A New Way To Reduce Font Loading Impact: CSS Font Descriptors Web.dev: CSS size-adjust for @font-face Specifikace CSS Fonts Module Level 5 Podpora Podpora size-adjust je výborná a asi vás překvapí: Chrome i Firefox podporují. Safari zatím nepodporuje. Internet Explorer také nepodporuje. Už nikdy. Totéž platí pro vlastnosti končící -override. Více na CanIUse.com. Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .