Tipy a triky na zlepšení logického myšlení u pohovorů

[Google CTCCTCGGCGGGCACGTAG]

Nesmim se vyjadrovat k nicemu, co neni moje domena? Vy se taky nevyjadrujete k politice, politice, ekonomii... mezi kamarady u piva (tady je uroven podobna)? Evidentne to take neni vase domena. Dle toho, co pisete, neni vase domena ani cokoliv na backendu. Proc jste se k tomu tedy - dle vasi logiky - vyjadroval?

Musi byt webovy frontend moje domena, abych vedel, ze JavaScript je ukrutne pomaly, latence na webovem frontendu je zpusobena requesty, resourcy, parsovanim HTML, CSS, JS (uz aby se rozsirilo WebAssembly), prebujelymi JS knihovnami a cpanim JS tam, kde by stacilo plain CSS?

Onehda jsem mel hovor s jednim rekruterem, nabidka byla celkem zajimava (detaily zminovat samozrejme nebudu), ale pry ten svuj uzasny produkt napsali v TypeScriptu, ale zjistili, ze je to prilis pomale a museli to zacit prepisovat do C++. Tot k te optimalizaci na mikrosekundy...

Pokud cerpate znalosti z rozhovoru s recruitery, ani se nedivim, ze placate nesmysly. Alespon jste se naucil buzzwordy.

Javascript neni pomaly, pomale jsou manipulace s DOMem, webassembly mozna pomuze jen u canvas aplikaci a her, urcite ne u klasickych aplikaci s DOM ui. Mozna byste to zjistil, kdybyste obcas otevrel profiler.

[Reklama]

[javalopata]

Musi byt webovy frontend moje domena, abych vedel, ze JavaScript je ukrutne pomaly, latence na webovem frontendu je zpusobena requesty, resourcy, parsovanim HTML, CSS, JS (uz aby se rozsirilo WebAssembly), prebujelymi JS knihovnami a cpanim JS tam, kde by stacilo plain CSS?

Co se týče UI tak browser technologie (JS VM, HTML, CSS) jsou teď srovnatelné s .NET a JVM, ne li lepší a to hlavně v rychlosti. Podle špatně napsaných aplikací nebo knihoven nemůžete posuzovat celou platformu. Napsat dobře aplikaci v browseru může být stejně složité jako ji napsat dobře v libovolném jiném jazyce.

WebAssembly pomůže jen v ojedinělých případech, má také svůj overhead.

[DukePukem]

Nesmim se vyjadrovat k nicemu, co neni moje domena? Vy se taky nevyjadrujete k politice, politice, ekonomii... mezi kamarady u piva (tady je uroven podobna)? Evidentne to take neni vase domena. Dle toho, co pisete, neni vase domena ani cokoliv na backendu. Proc jste se k tomu tedy - dle vasi logiky - vyjadroval?

Musi byt webovy frontend moje domena, abych vedel, ze JavaScript je ukrutne pomaly, latence na webovem frontendu je zpusobena requesty, resourcy, parsovanim HTML, CSS, JS (uz aby se rozsirilo WebAssembly), prebujelymi JS knihovnami a cpanim JS tam, kde by stacilo plain CSS?

Onehda jsem mel hovor s jednim rekruterem, nabidka byla celkem zajimava (detaily zminovat samozrejme nebudu), ale pry ten svuj uzasny produkt napsali v TypeScriptu, ale zjistili, ze je to prilis pomale a museli to zacit prepisovat do C++. Tot k te optimalizaci na mikrosekundy...

Pokud cerpate znalosti z rozhovoru s recruitery, ani se nedivim, ze placate nesmysly. Alespon jste se naucil buzzwordy.

Javascript neni pomaly, pomale jsou manipulace s DOMem, webassembly mozna pomuze jen u canvas aplikaci a her, urcite ne u klasickych aplikaci s DOM ui. Mozna byste to zjistil, kdybyste obcas otevrel profiler.

Ano, presne tak, jeste taky cerpam informace od vseznalku z rootu

Abyste mohl rict, ze neco "neni pomale", musite ale rict, co resite nebo to s necim srovnat. Ano, pokud resite DOM traversing, tak na to zrejme JavaScript je "dost" rychly. Pokud uz chcete JavaScript s necim srovnat, pak ano, zrejme je rychlejsi nez vase babicka, ale mezi jazyky, ktere resi skutecne problemy (v kterych je mimo jine i ten vas JavaScript napsan) se radit neda...

Samozrejme, ze WebAssembly s DOMem nyni nepomuze, protoze (pokud vim) ho nativne ani zatim neumi. Nevim, jestli jste cetl (nebo pochopil), co jsem psal. Ja mluvil o requestech, ktere vubec ten vas JavaScript musi do prohlizece dopravit a kdyz uz tam je, tak ho musi prohlizec naparsovat a zkontrolovat syntaxi. WebAssembly je binarni.

