DIY trackball Ploopy má novou variantu Adept, na rozdíl od předchozích používá 44mm kouli, má symetrický tvar a šest tlačítek, snímač zůstává PMW-3360, novinkou je použití Raspberry Pi Pico, na kterém běží firmware QMK s podporou grafické konfigurační aplikace VIA. Předobjednávky jsou otevřeny za ceny 80-105 CAD.
Probíhá Meta Connect 2023. Společnost Meta představuje své novinky v oblasti AI a virtuální, smíšené a rozšířené reality. Představeny byly nové chytré brýle Ray-Ban | Meta a headset Meta Quest 3.
Eben Upton oficiálně představil (YouTube) nové Raspberry Pi 5 (YouTube). Je více než 2x výkonnější než jeho předchůdce, model 4B.
Byl vydán (YouTube) Counter-Strike 2. Nativně také pro Linux. Jedná se o největší technologický skok v historii této populární herní série.
Richard Stallman vystoupí v Praze s přednáškou Free Software And Your Freedom. V sobotu 30. září ve 14:30 na Pedagogické fakultě UK a v neděli 1. října v 18:00 hodin v rámci konference Hackers Congress Paralelní Polis.
Byla vydána verze 6 s kódovým název Faye linuxové distribuce LMDE (Linux Mint Debian Edition). Podrobnosti v poznámkách k vydání. Linux Mint vychází z Ubuntu. LMDE je postaveno na Debianu.
Byly publikovány informace o novém bezpečnostním problému pojmenovaném GPU.zip (paper, GitHub). S vlastním logem. Jedná se o možný útok postranním kanálem na grafickou kartu (GPU). Proces může "krást pixely" jinému procesu.
Projekt GNU dnes slaví 40. výročí. Přesně před čtyřiceti lety, 27. září 1983, Richard Stallman oznámil, že se chystá napsat s Unixem kompatibilní operační systém GNU (Gnu's Not Unix). Hlavní oslava a setkání hackerů probíhá ve Švýcarsku ve městě Biel/Bienne. Na programu je také přednáška Richarda Stallmana.
Byl vydán Mozilla Firefox 118.0. Přehled novinek v poznámkách k vydání, poznámkách k vydání pro firmy a na stránce věnované vývojářům. Vypíchnout je nutno automatický lokální strojový překlad webových stránek. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 118 je již k dispozici také na Flathubu a Snapcraftu.
Byla vydána nová major verze 15.0.0 softwaru OCRmyPDF pro přidávání textové vrstvy k naskenovaným PDF dokumentům (PDF/A). Přehled novinek v poznámkách k vydání. OCRmyPDF využívá pro optické rozpoznávání znaků (OCR) engine Tesseract.
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.
<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
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.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í.
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í.
$ 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.065sNení to spíš problém s tvou konektivitou? Nějaká Wi-Fi s občasným packet lossem?
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).
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…
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.
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(?)
a to je mu třeba říct ve stránce či skriptuProhlíž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ánkuZdroj? 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.
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.
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.
Protože v tom skriptu může býtAtribut 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?
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.
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.
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?
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.
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.
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…)
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).
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
Tiskni
Sdílej: