Pojďme programovat elektroniku: Jak to, že je průměrná webová stránka stejně velká jako Doom?

Už na dialupu jsem používal webwasher který pouze blokoval obrázky o velikosti reklamy. Tehdy ještě na Netscapu :) a to byl rok 97-98

Zni to logicky, ale praxe tomu bohužel typicky neodpovídá.

Otázka je jaká praxe. Rychlost stránek a optimalizace fotek je samozřejmě jen jedna z mnoha věcí, které určují virtuální PageRank u každé stránky nějakého webu. Pak ještě záleží, co tam je, jak je obsah originální a užitečný, kolik a jakých vede odkazů z něj a na něj atd.Protože stejně tak jako jsou bonusy v pageranku, tak jsou taky mínusu a dokonce PENALIZACE.Je to jako v životě - můžete mít šest vysokých škol, skvělou kariéru, vlastní firmu a Nobelovu cenu Míru, ale když pak JEDNOU rozsekáte dětskou školku motorovkou, tak dostanete trest mrti nebo doživotí a jakékoliv Vaše kvality už nikoho nezajímají.Stejné je to i u SEO - můžete si skvěle optimalizovat web po technické stránce, mít tam luxusní obsah a pak si to vezme do rukou nějaké pako, které tam udělá "spam" ve formě "sex, sex, sex..." 3000x ve skrytém textu a Google Vám loupne okamžitě penalizačku +500< pozic až vyřazení z indexu a jste v p*deli! Navíc zástupci Google se vyjádřili už před dvěma lety, že budou sahat k mnohem větším mínusům, penalizacím a dokonce trvalým vyřazením z indexu... Takže ono stačí, aby takový majitel stránek nebo nějakého eshopu "přestal vyhazovat peníze za drahého konzultanta" a zaplatil si "zaručeně 1. místo ve vyhledávačích" z Bazoše za 2000 Kč jednorázově, překvapivě ho skutečně může na některá keywords získat na nějakou dobu a pak jednou šmitec a může web celý zavřít Nebo k tomu pustí nějakého ťulpase, ten mu tam klidně i chce pomoct, ale udělá tam nějaký nesmysl, třeba různé duplicity atd. a hned ho to hodí třeba +10 pozic.Každopádně ono je to dnes dost propojené, protože jedničky v businessu jsou zároveň i jedničky v SERP vyhledávačů. Jasně, je naivní myslet si, že udělám "nějakou tu optimalizaci" a bude na prvním místě, ale rozhodně se vyplatí na to nekašlat, protože je fajn být třeba alespoň na první stránce než na osmé - tedy úplně mimo organické získávání nových uživatelů/zákazníků.

tak samozřejmě, ale vhodně nakonfigurovaný server komprimuje vše, statický obsah i javascripty přes gzip a ještě lépe s http/2

Netlačí tě, oni to dělají všichni

Kdyby 2,5MB, titulka živě má dokonce 4MB: http://i.imgur.com/yX5P6ZZ.png... a ještě jsou ty skripty rozeseté mezi víc jak dvacet domén reklamních serverů, google, adobe a nevím co ještě.

chceš tím snad říct, že když se lajnou přenášej JPG, tak pro zobrazování v panelu brouseru se to překódovává do velkýho BMP? není to kravinismus???
když mám nějakou fotku v JPG na disku a zobrazím si ji v systémovým prohlížeči obrázků, tak se pro to zobrazení taky přepočítává do BMP? že nepřepočítává? tak proč se stejně nechová brouser?

Lekce češtiny: | bych, bychom, byste; abych, abychom, abyste; kdybych, kdybychom, kdybyste... rozhodně NE "aby jsme" či "kdyby jste" | standarD (standarDní/ě) | perMaNeNt

On jaksi monitor neumí jpg zobrazit, potřebuje pixely hezky jeden po druhym, takže něco v kompu to musí rozbalit do bitmapy, ať už to zobrazuje browser nebo cokoli jinýho.

Obrázek v JPEG, GIF, PNG se musí vždy nejdříve dekomprimovat. Sice na to lze použít GPU (grafický čip), ale výsledek bude nekomprimovaná bitmapa někde v paměti (nejlépe v paměti blízko GPU, tj. v paměti grafické karty, resp. přímo ve framebufferu). Odtud to GPU/RAMDAC čte, když vytváří obraz pro monitor. Framebuffer může být komprimován, ale to je jiný typ komprese a ten mezivýsledek v bitmapě tam stejně někde aspoň chvíli bude. A protože webový prohlížeč (nebo prohlížeč obrázků) do té paměti sahá, musí to být jemu přístupná paměť, a proto bude i vidět v čísle, kterým systém oznamuje paměťovou náročnost programu.[1] Tj. vlastně to až takový problém není, když je prohlížeč nenažranej (spíš je to dobře). Prohlížeč si také musí uchovávat kopie dat i mimo grafickou paměť - např. aby byl rychlý, když zmáčknete tlačítko "zpět" nebo aby měl předem nachystaná data, ještě než kliknete na odkaz (prohlížeče přednačítají stránky, na které byste mohli přejít).[1] ve Windows se běžně používají dost špinavý triky, aby zabraná paměť byla připsána na vrub jinému programu/knihovně (než ve skutečnosti), čímž se jeví například produkty Microsoftu "méně nenažrané", než jsou ve skutečnosti (včetně prohlížečů od MS).