Proc mi nutite profiler? Profilery jsou dneska na kazdy nesmysl. Ja vam rikam, ze kdyz udelate spravne vse vubec pred pouzitim JavaScriptu a toho JavaScriptu budete mit minimum (ano, jde to), nemusite resit profilery, protoze - pokud jste to nevedel - browser musi udelat spoustu dalsich operaci (je napsany v C++, vite?) predtim nez se vubec prokouse k vasemu JS.

Ano, samozrejme, pokud spustite 10000x smycku, jejiz body trva 100ms, tak jste prave zabil UI. Ale potrebujete na tohle skutecne profiler? Bezny uzivatel webovek skutecne nemeri vykonnost na milisekundy, ten vam jen rekne "je to pomale" vs. "je to rychle"

Vy uz jste se davno odkopal tim, ze nemate ahnung, co se deje na backendu, vase formulace "u frontendu musite myslet na rychlost mnohem casteji nez u backendu" to dokazuje. Mozna si tim jen snazite dokazat, ze vase remeslo je nejdulezitejsi na svete - ale neni

Tohle neni ani tak pro vas, vy uz svoji pravdu mate, spis pro ostatni, co se tak na webu meri: https://www.keycdn.com/blog/website-performance-metrics...

[DukePukem]

Musi byt webovy frontend moje domena, abych vedel, ze JavaScript je ukrutne pomaly, latence na webovem frontendu je zpusobena requesty, resourcy, parsovanim HTML, CSS, JS (uz aby se rozsirilo WebAssembly), prebujelymi JS knihovnami a cpanim JS tam, kde by stacilo plain CSS?

Co se týče UI tak browser technologie (JS VM, HTML, CSS) jsou teď srovnatelné s .NET a JVM, ne li lepší a to hlavně v rychlosti. Podle špatně napsaných aplikací nebo knihoven nemůžete posuzovat celou platformu. Napsat dobře aplikaci v browseru může být stejně složité jako ji napsat dobře v libovolném jiném jazyce.

WebAssembly pomůže jen v ojedinělých případech, má také svůj overhead.

Vy ale hrubym zpusobem mijite moji pointu. Ja zde nerozlisuji JavaScript vs JVM atd., nybrz interpretovany vs. kompilovany jazyk - v tom by WebAssembly pomohlo hodne, ale "it is not there yet" samozrejme...

A i kdyz bude vas JavaScript stokrat rychlejsi nez C++, stejne vykon vasich webovek bude stat a padat s kvalitou obrazku, poctem stazenych stylesheetu, knihoven, neefektivnim renderovanim atd. atd.

[javalopata]

A i kdyz bude vas JavaScript stokrat rychlejsi nez C++, stejne vykon vasich webovek bude stat a padat s kvalitou obrazku, poctem stazenych stylesheetu, knihoven, neefektivnim renderovanim atd. atd.

Co vlatně porovnáváte? Iteraci přes pole v C vs zobrazovaní obrázků v prohlížeči?
Neefektivní renderování v browseru - to jste vzal kde?

