Dotaz: Čekání na www.argonit.cz

[Lol Phirae]

Načte se levý sloupec, cca 20 sekund jinak všude bílo, pak se načte zbytek webu. Co to sakra je, zas nějaká výtečná reklamní kosočtvercovina?

Odpovědi

[Jendа]

Nainstaluj rozšíření Live HTTP Headers, použil debug tool z NSA Chrome nebo Burp proxy, uvidíš tam, co to tahá. Mně to nedělá…

[Lol Phirae]

Kašlu na to, zlikvidováno na lokálním DNS serveru. Na tohle nemám náladu, thread byl míněn jako upozornění, ať to někdo spraví.

[manasekp]

taky jsem si toho parkrat vsiml, nevim co to z tama taha za svinstvo

[Šangala]

Jo je to přesně to co píšeš, je to tam 300let, dělá to často a nebýt toho tak se abíčko načítá vždy rychle a bez problémů, když to zabiješ máš po problémech.

Je to na nevhodných místech ve stránce (není to v hlavičce, nebo na konci a za uzavřenými kontejnery) a když to server nedává, tak se prostě stránka nedočte, byť obsah už je stažený, bo není pseudo-kompletní.

Padlo to tu vícekerát, někde jsem na to taky brblal.

[Bill Gates]

<script src="http://www.argonit.cz/tmp/64bit.js"></script>

K cemu to tam je ? Takovy druh javascriptu tedy neznam http://www.argonit.cz/tmp/64bit.js :D

http://www.w3schools.com/tags/att_script_async.asp

pak snad mozna jeste

<script type="text/javascript" charset='utf-8' src="https://go.eu.bbelements.com/bb/bb_one2n.js"></script>

ale tomu se async obvykle nelibi

[Max]

Nikdy jsem se s tím nesetkal a o problému vím poprvé :-/.
Zdar Max

[Šangala]

Děje se to celkem pravidelně, někdy je to jen sekundička, ale občas to překračuje únosné meze, je to klasický a velmi rozšířený neduh, který lze docela rozumě řešit. Vždy je jen otázka jestli jsou ty reklamy (nebo něco jiného) důležité, nebo ne a tedy se mají zobrazit v průchodu stránkou nebo až po načtení(, když už je to tak řešené, tak ve valné většině platí, že až po načtení).

Kdysi jsem to někomu ukazoval, tak jsem to teď švihl na web, kdyby to někoho zajímalo, vo-co-go.

[Luboš Doležel (Doli)]

Vzhledem k tomu, že jde o statický drobný soubor, si nemyslím, že by to zpoždění mohlo být páchané přímo jím. To spíš jen prohlížeč ukazuje na nesprávného viníka, jak už jsem to viděl mnohokrát. Odstranit to ze smluvních důvodů nemůžeme, i když to naprosto nefunguje.

To to spíš brzdí bbelements.com, který nám poskytuje reklamní systém.

Jinak vzhledem k tomu, že od začátku roku 2013 tu byla tuším jediná reklamní kapmaň (mimo výplňovku AdSense), by nás potěšilo, kdybyste reklamu neblokovali. Portál stále dotujeme z jiného byznysu, prosíme vás o nezhoršování jeho výhledů.

[Lol Phirae]

Jinak vzhledem k tomu, že od začátku roku 2013 tu byla tuším jediná reklamní kapmaň (mimo výplňovku AdSense), by nás potěšilo, kdybyste reklamu neblokovali. Portál stále dotujeme z jiného byznysu, prosíme vás o nezhoršování jeho výhledů.

O tom bych možná mohl uvažovat, kdyby realizace reklamy nevypadala tak, jak vypadá. Tzn. půlminutové zpoždění při načítání stránky. Pokud něco "naprosto nefunguje", tak smlouvu vypovím, pokud jsem si to ve smlouvě neošetřil, jak jsem blbec a holt se budu muset povrtat v kódu tak, aby ta přiblblá reklama neničila můj vlastní produkt (tzn. tuto webovou stránku).

A popravdě mi je jedno, jestli to brzdí bbelements.com, argonit.cz nebo nějaký jiný šmejd, fakt nebudu půl minuty čekat na načtení stránky. Inzerenti si za to můžou sami a vydavatelé taky, pokud jim tohle neustále tolerují.