Sice teď budu srovnávat jablka a hrušky, ale vemte si například moderní komprimace u nových video kodeků, obrázků nebo nový způsob aktualizace aplikací od googlu. Uživatelů a obsahu každým dnem přibývá a s tím také celkové požadavky na bandwidth. To že ve výsledku jeden uživatel přenese u zdánlivě stejně kvalitního/velkého média menší množství dat, neznamená, že by jeho v jeho počítači byl méněcenější výsledek. Jednoduše se přesouvají "náročnější výpočty" na stranu klienta - se stoupajícím výkonem a efektivitou většiny koncových zařízení bych řekl, že to ničemu nevadí.
(Já například u WebApp, která periodicky aktualizuje stav pomocí json o velikosti cca 400B+http header snížil přenesená data na 150B vč http headeru a to díky zazipování>base64encode [cache, aby server tento úkon nemusel pořád dokola provádět pokud nedošlo ke změně json zdroje] a na klientu potom je, aby přijatá data dekódoval a rozbalil - "výsledek je stejný", množství přenesených dat cca 3x menší)
(Ty aktualizace aplikací viz http://www.zive.cz/bleskovky/aktualizace-apl... ...

oprava linku, odkaz zahrnul konec zavorky http://www.zive.cz/bleskovky/aktualizace-apl... ...

PS: Ještě bych mohl zjistit jestli by tento krok nebyl zbytečný na http2/SPDY, nejsem si úplně jistý, jestli tyto protokoly komprimují jenom headery, nebo i data. Potom by asi zipování odpovědi bylo zbytečné.

Zobraz jpeg v irfane a zistíš koľko RAM zaberá (písmenom "i")

A to je právě chyba začátečníků. Jasně, nacpat si na web 4 js frameworky zní cool a začátečník si to ospravedlní tím, že se to stáhne jen jednou.Problém je v tom, že většina komerčních webů má míru okamžitého opuštění dosti vysokou a dost bastlířů používají JS na vše a tak trvá někdy i několik sekund, než se to všechno spojí a zákazník vidí výsledek. A když už jsem za ten proklik zaplatil, tak z toho chci vymačkat maximum a nevidím jediný důvod, proč by měl potencionální zákazník čekat dlouhé vteřiny, když se konkurence načte mrknutím oka.Pravidlo na závěr zní, že když to neumím, použiji javascript.

Mno v podstatě je myšlenka správná. Ale v tomto případě se zpracování může protáhnout o pár ms. Ale rozhodně to nemá takový odběr jako samotný přenos, který může být (podle použité metody přenosu) energeticky náročnější až o několik řádů. Mno a to se užna výdrží pozná.

Samozřejmě jsem měl namysli "odečti 83,75" jen rychleji klikám než čtu .

Správně je, že nejdřív se odčítá těch 63.75 dokud se to nedostane do intervalu a nakonec -20.
No a jak sám vidíš, desítkový zápis je v tomto případě mnohem složitější...

Nemohu souhlasit, v desítkové soustavě se mi to jeví snáze pochopitelné pro laika než hrátky s binárními čísly.
Myšlenka pro zpětné dekódování byla taková že:
pokud je číslo v intervalu 64-127 pak od něj odečtu 83,75 = změřená teplota
pokud je číslo v intervalu 128-191 pak od něj odečtu 147,5 = změřená teplota
pokud je číslo v intervalu 192-255 pak od něj odečtu 211,25 = změřená teplota
Měl jsem za to, že je to dostatečně pochopitelné pokud uvedu pouze první případ..

No jo, jenže v tom tvém příkladě si s binárními čísly hraješ taky, jen to navíc ještě převádíš do desítkové, takže pro laika to vypadá jako hausnumera. Aby to pochopil, tak mu to stejně musíš všechno vysvětlit. Jiná věc by byla, kdyby třeba teplota byla <50 a přičítaly by se násobky 50, pak je to echt desítkové a jasné.Tvoje verze je oproti binární
(temp << 2) |(int)(fract *4)
a zpátky
temp / 4.0
opravdu neskutečně složitá.

Hmm je to asi o úhlu pohledu, mně je to jasné na první pohled a nepřipadne mi to složité, vše co jsem popsal v desítkové se vlastně udělá v binární - na straně čidla, dokonce jsem eliminoval krok, kdy autor posunuje výsledek přepočtu celé hodnoty teploty o dvě pole doleva. Já prostě jenom přičítám sedmý nebo osmý bit a nebo oba. Kdežto autor stejně pracoval s prvními dvěmi bity... Vlastně místo abych násobil 4 "|(int)(fract *4)", tak násobím 256 a přičítám k celočíselné hodnotě teploty bez posuvu.
Popsat dekódování na straně přijímače podmínkami mi přišlo nejsrozumitelnější, přecijenom ne každý holduje počtům ve dvojkové soustavě.
Každopádně netvrdím, že moje řešení je nejlepší ale jako alternativa pro pochopení možní poslouží.

A ještě se mi ztratil "interval 64 - 127" ..

V tom článku bych řekl, že dokazuje, že to minulosti nepatří.Jinak mě fascinuje tohle rozdělování na kodery, programatory a já nevim co. Nepoužívám binární data, nejsem programátor... Tak to slyším /čtu prvně...
Je na to aspoň nějaká mezinárodně ustanovená definice, nebo je to jen vycucaný z prstu?
Já mám jinou definici.
Pro mě třeba je kodér ten, který nenavrhuje strukturu/architekturu programu, ale jen dostane zadání a nabuší/nakódí dané zadání, přičemž může při tom klidně používat i ty binární data.

Já to vidím tak, ze kodér je jednoznačně lepší. Kodér je v telefonu na generálním štábu zatímco programátor je v pračce.

Jen malá připomínka ohledně "nejlépe poslat co nejvíce dat a to nejméněkrát" - to nemusí platit vždy protože se zvyšující se délkou přenosu roste riziko, že bude přenost zarušen nějakým dalším signálem a bude se muset opakovat.
Pokud byste takto sbíral a sbíral a sbíral, a pak chtěl naráz vysílat třeba minutu v kuse, je dost pravděpodobné, že byste data nikdy neodeslal protože by se pokaždé vyskytl nějaký kraťoučký zádrhel a musel byste začít znovu. Proto je třeba najít vhodný poměr mezi velikostí a rizikem rušení, který není možné obecně stanovit (v silně zarušeném prostředí logicky budou třeba kratší zprávy než uprostřed divočiny bez rušení)

Once, I was a Vecernik. Then I became a pony...

Jo, jenže naprogramovat v asm jednoduchý systém rozbalovacích menu na didaktika m mi zabralo několik dnů - teď je to v ms vizuálku záležitost na pár kliknutí.

Kdo dal minus ani nezna demo scenu. Tohle je taky 64kb (napsano v roce 2000): https://www.youtube.com/watch...

:[Xsoft]: - Let's Dance Dance Revolution ::

Presne, to bola doba optimalizacii. Kde kazdy bajt mal svoj zmysel a opodstatnenie. Dnes na to nie su prostiedky a ani cas. Radsej investovat do vacsej ram, disku, cpu ako do ludi a casu, ktory by bol na to potrebny vyladit do takejto podoby. Kym by sa to finalizovalo, konkurencia by bola uplne kdesi inde a produkt by castokrat nenasiel uz uplatnenie (sad story).
Inak pani, kde to zijete ze 64kB intra
Dnes uz ficia 4kB intra a to je pocin (zdrojak mensi ako Vasa ikona na ploche)
Vytaz 2016 ;)
https://goo.gl/e5Z1Rn...
Inak boli i stranky, ktore sa tomuto venovali no zanikli. Priklad za vsetko. Riesenie v sutazi na sudoku zadanie ... 67 byte! Potom sa toho este ktosi chytil a sup to na 62 byte !
B4 3F 8B D5 CD 21 91 43 88 02 4E 78 F7 B8 31 40 80 3A 2E 75 F5 8B F9 4F 60 78 ED 38 03 75 11 97 D4 13 6B C0 0B 96 43 7B F7 33 C6 A9 C0 E0 7E 02 F6 E4 61 70 E2 C6 02 2E 3C 39 74 F6 EB D1
Jednotlive kola a zadania (vratane sudoku)
https://goo.gl/OGUQ1T...

