Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
Tak co rikate na oznamene novinky. Mne osobne zaujal Metal 2, je to fakt mozny aby byl 100x vykonnejsi nez OpenGL (zrejme ne ve vsem, jen vypichli nejakou feature, ale i tak) ?To H265 vypadá slibně.
Dale v macOS oficialni podpora eGPU, novy filesystem APFS default, nativni podpora H265 taky neni k zahozeni a VR podpora.
No a samozrejme iMac Pro 18-jadrovy Xeon, Radeon Vega 16GB a nebude to moc hucet, no ja uz setrim
Ahoj,Nejlepší je asi VPS, flexibilita se časem hodí. S tím načítáním to jde částečně vyřešit vhodnou technologií, typicky kombinace offline manifestu, ajaxu a lokálního cachování dat, i když pochopitelně záleží na tom, co přesně má ta aplikace dělat. Nicméně vhodná architektura dělá ohledně rychlosti přístupu divy.
měl bych pár obecných otázek k provozu webové aplikace. Uvedu, že aplikace bude určena pro celý svět a k běhu potřebuje celkem standardní záležitosti jako webový server, Python, PostgreSQL apod... nic speciálního. Cena provozu je důležité kritérium, protože minimálně ze začátku to nebude vydělávat nic (ale zase tam nebude ani velký traffic).
1) Kde aplikaci provozovat? Přemýšlel jsem o VPS, což vyjde nejlevněji (cca 100 Kč/měsíčně), ale člověk si musí všechno nastavit a hlídat sám. Určitě to bude chtít i nějaké logy, monitoring a zálohování. Je to v silách člověka, co je vývojář a nikdy neadministroval server? Další varianta je něco jako Heroku. Tam jsem se ale díval že pro free variantu PostgreSQL je omezení 10000 řádků, což je dost málo. Celkově to Heroku vyjde o dost dráž (Postgresql bez omezení řádků 50 USD/měsíc + cena za dyno) a nevím, jestli se to za tu cenu vyplatí. Jsou ještě nějaké podobné služby?
2) Jak zajistit dobrou odezvu pro celý svět? Když si pořídím VPS u české firmy, pojede to svižně v ČR a v Evropě. Ale v USA, Austrálii nebo Asii to pojede pomalu. Samozřejmě statické soubory plánuji dát na CDN, ale i tak si myslím že stránka se bude načítat třeba 2 vteřiny v odlehlých regionech. Jak se toto řeší? Když rozjedu víc serverů v různých místech světa, tak stejně si budou muset sáhnout na nějakou centrální databázi na druhém konci světa, ne?. Nebo má každý stroj svou databázi a nějak se to synchronizuje na pozadí?
Díky za odpovědi.
To bych taky rád viděl. Spíš ten osel ukázal na fakt, že absolutně neví, o čem se tu bavíme.Prave ste poukazali na fakt, ze Redis drzi kluce v hash tabulke a nie v B+strome. Preto si rad pozriem ako vam SCAN bude vracat "nejbližšího následníka podle lexikografického uspořádání".Stěžejní je schopnost úložiště nalézt nejbližšího následníka podle lexikografického uspořádání. Taková implementace je optimální (lépe to nejde) a typicky se používá něco jak B+ strom, aby vyhledání bylo vždy O(log n).
https://redis.io/commands/scan
"Time complexity: O(1) for every call."
V logice jsme dostali za úkol přečíst si "Machine Oriented Logic Based on the Resolution Principle", což jsem udělal a teď si říkám - proč se používá zrovna FOL? V jiných kontextech (třeba reprezentace jazyků jako angličtina nebo čeština) se používají často predikáty vyšších řádů, kde už rezoluce neplatí. Znamená to, že s FOL lze sice formálně dobře pracovat, ale nestačí k popisu výroků v běžných jazycích?Stačí, když se použije konjunktivistická notace. V obecné sémantice je logika vyššího řádu úplná a převoditelná reifikací na FOL, čehož se využívá v reprezentaci.
Další troll do sbírkya trolim vedatory tim jak je JavaScript skvelej. Jak tak koukam docela me obesla Java a ani nevim jestli je to dobre nebo neTak jestli ve tvym pojeti "trolit" znamena delat ze sebe na webu vola pouzivanim terminu, kterym nerozumis, tak ti to jde skvele
Nebo kvantovým algoritmemPojem relační implikuje hledání podle indexů. Když nevíš, jak se to implementuje, tak kušuj (to platí pro všechny trolly).Úloha je relační databáze s indexy nad (vybranými) sloupci...
To jsi vyčetl kde?
Relační neimplikuje hledání podle indexů, relace nemusí být setříděná, a ani setřídění v dané relaci nemusí vůbec dávat smysl. Relační databáze jsou relační proto, že využívají k zachycení reality relace, tedy ne nutně uspořádané soubory uspořádaných entic. Indexy jsou tam navíc, souvisí s praktickou implementací, klidně by mohly být realizovány hardwarově asociativní pamětí, nebo neuronovou sítí.
Každé pole záznamu má klíč tabulka:uid:pole. Pro načtení záznamu stačí použít dolní mez tabulka:uid: k iteraci přes všechna pole záznamu. Indexy mají klíč index:pole:hodnota a jako hodnotu seznam uid. Pro vyhledání se pak použije dolní mez index:pole:hodnota. Stěžejní je schopnost úložiště nalézt nejbližšího následníka podle lexikografického uspořádání. Taková implementace je optimální (lépe to nejde) a typicky se používá něco jak B+ strom, aby vyhledání bylo vždy O(log n).Jak se teda dělá uložení záznamu a hledání v indexu?Už několikrát jsem při čtení o databazích narazil na zmínku, že relační databáze jde postavit nad KV úložištěm, ale nepodařilo se mi vygooglit nic bližšího. Jak se tabulky ukládají, když jsou k dispozici jen klíče?To jde jen tehdy, když jsou klíče v úložišti setříděné.
Z definice relační databáze.Úloha je relační databáze s indexy nad (vybranými) sloupci...
To jsi vyčetl kde?
Úloha je relační databáze s indexy nad (vybranými) sloupci. To jde na KV úložištěm udělat jen při použití sekvenčního procházení v lexikografickém pořadí, jiná cesta není (pokud nechci procházet všechny páry v úložišti, což je krávovina). Tečka.Jak uděláš index relace nad KV úložištěm, které nejde procházet sekvenčně?To jde jen tehdy, když jsou klíče v úložišti setříděné.Na to jsi přišel jak? Běžně se používají hashmapy a jde to také.
Pokud to úložiště nelze procházet sekvenčně, tak ten index relace neuděláš, ani když jsou seřazené. Hashmapa i seřazené záznamy tedy vyjdou nastejno.
Kromě toho ten index relace není nezbytnou podmínkou. Úloha se dá splnit i bez něj.
Jak uděláš index relace nad KV úložištěm, které nejde procházet sekvenčně?Na to jsi přišel jak? Běžně se používají hashmapy a jde to také.Už několikrát jsem při čtení o databazích narazil na zmínku, že relační databáze jde postavit nad KV úložištěm, ale nepodařilo se mi vygooglit nic bližšího. Jak se tabulky ukládají, když jsou k dispozici jen klíče?To jde jen tehdy, když jsou klíče v úložišti setříděné.
Už několikrát jsem při čtení o databazích narazil na zmínku, že relační databáze jde postavit nad KV úložištěm, ale nepodařilo se mi vygooglit nic bližšího. Jak se tabulky ukládají, když jsou k dispozici jen klíče?To jde jen tehdy, když jsou klíče v úložišti setříděné.
Nech ho aspoň napsat zadání, třeba projednou nenapíše debilní výblitek a bude to stát aspoň za zamyšlení.Poměříme efektivitu. Každý může řešit ve svém oblíbeném jazyce.Proc bych to pripanajana mel delat?! Fakt mne neni sedmnact
Ten reasoning má naučit VŠSekta jste spise vy logicti vedatori. Asi by sem vam zritil svet kdyby ste uznali, ze JS & JSON je cool na mnoho veci, ale ne najdete edge case co nikoho nezajima krome tri logickych vedatoru s poruchou osobnosti made in root.cz a kolem toho onanujete. Btw gratuluji tohle vlakno ma 300 vicemene nic neresicich prispevku, protoze i zitra i poztir na tebe vybafne jak json tak jsvascript a nic s tim nenadelas.Nojo, kámo, jenže právě corner cases odlišují dobrá a špatná řešení. Jde totiž o to, jetli se na tu danou věc dá spolehnout. Pokud má nějaké prokazatelné vlastnosti, tak se nad ní dá dobře uvažovat (reason) a tímpádem i spolehlivě dál stavět.
...a tohle je přesně ten kořen problémů webového světa ilustrovaný v tom zmíněným https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f - vezme se totiž nějaký vachrlatý hliněný základ (corner cases přece nikoho nezajímají, je to good enough!), na něm se postaví eiffelovka, ta se začne naklánět, tak se podepře lešením ze sirek, který začnou praskat, tak se to celý omotá dvěma tunama lepící pásky a do manuálu se napíše, že to celý funguje, pokud je venku míň než 30 st. C, protože pak začne páska měknout a povolovat. Ok. A pak po webu poskakujou webaři s tvrzením "to není bug, ale feature, si to přečti vole v manuálu, že to můžeš používat jenom do 30 st. C". Načež vyjde nová verze JS, kde se celá ta koule z lepící pásky omotá deseti tunama ocelového řetězu, takže už to přežije víc než 30, ale zas je to těžký a naklání se to pro změnu na druhou stranu. Ok, už víme, že sirky jsou blbý řešení, tak uděláme lešení z brček. Neonových, protože to je cool.
Hele, klidně si mysli, co chceš, já se ti jenom snažím pomoct uvědomit si, že úhelným kamenem IT je předvídatelnost a schopnost o věcech strukturovaně logicky uvažovat. Čím dýl budeš logický uvažování považovat za "vědátorskou onanii", tím dýl budeš dělat shitový produkty, o který bude postupně opadat zájem - stejně jako opadl zájem o správce Windows 95, kteří se cítili na koni, dokud měly W95 monopol. Dneska jsou z nich pupkatí pánové, kteří si horkotěžko vydělávají pár korun v zaflusaným krámku, kde lidem čistí v komplu ventilátory.
Možná už SŠ, my měli na gymplu učitelku, která na nás v matice házela příklady ze života, každé zadání bylo formulované v rámci nějaké situace z reálného světa, někdy skoro až přehnaně uměle, ale nikdy to nebylo "tady máte rovnici a vypočítejte x".
To tak bývá, když technologie navrhuje pako. Další paka to pak obhajujou. Akademický přístup k problému někdy není na škodu, ale tady už je pozdě.Nicméně JSON je sice pakárna, ale na jednoduché věci stačí.Jasně, však já nemám nic proti tomu, aby se JSONem posílaly přes websockety zprávy typuKód: [Vybrat]ale je škoda, že se ten mor šíří dál a dál. Je to stejný jako monopol Windows 95... Vyhrál největší shit široko daleko...{event: "newChatMessage", sender: "Franta", msg: "specificka webarina"}
...a do toho slzavýho údolí ještě přijdou chytráci, kteří začnou tvrdit, že to je vlastně state of the art...
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2023 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.