Browser technologie se používají jako náhrada předchozích UI technologií jako je Swing/JavaFx/WPF/WinForm/*. A když se napíší dobře tak jsou aplikace stejně rychlé.

[Reklama]

[DukePukem]

Boze muj, chapete rozdil mezi tim, kdyz mate program ve forme vstupniho jazyka (napriklad JavaScript) nebo ve zkompilovane binarni forme??

[DukePukem]

A i kdyz bude vas JavaScript stokrat rychlejsi nez C++, stejne vykon vasich webovek bude stat a padat s kvalitou obrazku, poctem stazenych stylesheetu, knihoven, neefektivnim renderovanim atd. atd.

Co vlatně porovnáváte? Iteraci přes pole v C vs zobrazovaní obrázků v prohlížeči?

Ne, vy se tu snazite manipulativne tvrdit, jak v JavaScriptu musite resit kazdou instrukci bytekodu, aby vas kod byl rychly. A ja to vyvracim tim, ze kdyz udelate spravne vsechno ostatni, profiler vas nezajima.

[javalopata]

A i kdyz bude vas JavaScript stokrat rychlejsi nez C++, stejne vykon vasich webovek bude stat a padat s kvalitou obrazku, poctem stazenych stylesheetu, knihoven, neefektivnim renderovanim atd. atd.

Co vlatně porovnáváte? Iteraci přes pole v C vs zobrazovaní obrázků v prohlížeči?

Ne, vy se tu snazite manipulativne tvrdit, jak v JavaScriptu musite resit kazdou instrukci bytekodu, aby vas kod byl rychly. A ja to vyvracim tim, ze kdyz udelate spravne vsechno ostatni, profiler vas nezajima.

Nevim ktere me vyjadreni vas vede k tomu ze si myslite, ze pouzivam profiler denodenne. Jsou situace kde se ale hodi a   je jedno na jake platforme jsme.

Kod, ktery se pise aby bezel v browseru muze byt stejne komplexni jako ten na backendu. Naopak neni duvod cpat kod z prezentacni vrstvy nekam kam nepatri.

A kdyz uz mate hodne kodu na dane platforme tak proste potrebujete mit stejne nastroje jako pro ne-UI cast. A k tomu potrebujete mit stejne dobre vyvojare.

Vyzkousejte si browser technologie, budete prijemne prekvapen, stejne jako ja pred par lety. Predpokladam totiz, ze vase posledni realne zkusenosti s webovym vyvojem jsou asi z doby kdy jsem sam naposledy delal s PHP, tj. 20 let zpet.

[Idris]

pry ten svuj uzasny produkt napsali v TypeScriptu, ale zjistili, ze je to prilis pomale a museli to zacit prepisovat do C++

Copak asi zjistili pro přepsání do C++ Že je to pomalé a musí to přepsat do Rustu?

[Idris]

Existují nějaké tipy / triky jak tento logický / algoritmický styl myšlení vylepšit?

Jak říkal jeden pán: učit se, učit se, učit se. Kromě nějaké té teorie hlavně procvičovat, ne triviální blbosti, ale něco jako tohle: https://github.com/AYLIEN/technical_challenge (to je tak 5 minut rozmyšlení a pak 10 minut implementace). Ten styl úloh se docela opakuje, po určité době už člověka nic nepřekvapí.

[xyz]

Existují nějaké tipy / triky jak tento logický / algoritmický styl myšlení vylepšit?

Jak říkal jeden pán: učit se, učit se, učit se. Kromě nějaké té teorie hlavně procvičovat, ne triviální blbosti, ale něco jako tohle: https://github.com/AYLIEN/technical_challenge (to je tak 5 minut rozmyšlení a pak 10 minut implementace). Ten styl úloh se docela opakuje, po určité době už člověka nic nepřekvapí.

https://onlinejudge.org/index.php?option=com_onlinejudge&Itemid=8&category=3

Asi bych trochu polemizoval s temi 5+10 minutami. Viz ta procenta.

[Idris]

Existují nějaké tipy / triky jak tento logický / algoritmický styl myšlení vylepšit?

Jak říkal jeden pán: učit se, učit se, učit se. Kromě nějaké té teorie hlavně procvičovat, ne triviální blbosti, ale něco jako tohle: https://github.com/AYLIEN/technical_challenge (to je tak 5 minut rozmyšlení a pak 10 minut implementace). Ten styl úloh se docela opakuje, po určité době už člověka nic nepřekvapí.

https://onlinejudge.org/index.php?option=com_onlinejudge&Itemid=8&category=3

Asi bych trochu polemizoval s temi 5+10 minutami. Viz ta procenta.

Je možné, že ten odhad je špatný, žádnou statistiku k tomu nemám. Nicméně tento styl úloh oddělí zrno od lopat a především otevírá prostor k zajímavé diskusi nad řešením, paradigmaty apod.

[DukePukem]

pry ten svuj uzasny produkt napsali v TypeScriptu, ale zjistili, ze je to prilis pomale a museli to zacit prepisovat do C++

Copak asi zjistili pro přepsání do C++ Že je to pomalé a musí to přepsat do Rustu?

Jakoze Rust je rychlejsi nez C++ Rekl vam nekdo, ze oba jazyky se kompiluji do stejneho strojoveho kodu, dokonce Rust backend je - stejne jako Clang - v LLVM, tudiz nektere vysledne binarky mohou byt ~totozne?

a) Rust neni a ani nema byt ambici "byt rychlejsi nez C++". Chce byt "alespon stejne rychly, pri vetsich compile-time zarukach".
b) Benchmarky sice existuji, ale jsou dost vyrovnane - benchmarky, ktere jsou takto blizke nemaji vyznam. Dulezite jsou pouze pokud ukazuji radove (řádové) rozdily.

[Idris]

Jakoze Rust je rychlejsi nez C++

Pokud někdo, kdo píše v JS (případně TS), přepíše svůj kód do C++, tak to bude dost hnůj. V Rustu mu překladač nedovolí tolik prasit.

[mikrom]

https://onlinejudge.org/index.php?option=com_onlinejudge&Itemid=8&category=3

Na prvy pohlad celkom zaujimave ale ...
skusil som z toho jednu ulohu
https://onlinejudge.org/index.php?option=com_onlinejudge&Itemid=8&category=3&page=show_problem&problem=42
ale ako dostali pre
Sample Input
10
Sample Output
1 4
to teda neviem

Prve cislo t.j. 1 je jasne, pretoze ta hladana trojica je (3, 4, 5)
Odkial ale maju ze to druhe cislo je 4, ked pisu ze "The second number is the number of positive integers ≤ N that are not part of any triple whose components are all ≤ N"
Ak mame cisla 1,2,..,10 a vysla nam teda jedna trojica (3, 4, 5) tak cisla ktore nie su v trojici su 1, 2, 6, 7, 8, 9, 10, teda ich je 7. Tak odkial maju ze to ma byt 4 ?