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 - DukePukem

Stran: [1]
1
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.

2
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.

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

4
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.

5
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...

6
Studium a uplatnění / Re:MatFyz UK vs. FIT ČVUT
« kdy: 19. 02. 2022, 20:13:54 »
Naprosto nesouhlasím s výkřiky "MFF ti dá jen teorii" a "chodí tam jen nerdi"...

Samozřejmě, MFF je o dost teoretičtější (projděte si studijní plány), ale musíte si zodpovědět, co chcete dělat... Jestliže chcete mastit eshopy (vizte vedlejší vlákno...) nebo linux-adminovat pár serverů a teď nic neumíte, ano, udělejte si Bc. na FITu.

Chcete-li se věnovat něčemu složitějšímu, pak se rozhodování dále větví...

FIT vás naučí programovat, pokud to ještě neumíte + vám dá navíc něco teorie.

Pokud už umíte dobře programovat a ještě navíc vám jde matika, MFF vás naučí nad problémy jinak přemýšlet a programování pro vás bude spíš nástroj, jak ty problémy řešit - ale nedá vám tolik praxe jako FIT.

V každém případě ale nikdo nemůže počítat s tím, že dokončí Mgr. na MFF nebo Ing. na FITu a bude z něj mistr světa. Úspěšná kariéra samozřejmě vyžaduje spoustu dalšího sebevzdělávání a praxe.

Já mám zkušenosti s obojím.

Na FITu je matika spíš opravdu jen takový základ pro programovací/teoretické předměty, naopak - když člověk aspoň trochu chce - může se tam naučit slušně programovat.

Na MFF je naopak brutální matematika, větší důraz na různé grafy, efektivní algoritmy apod., ale programování samo o sobě je tam prostředek pro "zkoušení" těchto problémů. Jsou tam také obory/předměty, kde se člověk naučí dobře programovat, ale IMO je v nich větší volnost než na FITu.

7
Navic, ja ani tak nemluvil o "webovych backendech", spise obecne o cemkoliv slozitejsim nez placani webovek v JavaScriptu. Budete se divit, ale ta vase DB na backendu setsakramentsky resi, jestli bude pouzivat std::vector nebo std::unordered_map...

pokud implementujete vlastni DB server.

Co to povidate? Myslite si, ze databaze programuji roboti? Databaze programuji lide, velmi casto je pisi v C++ a presne tam resi vykonnost proto, aby na rootu mohli rozumbradove psat, ze "vykon backendu neresi"...

Projdete si nabidky na LinkedInu, pomerne nedavno jsem tam videl i nejakou zajimavou nabidku na C++ job pro nejakou firmu, co programuje databaze. A ano, tam se vas rozhodne na algoritmy ptat budou...

to si nemyslim, mozna je to vase domena? Proc se potom vyjadrujete k webovemu frontendu?

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...

8
Navic, ja ani tak nemluvil o "webovych backendech", spise obecne o cemkoliv slozitejsim nez placani webovek v JavaScriptu. Budete se divit, ale ta vase DB na backendu setsakramentsky resi, jestli bude pouzivat std::vector nebo std::unordered_map...

pokud implementujete vlastni DB server.

Co to povidate? Myslite si, ze databaze programuji roboti? Databaze programuji lide, velmi casto je pisi v C++ a presne tam resi vykonnost proto, aby na rootu mohli rozumbradove psat, ze "vykon backendu neresi"...

Projdete si nabidky na LinkedInu, pomerne nedavno jsem tam videl i nejakou zajimavou nabidku na C++ job pro nejakou firmu, co programuje databaze. A ano, tam se vas rozhodne na algoritmy ptat budou...

9
neni zdaleka pravda, u frontendu musite myslet na rychlost (pripadne spotrebu baterie) mnohem casteji nez u backendu. V JS pouzivam profiler celkem casto.