[Luboš Doležel (Doli)]

argonit.cz je nás vlastní server, takže nevím, co komu tolerujeme.

[Lol Phirae]

Jasně, takže jste "smluvně" vázání udržovat vlastní "naprosto nefunkční" reklamu, která zdržuje načítání stránky o půl minuty. Bezva. Jsem rád, že vím, na čem jsem. Něco blbějšího už by se nenašlo?

[Luboš Doležel (Doli)]

Tenhle soubor určitě nic nezdržuje. Buď je problém v něčem jiném (např. bbelements.com) a vám to ukazuje nesprávně (prohlížeče to dělají často), nebo je problém např. s vaším IPv6 tunelem.

[manasekp]

ceka to na argonit, ne na bbelemments

[Lol Phirae]

Ano, taky vidím, že to čeká na argonit.cz, ale tohle bylo hlášeno už před drahnou dobou, a samozřejmě za pitomce byl opět ten, kdo to nahlásil. Stránka se nenačte, protože se smluvně propaguje něco, co vůbec nefunguje. A pak si zahekáme, že uživatelé blokují reklamu. Ne, to vážně nemá smysl.

[Luboš Doležel (Doli)]

A můžu vidět nějaký důkaz? Opravdu nevidím důvod, proč by to mělo čekat při poskytování jednoho souboru z desítek statických souborů, co se stahují.

[manasekp]

opravdu nevidim duvod proc bych ti mel posilat nejaky dukaz. Je to rozbite, prohlizec rika ze ceka na argonit, lhat nema duvod imho.

[Šangala]

Já tedy Firebug-u věřím, nyní, kdy je to OK a běhá to, se u mě pohybuje na ≈200-300ms, ale dostal jsem jej i za 800ms, bbelements.com je výrazně horší běhá to i přes 1sec a k té 1sec se blíží často. Ale je fakt, že je tam spousta dalšího „smetí“, jako statistiky z PL apod. - nevím jestli se na to čeká nebo ne, bo zběžným pohledem to fčul, když to chodí OK, nepoznám.

Osobně reklamu neblokuji vůbec, beru to jako „daň“, ale několikrát už mě to napadlo a jednou jsem to i udělal (pak zas zrušil), právě proto, že se natahuje víceméně synchronně, a bílou stránku sem tam vídám (řekněme 1× za 2 měsíce), když se člověk podívá tak zjistí, že celý zdroj už je tady, ale jen to čeká na nějakou reklamní blbost, která se prostě nenačte, takže hotovizňa - to je docela opruz. AdSense je v klidu, to je víceméně asynchronní.

[Luboš Doležel (Doli)]

I to je dost podezřele špatné. U mě to wget dává za 75ms a nijak se to výrazně nevychyluje.

$ time wget www.argonit.cz/tmp/64bit.js
--2014-04-13 22:02:28--  http://www.argonit.cz/tmp/64bit.js
Resolving www.argonit.cz... 37.46.80.55, 2a03:b780:1:4:216:3eff:fe00:a37
Connecting to www.argonit.cz|37.46.80.55|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3288 (3.2K) [application/x-javascript]
Saving to: ‘64bit.js.8’

100%[=====================================================================================================================================================================================================================================>] 3,288       --.-K/s   in 0s      

2014-04-13 22:02:28 (879 MB/s) - ‘64bit.js.8’ saved [3288/3288]


real    0m0.065s

Není to spíš problém s tvou konektivitou? Nějaká Wi-Fi s občasným packet lossem?

[Šangala]

Příloha:

• process.png (123235 bytů)

Ne-ne, to bylo na drátě (žádná super linka), fčuk su na WiFi (žádná super linka), a wget-em samostatně su na < 100ms, jenže ono se toho při načítání stránky tahá roj (například na tuto stránku to fčil bylo ≈70 požadavků, při vyprázdnění cache rovných 100 požadavků), takže není nic špatně - uváděl jsem časy při načítání stránky. Přikládám začátek výpisu po druhém refreshi po vyprázdnění cache (ale fčul to jede, takže není co řešit) načtení všeho bylo za 4sec (stránka viditelná asi za 1sec), při vyprázdněné cache něco přes 7sec (stránka viditelná pod 2sec).

[Luboš Doležel (Doli)]