Jej, nostalgie - a ta hra po seriovem kabelu proti kamaradovi... :)

JJ, a marná snaha o přistání ...
nechápu jak všechnu tu grafiku dokázali nacpat do těch 100 kB - dneska by se do toho nevešlo ani úvodní logo ...

Jo, vás jsem zaregistroval jako takzvanou samozvanou autoritu i v článcích od P. Tronnera, zejména u počítačů Z80 kompatibilních. Působíte na mě dost arogantně.

Mě nejvíc fascinuje kombinace baterie + hardware + software v sondě Voyager. Po čtyřiceti letech provozu a daleko od naší sluneční soustavy, v téměř absolutní nule a bez slunečního záření pořád přijímá příkazy a odesílá informace. Klobouk dolů.

noo jeste to zareni, baterie je nuklearni.
je neuveritelny s cim vsim pocitaji.

První je správně. Jak ale podotýkáš, jde to i způsobem, že to píšeš jako prase a pak dokupuješ RAM... jenže pak se ti klidně na produkčním systému může stát, že ti taková aplikace žere stovky GB RAM a padá, protože jí má stále málo, právě díky tomu jak je prasácky napsaná, plná memory leaků apod...U aplikace typu "malování" to nikdo řešit nebude, u aplikací např. pro sklady/logistiku, kde každá minuta výpadku je klidně několik milionů peněz ztráta, to už asi jen tak neprojde.