A ted tu o Karkulce... Pokud nemate ve vasich webovkach svitive barvy, netahate megabajty obrazku, resourcu, libek (coz je ale hloupost i u ne-mobilni aplikace), nemate tam tunu zbytecnych requestu, vezte, ze nejake to iterovani pres pole ma vyznam 0.0. Pokud pisete hry v JS pro mobilni prohlizece, dejme tomu - ale to uz jsme daleko od bouchani eshopu a stejne bude jeste hodne zalezet na tom, jak ten prohlizec JS interpretuje...

99% vykonostnich problemu webovych aplikaci jsou bud na strane DB serveru nebo frontendu. Na strane backendoveho aplikacniho kodu neni problem temer nikdy, tam staci dodrzovat jednoduchou zasadu neselektovat z DB vic dat nez hodlate zobrazovat. Potom muzete klidne zamenovat std::vektor a std::unordered map, dat nikdy neni tolik, aby se to vykonostne projevilo.

"Mnohem casteji nez u backendu"? :D Tak jestli vas backend je par selectu z databaze... Pokud pisete webove aplikace, kde neresite vykon backendu, zrejme byste si mel rozsirit obzory...

Navic, ja ani tak nemluvil o "webovych backendech", spise obecne o cemkoliv slozitejsim nez placani webovek v JavaScriptu. Budete se divit, ale ta vase DB na backendu setsakramentsky resi, jestli bude pouzivat std::vector nebo std::unordered_map...

10
Haha, v dnesni dobe jsou internety plne vsemoznych leetcode, hackerranku atd. Jestlize o nich tazatel nikdy v zivote neslysel, zrejme by si mel vyndat hlavu ze sedaci oblasti. "programovat e-shop na 100 zpusobu" skutecne dnes zadny skill neni a uz vubec to nepredstavuje nejakou intelektualni vyzvu. V IT je to - hned po QA - takove kopani lopatou a zatloukani hrebiku.

SAMOZREJME, ze takoveto typy uloh jsou naprosto klicove pro vyber uchazece (tedy pokud se uchazec uchazi o neco narocnejsiho nez masteni eshopu v male firme). Nelze ocekavat, ze prijdu na pohovor, reknu: "Jsem proste dobrej" a oni me bez dalsich otazek prijmou. Mozna to tak plati pro frontendaky, kteri ukazi, ze umi v JS naimportovat React/Angular/Vue, zavolat par funkci a udelat eye-candy menu. Ano, tam skutecne neni treba premyslet nad tim, jak rychle JS bude iterovat pres polozky toho menu...

Trochu se desim, jak tu vsichni pisi, ze to jsou nejake teoreticke nesmysle, ktere nikdy nepouzivaji. Skutecne jste nikdy neresili tak casty problem jestli pouzit napr. std::vector (cache-locality, malo alokaci) vs std::unordered_map (rychlejsi lookup) apod.? Skutecne nepremyslite nad cistotou a efektivitou vaseho kodu?

Vzpominam si, kdyz jsem nekomu vysvetloval, ze duplikovani kodu je zlo a ten clovek mi tvrdil, ze on se neridi nejakymi teoretickymi pouckami, ze on je "clovek z praxe"...

Tazateli doporucuji precist knihu o algoritmech, zjistit, co je to asymptoticka slozitost, nastudovat zakladni tridici algoritmy, datove struktury a potom busit leetcode/hackerrank.

Muzete si tu brecet, jak chcete, ale realita je takova, ze tohle proste na pohovorech chteji.

11
Studium a uplatnění / Re:Přechod na magistra na FIT ČVUT
« kdy: 14. 03. 2021, 18:47:50 »
Doporucovat cloveku z VSE, kteryho uz jednou nekde vyrazili MFF nebo FJFI je hodne naivni...

FIT CVUT je o neco lehci nez vyse zminene (ale slysel sem i od matfyzaku kladne hodnoceni vyuky programovani na FIT), ale prochazka ruzovou zahradou to urcite neni.

Nevim jak jsou ted postaveny PARy, ale bez aspon zakladu diskretky, datovejch struktur a algoritmu to - aspon tenkrat - bylo totalni nogo, nedavali to ani lidi, co meli Bc. z FITu.