No, potřeboval bych to vidět, až to pojede špatně. Server, kde ten soubor je, je aktuálně nevyužitý, takže není vytížený. Proto vidím spíš problém ve vaší konektivitě a nějaké ztrátě paketů.

[Šangala]

Příloha:

• process2.png (164811 bytů)

Pro analýzu „proč a co nedává“, rozhodně, pokud to bude v blízké době a nezapomenu na to, a bud moci tak to se juknu a sjedu to.

Fčul su na dost slušné lince a plný refresh je vidět v příloze (naprosto v pohodě).

Prezentovat myšlenku, že si myslím, že takové věci (reklamy apod.) mají být asynchronní asi netřeba…

[2X4B-523P]

tohle se mi projevovalo na openvpn přes gprs, na broadbandu a 3g agronit.cz ani neproblikne, na rozdíl od google anal.

[Šangala]

Jenže „google anal“ nezabrání zobrazení stránky - jede na pozadí.

[2X4B-523P]

myslím že zrovna rekonq mi čekal s renderováním právě na google anal., u iceweaselu mi to zas dlouho po načtení stránky zobrazuje, že čeká na google anal., prostě to není ideální a vadí to napříč internetem, na rozdíl od toho, že někomu občas lagne agronit.cz... další se za google řadí facebook, to jejich tlačítko se tak rozšířilo, že už brzdí i to samo o sobě...

[Šangala]

Pokud to prohlížeč neposlouchá a čeká, tak s tím nic nenaděláš.

U Iceweasel-u, je přece rozdíl mezi tím, jestli to stránku zobrazí a něco dočítá a informuje o tom - to tě víceméně neomezuje, nebo stránku vůbec nezobrazí, což je docela naprd.

Nepopírám, že to mohlo čeká na něco jiného než argonit.cz, protože browsery opravdu někdy zobrazují kraviny (v liště), ale rozhodně to čeká (v uvedeném případě) na něco, co je vyžadováno pro načtení stránky (já jsem to vždy vyřešil jen vypnutím JS a dále jsem po tom nepátral - což byla chyba).

Jen pro zajímavost, aktuální pokus, běžný refresh stránky bez javascriptu je po 'onload' 1.5sec a plné načtení 1.51sec, při zapnutém javascriptu po onload 2.4sec a plné načtení 4.19, rozdíl mezi 1.5 a 2.4 je to co lze eliminovat, sice ne plně, protože ty dotazy na ty zdroje(js-ka) tam budou vždy a zatíží zdroje(linku/cpu). Rozdíl mezi těmi dvěma čísly 2.4 a 4.19 je to co běží asynchroně - kdyby neběželo, tak by se na zobrazení muselo čekat těch 4.19sec.

[pavlix]

Ony na straně serveru asynchronní nejsou? Máš namysli nějakou konkrétní chybu, se kterou může Luboš něco dělat? Osobně mám pocit, že největší problém s reklamami je (1) na straně prohlížečů a (2) na webech, které závisí na javascriptovém eventu kompletního načtení stránky.

[Šangala]

Nemám na mysli chybu - je to spíš zvyk. A udělat(?) - zjednodušeně zařídit aby se na vše co není potřeba nečekalo, ale dočetlo se až dodatečně, výše jsem dával ukázku chování.

Otázkou je co vnímáš pod pojmem asynchronní v tomto kontextu (jde o to aby browser na nic co nepotřebuje nečekal a to je mu třeba říct ve stránce či skriptu), pokud je tag script s atributem src vložen někde v kódu, tak prohlížeč (obvykle) čeká a potřebuje stažený tento zdroj, než bude renderovat stránku. Pokud tento script je jen kraťoučký skript, který se nemění (tedy je cache-ovám) a jen vyvolá asynchronní akci načtení reklamy, tak se na nic nečeká a i pokud reklama nejde a nejde. Atribut async rozumí většina browserů, ale je to dle specifikace html5, jestli se nepletu, a pak browser nečeká a stránku zobrazí i bez něj.

Bodu 2 přesně nerozumím, pokud se reklama načítá až na event kompletního načtení stránky (onload), tak to je super, ne(?)

[pavlix]

a to je mu třeba říct ve stránce či skriptu

Prohlížeči, nečekej na nic, co nepotřebuješ.

Lepší?

pokud je tag script s atributem src vložen někde v kódu, tak prohlížeč (obvykle) čeká a potřebuje stažený tento zdroj, než bude renderovat stránku

Zdroj? Důvod?

Atribut async rozumí většina browserů, ale je to dle specifikace html5, jestli se nepletu, a pak browser nečeká a stránku zobrazí i bez něj.

Existuje nějaký důvod, proč by mělo být něco takového vůbec potřeba?

Bodu 2 přesně nerozumím, pokud se reklama načítá až na event kompletního načtení stránky (onload), tak to je super, ne(?)

Pokud se na tento event naopak načítá kód bez kterého nefunguje navigace na daném webu, tak už to tak super není.

Jen projistotu... Neptám se na common practice, to přenechám jiným, kteří se dynamickými prvky webu aktivně zabývají. Zajímají mě důvody, proč nestačí opravit prohlížeče.

[Šangala]

Lepší?

Pokud tomu tak prohlížeč bude rozumět, klidně, ale zatím musíme volit jiné praktiky.

Zdroj? Důvod?

Tak to prostě je, ukázku jsem už 2x odkázal.

Existuje nějaký důvod, proč by mělo být něco takového vůbec potřeba?

Filosofická otázka. Možná proto, že stránka je vyhodnocována shora dolů, a pokud někde je vložen skript a definuje fci a dále je vložen další skript, tak tu fci může použít. A pokud se ptáš mě, tak já bych rád u každého externího zdroje rád měl možnost definovat kdy se má načíst, nejenom asynchronně, ale přímo bych chtěl říct (vložit atribut), načti se až po načtení DOM a to s prioritou XY.

Pokud se na tento event naopak načítá kód bez kterého nefunguje navigace na daném webu, tak už to tak super není.

Ale to už jsme jinde…

Jen projistotu... Neptám se na common practice, to přenechám jiným, kteří se dynamickými prvky webu aktivně zabývají. Zajímají mě důvody, proč nestačí opravit prohlížeče.

Něco jsem už napsal o pořadí a řekl bych, že to není oprava, ale změna chování a to jsem i napsal jak bych to chtěl já, default ať se to chová ja se to vždy chovalo, ale chtěl bych to mít explicitně možnost definovat, bylo by pak možné udělat web rychlý, protože když valí 100 požadavků naráz a i když se na ně nečeká, tak přece jenom to trvá déle než kdyby jich běželo třeba jen 10 (html+css+nutné js+nutné obrázky) a zbytek až pak.

[pavlix]

Možná proto, že stránka je vyhodnocována shora dolů, a pokud někde je vložen skript a definuje fci a dále je vložen další skript, tak tu fci může použít.

Konečně něco, co dává trochu smysl smysl. Jestli to správně chápu, jedná se tedy o pozůstatek starých dobrých prasáckých javascriptů, které se tak nějak míchaly se stránkou jako takovou. Jo, pak asi dává smysl rozvazovat zpětnou kompatibilitu explicitně.

Dokonce bych si troufnul doporučit, aby asynchronně načítané skripty vůbec nesdílely globální namespace.

[Filip Jirsák]

Atribut async rozumí většina browserů, ale je to dle specifikace html5, jestli se nepletu, a pak browser nečeká a stránku zobrazí i bez něj.

Existuje nějaký důvod, proč by mělo být něco takového vůbec potřeba?

Protože v tom skriptu může být document.write(), bez jehož provedení je celý zbytek zdrojového kódu stránky k ničemu. Proto má tag skript atribut defer=defer, který říká, že ve skriptu žádný document.write() není a zpracování skriptu se má odložit až po rozparsování stránky.

Atribut async je podobný v tom, že neblokuje další načítání stránky, ale zpracování skriptu se spustí hned, jakmile je skript dostupný, ne až po rozparsování stránky.

Bohužel při tom asynchronním načítání skriptů se těžko řeší závislosti, protože pořadí načtení skriptů je pak nedefinované. Můžete do skriptů přidat kód, který vyvolání nějaké akce odloží až po té, co se načtou závislosti. Jenže takový kód není úplně jednoduchý, takže je dobré jej vyčlenit do nějaké knihovny. Tím pádem máte zase závislost na té knihovně…

Navíc ty skripty pro neblokující načítání často používají document.write(), takže na ně to asnychronní nebo odložené zpracování nejde použít. Tam se spoléhá na to, že ten bootloader bude velmi malý a ideálně nakešovaný v prohlížeči.