EET... Jinak já myslím, že on to zas tak extrémně nemyslel. Prostě až takovéto optimalizace na urovni bitů-bajtů nemá ani moc smysl u nějakých mamutích projektů. Ale to neznamená, že by měli vývojáři psát jako prasata. Třeba raději déle rozmyslet návrh struktury programu než jít hned zbrkle kódit, nebo optimalizace dotazů do databáze apod.

Systémy státní správy bohužel spadají v naprosté většině do kategorie "od prasat", tam se na nějakou stabilitu a rychlost nehraje. Když se to vysere, tak ztráty zatáhne daňový poplatník.

Tak je potřeba najít nějakou rovnováhu. Některé věci se nedají škálovat do nekonečna. Twitter takto škáloval až už bylo serverů neúnosně mnoho. Pak musel přepsat backend z Ruby do Scaly.http://highscalability.com/scaling-twitter-making-tw... ... Asi se dá namítnout, ze Twitter je extrém, ale platí to i v malém měřítku. Můžu rozšířit paměť, přidat CPU, ale těžko něco udělám s I/O (ať už mezi pamětí a CPU, nebo na Internetu, kde nezáleží jen na mém připojení...

To víte, lidi si to líp představí v snadno představitelných "jednotkách" :D

Drobná narážka na to, že při reloadu stránky živě a stažení Dooma se přenese zhruba stejné množství dat (~2.4MB)

Asm mi přišel strašně cool na didaktiku - dalo se tím dosáhnout neskutečných věcí fungujících neskutečnou rychlostí ... ve srovnání s basicem. Na moderních počítačích mi asm přijde jako nesmysl - dokonce jsem četl, že kompilátory produkují tak dobrý kód, že jej jen málokterý programátor dokáže na úrovni strojového kódu překonat.
Teď jsem si zrovna pro svoji překladatelskou práci napsal pár prográmků v C#. Funguje to k mé naprosté spokojenosti, napsal jsem to za pár dnů (kdybych měl praxi, tak za pár hodin... musím hledat kdejakou ptákovinu). V asm bych to šmudlal týdny.

Assembler je dost nešikovný kvůli produktivitě a nepřenositelnosti. Teď sis napsal program pro PC, zítra ho budeš chtít přepsat pro telefon. Kód v C# nebo C++ apod můžeš pravděpodobně bez úprav překopírovat do svého mobilního projektu (aspoň jeho části), ale Assembler z Intelu na ARM přenést nelze. Ani ň. Dnešní kompilátory umí kód dobře optimalizovat a využívat vlastnosti CPU jako je vektorizace, ale úplně perfektní kód ne generují. Navíc binární kód z těch vyšších jazyků bývá dost velký. A některé ani nevytváří strojový kód, ale tzv. Bitcode. Např. C# a Java.

Sorry, bytecode. Bitcode generuje Swift a je to něco jiného.https://en.wikipedia.org/wiki/Bytecode...
https://lowlevelbits.org/bitcode-demystified/...

V tom pripade bych potreboval tip na nejaky uC o velikosti pouzdra Soic 8 ktery pobezi na 5V/16Mhz s internim oscilatorem, bude mit ADC prevodnik (aspon jeden) a bude mit vic pameti nez AtTiny85. Kdyz je situace ze musim setrit kazdym gramem/milimetrem proto abych dostal zarizeni do copteru/letadla tak se hodi i bitove operace

ESP8266? Samotný MC má tuším 4x4 mm, ale budete potřebovat 3.3V
Pak je zde ještě možnost ESP32. Rozměry stejné, parametry úplně někde jinde.

Není dobrých a špatných programovacích jazyků. Jsou jen dobří a špatní programátoři.

Většina těch IOT rádií je jednoduchá, žádné TCP/IP.

Tam to má jistě větší smysl. Já jsem vycházel z toho, co v článku uvádí autor jako příklad: externí a interní meteorologickou stanici s Wi-Fi.