Dalsi vec jsou runtime systemy. Na magistru na FITu se nikdo nepta, jestli umis programovat, jestli neumis, zkousnes si v tomhle predmetu hodne horkou pilulku. Nakodit ve dvou za semestr VMku (a mit k tomu jeste dalsi predmety) je dost sousticko i pro zkusenyho.

Tim nerikam, ze to nejak neprebrkas, ale u statnic to po tobe budou stejne chtit.

Asi nemusis bejt nejak extra genialni (i kdyz to je samozrejme vyhoda  :D), to vubec netvrdim. Ale stopro musis mit aspon trochu zkusenosti s kodenim a rozhodne byt dost systematickej, odhodlanej a peclivej.

No offense, ale na tohle te IMO VSE nepripravi...
Zas tak černě bych to neviděl, na magistru panuje úplně jiný přístup a v případě potíží vyučující pomůžou individuálně.

Haha, tak to jsi asi nemel PARy a podobne predmety. Vyucujici radi pomuzou, to je pravda, ale hromadne, vice studentum najednou s tim, co obecne v tom predmetu dela problem. Urcite ti nebude davat osobni konzultace na latku, kterou mas davno znat z Bc.

To vaclavjochim: Nevim, co znamena "92 percentil na oboru", ale jestli je to prospech na VSE, tak od toho bych se moc neodrazel :)

Pochop, na FITu to neni o "uceni se", je to tam o "chapani". To se neda kvantifikovat na pocet hodin. Nekomu to zabere hodinu, nekomu deset, jinej se na to po peti vykasle.

Nesnazim se te odratit, ja nevim, treba na to mas. Dobre by se to dalo "vyzkouset" tak, ze si koupis/pucis skripta z PARu a zkusis to pochopit nebo si nakodis - jako hobby projekt :P - JVM. To myslim smrtelne vazne.

Spis chci predejit tomu, ze

a) ztratis rok/dva casu neuspesnym studiem
b) na zaklade a) budes zhrzenej a budes vsude rozhlasovat, jak je FIT spatna skola VSE fajn :D

12
Studium a uplatnění / Re:Přechod na magistra na FIT ČVUT
« kdy: 14. 03. 2021, 14:41:11 »
Doporucovat cloveku z VSE, kteryho uz jednou nekde vyrazili MFF nebo FJFI je hodne naivni...

FIT CVUT je o neco lehci nez vyse zminene (ale slysel sem i od matfyzaku kladne hodnoceni vyuky programovani na FIT), ale prochazka ruzovou zahradou to urcite neni.

Nevim jak jsou ted postaveny PARy, ale bez aspon zakladu diskretky, datovejch struktur a algoritmu to - aspon tenkrat - bylo totalni nogo, nedavali to ani lidi, co meli Bc. z FITu.

Dalsi vec jsou runtime systemy. Na magistru na FITu se nikdo nepta, jestli umis programovat, jestli neumis, zkousnes si v tomhle predmetu hodne horkou pilulku. Nakodit ve dvou za semestr VMku (a mit k tomu jeste dalsi predmety) je dost sousticko i pro zkusenyho.

Tim nerikam, ze to nejak neprebrkas, ale u statnic to po tobe budou stejne chtit.

Asi nemusis bejt nejak extra genialni (i kdyz to je samozrejme vyhoda  :D), to vubec netvrdim. Ale stopro musis mit aspon trochu zkusenosti s kodenim a rozhodne byt dost systematickej, odhodlanej a peclivej.

No offense, ale na tohle te IMO VSE nepripravi...

13
Hledám práci / Re:Zajímavý C++ job v Praze
« kdy: 25. 08. 2020, 21:00:01 »
Zrovna jsem se prihlasil, abych se zeptal, jestli nevite, jaka je ted situace v Barclays... Slysel jsem ruzny drby jako napriklad, ze propousti a ze meni hiring procesy.

Stran: [1]