Příspěvky

166

Studium a uplatnění / Re:Otázky má pohovoru

« kdy: 15. 08. 2018, 17:11:51 »

Jenže ono je to ještě jinak. Dvacetiprocentní šance zásahu znamená že se trefí (průměrně) každé páté. Takže jich musím poslat pět najednou, aby se aspoň jedno z nich trefilo (opět průměrně, někdy se netrefí žádné, občas zase dvě nebo i víc, a ve velmi nepravděpodobném ale možném případě všech pět). Jenže kdybych to počítal přes ten 80% neúspěch, tak se netrefím nikdy ani kdybych jich poslal tisíc! Což je blbost, a pořádná. Takže takhle v praxi určitě NE.

Když to vezmu úplně prakticky, nikoliv akademicky, tak 1/5 + 1/5 = 2/5 a to je těch 40%.

10 torpéd se trefí na 200%?

167

Studium a uplatnění / Re:Otázky má pohovoru

« kdy: 15. 08. 2018, 15:44:24 »

dost záleží na tom, jak vypadají vstupní data. Jestli se tam opakuje pár url, tak řazení není dobrý způsob. Lepší ty county ukládat do slovníku.

V zadání bylo, že ani unikátní URL se nevejdou do paměti.

to jsem přehlédl.

168

Studium a uplatnění / Re:Otázky má pohovoru

« kdy: 15. 08. 2018, 15:40:58 »

Ne. Unixový sort je zrovna dělán tak, že RAMka nedojde (a o žádném jiném zjevně řeč není).

Toto zadanie je zaujímavé v tom, ako by sa dalo so skúšaným filozoficky diskutovať nad podstatou rôznych fundamentálnych objektov, ktoré sa na to využijú (ja už odpoveď prepisujem odznova tretí krát, vždy ma niečo nové napadlo, čo znegovalo predošlý text). T.j. nie len samotný algoritmus, ale všetka omáčka okolo, čo za akých obmedzení ako urobiť.

Lebo ak máme napr. disk z ľubovoľným prístupom, ten sa dá považovať vlastne za RAM (ako swap file), čiže napríklad by bolo vhodné sa pre účel tohto príkladu pozerať na súbor (a pajpu tiež) z pohľadu, akoby šlo o pásku (zapíšem, pretočím, sekvenčne prečítam). To podľa mňa veľkú časť uchádzačov ani nenapadne (a teda požiadavka "Různých URL je také velké množství, ani ty samotné se nevejdou do paměti." ani nedáva zmysel) - napr. ak budeme predpokladať dostatočne veľké diskové miesto a povedzme unixový systém, naivné riešenie môže byť vytvorenie samostatného súboru obsahujúceho číslo ako počet výskytov pre každé unikátne URL, a potom sekvenčne prechádzať pôvodný súbor a inkrementovať obsah príslušného súboru patriaceho danému URL...

postni sem to řešení. Podle mě plácáš nesmysly.

169

Studium a uplatnění / Re:Otázky má pohovoru

« kdy: 15. 08. 2018, 13:26:02 »

Jedna z pozdějších nápověd bylo, že příkaz "sort | uniq -c | sort -nr | head -n 5" přesně kopíruje to řešení (a jak to ten sort s tak velkým souborem vlastně dělá?). Rozhodně nechtěli slyšet "strč to do databáze a udělej SELECT", protože v tom případě si ten člověk myslí, že databáze je nějaká magická krabička a nevidí za tím, jak na tuhle úlohu je neefektivní.

dost záleží na tom, jak vypadají vstupní data. Jestli se tam opakuje pár url, tak řazení není dobrý způsob. Lepší ty county ukládat do slovníku.

170

Studium a uplatnění / Re:Otázky má pohovoru

« kdy: 15. 08. 2018, 13:20:59 »

BTW: Ja bych vazne chtel videt dneska firmu, ktera si dovoli pokladat podobne debilni otazky ktery tu sou zmineny, kdyz si muzou gratulovat, ze na ten pohovor dotycnej vubec prisel.

Podle mě je to výborná úloha na oddělení lidí typu „použijeme databázi“ a kteří nad problémem fakt přemýšlí. Pravda je, že ve většině firem ta databáze stačí. V tom tehdejším zaměstnání teda ale rozhodně nestačila, a právě proto vybrali tuhle úlohu.

