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.


Příspěvky - Tomas2

Stran: 1 ... 14 15 [16] 17 18 ... 21
226
Server / Re:Konzistencia dat - databaza
« kdy: 18. 06. 2017, 23:34:31 »
správně je (2) a i nejspíš (1), podrobnosti máš třeba na wiki https://en.wikipedia.org/wiki/Serializability

(1) je dost strašidelná formulace vzhledem k otázce, ona je totiž podmnožinou (2) a popisuje interní implementaci a osobně bych jí také zvolil. Jedná se právě o běžný způsob jak navrhnout paralelní aplikace - příjmout více požadavků, ale vykonat je ve frontě jeden po druhém a (2) právě popisuje stav, kdy jednotlivé transakce nejsou na sobě závislé - výsledek není závislý na pořadí vykonání jednotlivých transakcí.

227
Software / Re:Náhrada FTP
« kdy: 18. 06. 2017, 21:43:06 »
sftp je opravdu často pomalejší, může za to podpora jeho shellu a nutnost parsovat a ošetřovat příkazy. Pokud je možné, scp je na přenos souborů mnooohem efektivnější, také je uzavřené v ssh, je možné ho i nakonfigurovat, aby bylo plně kompatibilní s chrootu u mod_sftp, ale s tím je poměrně dost opičáren s binárkami nebo kompilací.

sftp je ale při přenosu velkého množství malých souborů mnohonásobně efektivnější než ftp. Pokud jde o rychlost přenosu velkého souboru, není špatná volba třeba běžně dostupný rsync (opět nad ssh), umí poměrně hezky komprimovat, přenášet ve více kanálech a pokračovat v nedokončeném přenosu.

228
Vývoj / Re:Proč pořád používáme TTY, konzole a terminál?
« kdy: 14. 06. 2017, 20:05:11 »
odpověď je jednoduchá, protože nikdo nic lepšího a všestrannějšího nevymyslel. TTY s námi je skoro beze změny několik generací. Osobně jsem si na tohle asi už zvyknul a moc to řeším, jen používám, pro mě nejdůležitější je, že to funguje obdobně na všech platformách.

229
Server / Re:Využití paměti v Linuxu: cache vs. swap
« kdy: 09. 06. 2017, 14:29:49 »
"swap je špatně, tak ho zrušíme", geniální názor geniálních lidí.

Na linuxu se swap chová jinak než na Windowsu. Na linuxu se tam primárně dávají dlouho nevyužité procesy, tak aby se uvolnila paměť pro ty, které jí potřebují. Aplikace si sama může určit, jestli může jít do swapu nebo ne, to je třeba případ Chromu, ten do swapu nechodí.

Manipulace se swapem byl měl být až důsledek měření nebo nějakého chování, rušit ho jen proto, že si myslím, že ho nepotřebuji nebo je to špatně, není dobrý nápad. Osobně raději, když mi aplikace skončí ve swapu než když mi jí ze světa zprovodí OOM.

Něco jiného to je na produkčních serverech, zejména databázích pod vysokým vytížením, tam pokud něco aktivního vlétne do swapu, může celý stroj popadat jak nic. Opět to je ale důsledek určitého stavu a vypnutím swapu vím přesně co dělám.

Argument se SSD také není správný, tolik zápisu do swapu není a pokud je, většinou to je důsledek jiných problémů.

230
Server / Re:Využití paměti v Linuxu: cache vs. swap
« kdy: 08. 06. 2017, 11:08:12 »
klidně nastav swappiness na 0 a tím vypneš automatické odlévání na pozadí. Pokud nic napadat nebude, můžeš to nechat, pokud ti začnou padat programy na OOM (out of memory), zase to zapni.

231
Server / Re:vyuziti pameti
« kdy: 07. 06. 2017, 12:15:19 »
lidsky řečeno, ve swapu skončí paměť neaktivních procesů. Pokud by se začalo swapovat až v momentě, kdy nějaký proces tu paměť potřebuje, muselo by se čekat na zapsání paměti na disku, což nechceš. Linux se stará na pozadí o to, že procesy, které se moc nepoužívají, odlévá do swapu.

Regulovat tohle chování lze přes nastavení swappiness, které určuje poměr stránek (page), které půjdou do swapu.

File cache je důležitá pro performance a není dobré jí agresivně čistit.

232
Vývoj / Re:Efektivita MySQL při uložení velkého XML
« kdy: 05. 06. 2017, 22:21:44 »
Raději to uloži do databáze ve formě key, value.
No, a tady bacha: EAV je právem považováno za antipattern, a právem. Dnes už je opravdu lepší použít XML nebo JSON, pokud mají nativní podporu (vlastně EAV byl jeden důvod proč se přidávala). Když relační databáze, tak pokud možno nějaká rozumná normální forma (tj. sloupečky).


EAV je o dvě míle dál než jsem měl na mysli :). Použití nativních struktur v XML/JSON bude antipattern za pět let, to si člověk moc nepomůže.

Akademická diskuze tady asi nemá smysl, nějaká normalizace dat v relačních databázím klukům asi moc neřiká. Ukládat celou strukturu v jednom atributu vypadá lákavě, ale chtěl bych upozornit na dost pastí, které se v budoucnu mohou vymstít (upgrade/downgrade, transformace, konzistence, integrita, backup/restore, transakce atd.).

Normalizovat data do tabulky je pro podobnou hru nejlepší, nosql může sloužit jako cache nebo píseček na hraní, data budou ale pod kontrolou v db.

233
captcha není kvíz o ceny, abys musel odpovídat správně, má jen zjistit, jestli jsi člověk, robot nebo opice.