[Šangala]

Bohužel při tom asynchronním načítání skriptů se těžko řeší závislosti, protože pořadí načtení skriptů je pak nedefinované. Můžete do skriptů přidat kód, který vyvolání nějaké akce odloží až po té, co se načtou závislosti. Jenže takový kód není úplně jednoduchý, takže je dobré jej vyčlenit do nějaké knihovny. Tím pádem máte zase závislost na té knihovně…

V případě reklamy a běžné funkce stránek, jaké závislosti(?). Pokud jsou tam nějaké aplikační závislosti, tak to patří jednoznačně do knihovny, o tom to také mimo jiné je, že je pak jen jeden požadavek na zjištění aktuálnosti zdroje a ne „dvacet“ zdrojů, kde se na každé musím browser zeptat. A knihovnu obvykle patří do hlavičky - jeden dotaz na aktuálnost to nezabije.

Navíc ty skripty pro neblokující načítání často používají document.write(), takže na ně to asnychronní nebo odložené zpracování nejde použít. Tam se spoléhá na to, že ten bootloader bude velmi malý a ideálně nakešovaný v prohlížeči.

V případě reklamy (a většiny jiných užití) bych řekl, že se spíš používá o vkládání obsahu do již existujícího prvku (innerHTML), tedy jde jen o to aby prvek existoval, měl nastavenou velikost a obsah se kdykoliv donačte.
document.write() je inline a nemůže být zpracován asynchronně a jeho využití je velmi specifické a téměř nikdy potřebné - de-facto narušuje zpracování DOM. Osobně bych to označil jako nepříjemný pozůstatek dob hluboko minulých.

[pavlix]

V případě reklamy je tak jako tak nejlepší žádné skripty nenatahovat a namísto toho natáhnout samostatný objekt, který se o tu reklamu stará. Měl jsem za to, že se to tak vždy dělalo a tento způsob je pokud vím plně asynchronní by default.

[Šangala]

To je moc vágní, prakticky?

[pavlix]

Co přesně je na tom nejasné?

[Šangala]

Píšeš:

V případě reklamy je tak jako tak nejlepší žádné skripty nenatahovat a namísto toho natáhnout samostatný objekt, který se o tu reklamu stará. Měl jsem za to, že se to tak vždy dělalo a tento způsob je pokud vím plně asynchronní by default.

Co má být tím objektem, když to není JavaScript?
Jak takový objekt pracuje asynchronně?

[pavlix]

Dle potřeb reklamy může takový objekt být od obrázku, přes samostatný HTML dokument až po nějaký flash. Prostě kterákoliv z mnoha technik, co se používaly pro objekty, které nepotřebují přistupovat ke zbytku stránky.

[Šangala]

Jo takto, to jsou všechno techniky, které se moc nepoužívají, protože mají malou flexibilitu a dávají nedostatek informací - „oni“ tě potřebují šmírovat aby ti nabídly to co potřebuješ ;).

Dodavatel reklamy chce mít kontrolu, co nabízí v reklamě a kam se dostaneš po kliku.
Jo reklama na konkrétní casino, může být ten obrázek, ale počítá s tím a tu reklamu umístníš do stránky „natvrdo“.

Pokud máš mít na stránce 3 reklamy stejného zdroje, tak je lepší natáhnou jeden neměnný skript, nachystat 3 kontejnery (DIVy) a ty na závěr asynchronně naplnit, protože řídíš kdy i co i kam i odkud i čím atd...

Když jsou to obrázky, musíš dávat v tagu img do src třeba timestamp aby se nekešoval a jak jsem psal na začátku, co se stane na klik na obrázek nezařídíš obrázkem.

[Filip Jirsák]

HTML bohužel stále nepodporuje vložení části stránky (include, např. XInclude z XML). Takže vložit HTML dokument nejde. Sice by se tím odstranily ty příšerné skripty pro vkládání reklamy a měřících kódů, podstatně by se tím zrychlilo načítání většiny stránek, ale porušila by se tím zpětná kompatibilita, takže se radši bude vymýšlet další asynchronní JavaScript a komprese HTTP hlaviček. (Ne že by zrovna tyhle dvě věci nebyly užitečné, ale include by pomohlo mnohem víc).