Není to naopak? Sort stačí na jednoázové vyhledávání. Databázi použijete, když v těch datech hledáte opakovaně a nechcete řadit soubor pro každé hledání.

171

Studium a uplatnění / Re:Otázky má pohovoru

« kdy: 14. 08. 2018, 23:10:02 »

na hackerrank můžete vytvořit vlastní soutěž. Můžeme poměřit síly.

172

Studium a uplatnění / Re:Embedded systémy a microcontrollers

« kdy: 14. 08. 2018, 14:00:14 »

debugování je o dva řády složitější než v Javě a o řád než systémařina na PC.

programy jsou o 10 řádů jednodušší.

173

Vývoj / Re:Jak z PHP CLI poslat data na server a zpět?

« kdy: 06. 08. 2018, 17:15:38 »

http://php.net/manual/en/book.curl.php

174

Studium a uplatnění / Re:Otazky u pohovoru podprumerne firmy?

« kdy: 04. 08. 2018, 20:20:00 »

ptal jsi se tu na stejnou otázku už nejmíň 100-krát.

175

Vývoj / Re:Junit 5 - fakt bez poradi testu?

« kdy: 04. 08. 2018, 19:53:58 »

můžeš spouštět jednotlivé testy scriptem nebo i z Javy v pořadí v jakém chceš.

176

Vývoj / Re:Facebookové skupiny o programování?

« kdy: 03. 08. 2018, 18:00:37 »

Neznam zadneho skutecneho developera ktery by pouzival facebook. Lopaty na facebooku samozrejme jsou...

A co používají skuteční developeři? Rád se přiučím. A raději od skutečného developera, než od lopaty

hacker news

177

Vývoj / Re:Facebookové skupiny o programování?

« kdy: 03. 08. 2018, 14:15:24 »

Chci mít všechno na jednom místě.

potom nechceš facebook.

178

Vývoj / Re:Proč je čtení ze Socketu blokjící operace?

« kdy: 01. 08. 2018, 23:11:08 »

runBlocking nie je problem connection poolu, ale toho, ze JDBC je blokujuce API. Mozete mat datasource aj bez connection poolu s jednym spojenim a nic to nezmeni na tom, ze JDBC je blokujuce API a bude nutne volat runBlocking a stale sa nebudete vediet hooknut do toho eventloopu.

runBlocking právě nezablokuje vlákno event loopu. Spustí blokující kód ve vlákně thread poolu a výsledek zpracujete v callbacku. Nebo přeruší coroutinu. Nevím, jaké abstrakce ten framework podporuje. Každopádně to slouží k volání blokujícího kódu mimo event loop.

10k websocketovych spojeni je z hladiska procesoroveho casu vascinu casu neaktivnych, kedze IO trva vecnost. Nechapem co ich robi viac ne-scifi ako 10k sql dotazov.

máte 10k aktivních uživatelů, kterým občas zašlete notifikaci. To je běžná situace například u zpravodajských webů. Na druhou stranu se nikdy nestane (nemělo by se stát), aby všichni najednou dotazovali databázi. Od toho máte cachování a i ten thread pool. Obsluha websocketů může být v odděleném procesu, který do DB nepřistupuje.

179

Vývoj / Re:Proč je čtení ze Socketu blokjící operace?

« kdy: 01. 08. 2018, 21:13:59 »

Pokud tedy řešíme 10M tak stejně narazíte na limit počtu otevřených file deskriptorů a vlákna budou ten menší problém.

10M je asi moc, ale půl milionu jde.

180

Vývoj / Re:Proč je čtení ze Socketu blokjící operace?

« kdy: 01. 08. 2018, 21:09:07 »

NJ, jenže ten jednovláknové event loop je i v javě, jen už na to nemůžu použít jdbc. Java má i asynchronní sockety, ale asynchronní jdbc se teprve dělá. Můžu použít ale asynchronní Driver, třeba PostgreSQL ho má, ale není to jdbc. Takže jen jsem chtěl říct, že pořád to raději udělám v javě než v JS.

existuje

http://docs.paralleluniverse.co/comsat/#db-access

vnitřně to používá runBlocking. Ani to jinak nejde, vždy se připojuješ přes nějaký omezený connection pool. Stále nechápeš, že nikdy nebude spuštěno 10k sql dotazů současně, ale 10k websocketových spojení není scifi.