Vtipné je, že tu hlasovou captchu si umí Google rozlušit vlastní službou, při ale masivnějším použití blokují účet. To jen tak mimo.

Jejich captcha mě poslední dobou také vysloveně štve, abych se 5 minut přihlašoval, protože usoudil, že můj ISP je v Indii a že je super nápad mi nabídnout indické otázky k obrázkům nebo hledání hor, tam kde podle mě určitě nejsou, je super. Naštěstí pokud je člověk přihlášený na firemní účet, Google daleko méně otravuje s captchou a na stránky, kde ji musím vyplňovat jsem přestal chodit a raději trávím čas na česrstvém vzduchu.

234
Hardware / Re:Jak nejrychleji rozeznat okem 6/8/bit monitor
« kdy: 04. 06. 2017, 22:59:47 »
hledej na googlu třeba 10 bit Gradient Test Patterns a podle jemnosti přechodu (šířce pruhů) poznáš množství barev. Radeon podporuje 8bit barvy (resp. až 12bit), ale pozor na HDMI kabel, ten rád posílá 4:2:0, z hlavy ži už neřeknu, jak to nastavit na windowsu, co si pamatuji, je lepší použít displayport, ten by měl automaticky jet na 4:4:4, místní Windowsáci mě určitě rád opraví.


235
Vývoj / Re:Efektivita MySQL při uložení velkého XML
« kdy: 04. 06. 2017, 11:15:20 »
MySQL má datový typ blob, jeho obsah je uložený mimo zbytek řádku jako soubor a jeho přítomnost nemá vliv na zbytek práce s řádkem.

Obecně ale takovéhle ulehčení není vhodné, narazíš s tím, když budeš chtít třeba dělat statistiku nebo celkový přehled několika údajů, bude to náročné. Velice problematické to je v případě, kdy časem budeš měnit/rozšiřovat strukturu těhle dat, doménová logika pak bude obsahovat zbytečně hodně ifů nebo musíš jednorázově transformovat všechny tyhle xml.

Raději to uloži do databáze ve formě key, value.

236
Vývoj / Re:Aku NoSQL databazu?
« kdy: 03. 06. 2017, 01:05:09 »
pokud chcete mít úspěšnou aplikaci, vykašlete se na nosql, to nevede k úspoře, ale k plýtvání časem na vývoj. Pokud si ale chcete hrát a něco se naučit, vemte tu první, která vám padne pod nos a vyzkoušejte si to na ní, u začátečníků má docela úspěch Mongo nebo Couchdb či Redis, pokročilejší jsou schopni pracovat s Elasticsearch. Rozhodně se vyhněte speciálkám typu Riak, Cassandra, Hadoop nebo těm stovkám velice malých bez velké komunity.

Ona je občas výzva i ten jeden uživatel za sekundu, záleží na typu aplikace a HW. Ty velké systém s miliony požadavků za sekundu prostě jen běží na mnoha strojích, to pak není zábava, mít pod kapotou 1000 cpu a desítky TB ram si člověk ani neužije, když jako vývojáře ho k tomu už nepustí a jako architekt si s tím nemůže hrát. Všichni se ale strašně rádi chlubí na jak velkém projektu pracovali :)


237

aneb řečeno, vadí ti, že obrazy na Azure nejsou secured by default a potřebuješ k tomu admina, aby daný stroj dal do pořádku? Dobrej objev...

238
Hardware / Re:Koupě notebooku bez Windows
« kdy: 21. 05. 2017, 14:50:13 »
Open source OS ale neznamená, že to výrobce nic nestojí, zajistit kompatibilitu s Linuxem bývá dražší než licence za Windows. Názor, že nechceš platit za OS, který nevyužiješ nepovažuji za směrodatný, krátkým pohledem do ceníků nevidím velký rozdíl mezi s/bez Windows (např. Acer Aspire E15 E5-575G).

Dell se snaží a většina jeho vyšších modelů je kompatibilní s Linuxem, u Lenova s thinkpady X je nutné tak generaci počkat. Na x230 běží i freebsd.

Franta: ono to možná bude nezájmem trhu.

239
ano, nadřazené proměnné se propagují do těch vnitřních. Nejedná se o globální proměnné, btw.

Použití pole místo objektu byl ode mě jen krok napřed (users je poté nutné inicializovat jako var user = []). Mohu mít uživatele s více okny prohlížeče, chci mu to tedy poslat asi do všech nebo v době vytvoření připojení nemám k dispozici ještě jméno uživatele, tak musím ukládat sessionId a to je pak mnohem efektivnější procházet a hledat v poli než v objektu.

Je tady poté i další aspekt, pokud uživatelské jméno je vstupem z venku a já ho dávám jako klíč do objektu, mohu si s tím zadělat na problém, kdy správně zvolená jména mi odrovnají aplikaci kvůli složitosti jejich hledání v hashmapě.

Další drobnost je třeba performance, pokud budu do pole ukládat pořád stejný objekt, JIT v JS s ním bude pracovat velice efektivně. Mazání nebo přidávání položek do pole je i při velkém množství takových operací stabilní. Dělat tohle s objektem, mohu si zadělat na dost nepříjemné bugy nebo memory leaky.

240
tipuji, že za to může jejich adaptivní bitrate (nejprve se začne přehrávat video v nejmenší kvalitě a pak podle rychlosti připojení se kvalita zvedne). Tím, že ti to odchytne systémový player, už nedojde ke změně rozlišení.

Zkusil bych si na youtube nastavit svoji výchozí rozlišení videa či pohledat, jestli neexistuje možnost, jak GET parametrem v url to změnit.

Stran: 1 ... 14 15 [16] 17 18 ... 21