[Šangala]

Nemyslím si, že by to bylo řešením, vždy je to totéž je jinak zaobalené, pokud tyto vložené kódy budou synchronní, což mi include evokuje, tak to nic nevyřeší bude se buď čekat na ten zdroj nebo na jeho případné provedení.

Nevím jestli další asynchroní javascript - to lze provést několika způsoby a už dávno šlo, jednou je třeba dynamické informace (reklamátoři to chtějí) musí to být dynamické.

Pokud by to mělo být na úrovni html, tak se zopakuji, protože se poslouchám rád ;), tak by každý tag, odkazující externí obsah mít atribut „loadWhen“ a „loadPriority“.
Obvykle se stránka stejně skládá na serveru, kde snad v každém jazyku taková konstrukce existuje, takže nevím čemu by to pomohlo.

[Filip Jirsák]

Pokud by bylo povoleno vkládat jenom XML fragment, může se hlavní stránka klidně parsovat dál, pak se rozparsuje vložený kód a ten se jenom vloží na správné místo do DOMu.

Právě proto, že se stránky obvykle skládají na serveru a klientovi se posílá pořád to samé s malou obměnou. Klient tedy může mít většinou nakešovanou a načítat jenom to změněné. Třeba při editaci komentáře jsem na stránce, kde je vložená hlavička a patička, která se nemění měsíce, je tu vložený sloupeček zpráv, které se mění jednou za pár hodin (nebo třeba minut, pokud chci aktuální i počty komentářů), je tu nápověda k formátování, která se také nemění, a nakonec je tu text komentáře, na který reaguju, který už prohlížeč koneckonců také před chvílí načetl. Takže jediné, co se oproti předchozí stránce změnilo, je částečně layout, reklamy a pak titulek vyplněný ve formulářovém políčku. Všechno ostatní se mohlo nahrát z cache.

[Šangala]

A jsme u AJAXu, ale jinak ta myšlenka už tu byla a mně ta myšlenka frame a framsetů byla blízká a považuji za chybu její opuštění, uvítal bych jen rozvinutí možností layoutu a lepší identifikace frame než přes „target“, který byl společný pro window i frame, bohužel už se s takovým stylem práce ani nepočítá .

[Filip Jirsák]

AJAX ne, stačil by AX

[Šangala]

Stál není nic špatně, ale když tady o tom tak píšeme, tak jsem udělal dvě věci, hlídal jsem to a podíval se na obsah, mám dva poznatky.

První je ten, že 64bit.js soubor se dost často stahuje třista-čtverka tam je jen občas při rychlém refreshi, de-facto se hlásí jako změněný furt i když není rozdíl v obsahu.

A druhý: „co to je?“ (Nejsem v tom nijak zběhlý, tak jsem to moc nepobral - jakýsi zběsilý přihlašovací formulář, který ani není to co by tam člověk očekával, tedy jen JavaScript…)

[Pavel Stárek]

Obvykle mi toto dělal server spir.hit.gemius.pl hrozná věc, no, eliminoval jsem to adblockem. A jak vidno ze screenshotu jakýsi gemiusácký javascript tam je.

[Nobody]

S nacitanim webu nemam potize. Je ale fakt, ze AdBlockuju argonit, gemius, bbelements i google analytics.

[xkucf03]

Za sebe můžu říct, že mi to z argonit.cz stahuje rychle (po IPv6) resp. zhruba stejně rychle jako zbytek Ábíčka a nějaké zasekávání jsem nezaznamenal.

Ale uvítal bych, kdyby se i tady používalo HTTPS – abych neměl smíšený obsah a ošklivý vykřičník v adresním řádku (Spojení částečně zašifrováno).

[Luboš Doležel (Doli)]

Ale uvítal bych, kdyby se i tady používalo HTTPS – abych neměl smíšený obsah a ošklivý vykřičník v adresním řádku (Spojení částečně zašifrováno).

AdSense bohužel HTTPS doteď neumí, takže i když bych vyřešil ten argonit.cz, varování by zůstalo Je to dost často žádaná funkce, ale Google stále nic.

[jmeno]

adsense https umi viz https://support.google.com/adsense/answer/10528?hl=cs

[Luboš Doležel (Doli)]

Díky za upozornění, to je novinka. Dřív psali, že má člověk smůlu.