Příspěvky

196

Odkladiště / Re:Zakonna vypovedni lhuta a umyslne delani potizi

« kdy: 23. 10. 2019, 11:53:17 »

budeš mít záznam v papírech a nedostaneš podporu.

setkal jsem se s tím, že podobně to řešili lidé na dělnických pozicích, když si našli jinou práci a potřebovali rychle vypadnout. domluvili se s novým zaměstnavatelem, před šichtou popili, došli si na vrátnici dejchnout a pak už rovnou vyklízet skříňku.

Ha, a od tohoto slouzi diskuzni forum, toto je mnohem elegantnejsi reseni, proste parkrat po sobe prijit do prace s flaskou ruce nality jak delo, a nasledne se generalniho reditele zeptat jestli nechce napit 

197

Odkladiště / Zákonná výpovědní lhůta a úmyslné dělání potíží

« kdy: 23. 10. 2019, 11:37:47 »

Dobry den,

 kratky dotaz vztahujici se k logice vypovednich lhut a zakonum CR.

Zamestnanec muze podat Okamzite vypovezeni pracovniho pomeru ze zakona pouze v pripade, ze mu neprisla vyplata, nebo ze zdravotnich duvodu. V ostatnich pripadech si zamestnanec nemuze jen tak prestat dochazet do prace - pokud to udela, zamestnavatel po nem muze vymahat zpusobenou skodu cimz konci veskera legrace, protoze ta muze byt dost vysoka.

Tudiz neni mozne jen tak zmizet a pokud se k zmestnanci bude zamestnavatel chovat jako ke kusu lejna, tak zakon mu stejne neumoznuje jen tak firmu opustit.

Nicmene co kdyz by zamestnanec, ktery chce okamzite ukoncit pracovni pomer z duvodu rekneme neuctiveho chovani managementu, dal obycejnou vypoved, nasledne vpadl do kancelare generalniho reditele firmy, na zed mu nakreslil kridou velkou pizdu (nulova zpusobena skoda), nafotil to a potom rozeslal emailem nekolika zamestnancum.

V ten moment se stane to, ze jistojiste dostane vypoved na hodinu. Nicmene predpokladam, ze uz po nem neni mozne domahat se zpusobene skody za predcasne ukonceni pracovniho pomeru.

Jak se na toto diva zakon?

198

/dev/null / Re:Auta na baterky - má to budoucnost?

« kdy: 19. 10. 2019, 11:02:27 »

Vyskúšal som si Huinday Ioniq Electric a Skoda Fabia TSI 1.0 a pri ročnom nájazde 15 000km aj s dotáciou nenávratné, teda za 20 rokov. Pri nájazde 50 000 za rok návratné už za 5 rokov. S dotáciou 8 000€. Bez za 8 rokov.

Hyundai electric 130kW
Cena: 900000,- Kc

Kapacita baterek: 39kWh
Prumerna spotreba: 13,8kWh

Optimisticky dojezd: 280km
Realny dojezd: 50km musi byt rezerva -> 230km

Spotrebu na dalnici pri 130kmh vsak pocitejte tak minimalne 20kWh

Optimisticky dojezd na dalnici: 195km
Realny dojezd na dalnici: 50km rezerva -> 145km

Cena elektriny za 1kWh: 4.5,- Kc
Cena elektriny na 100km: 62,- Kc

----------

Skoda Fabia 1.0 TSI 81kWh, zakladni vybava
Cena: 340000,0 Kc

Prumerna spotreba: 6l/100km

Cena benzinu za 1l: 30,- Kc
Cena benzinu na 100km: 180,- Kc

Cena benzinu za 1l bez spotrebni dane: 17,- Kc
Cena benzinu na 100km: 102,- Kc

----------

Zaver at si udela kazdy sam.

199

Vývoj / Re:Naučení se asynchronnímu programování

« kdy: 12. 10. 2019, 10:25:15 »

Z epollu se samozrejme cte ve smycce, ale tady je celou dobu rec o Event Loop designu jak to ma Javacript, Node.js, Vertex, atp., a ne doprcic o tom, ze sis nekde v programu udelal while(true) a ctes neco ve worker threadu pres epoll.

200

Vývoj / Re:Naučení se asynchronnímu programování

« kdy: 11. 10. 2019, 16:32:01 »

Zaprve, ja vim dost na to, abych vedel, ze na backend do kodu zadne event loopy ani jine podobne srakcy nepatri. A Actor je taky solidni sracka 

A zadruhe, taky vim dost na to, abych vedel, jak je strasne na hovno kdyz ma jazyk coroutiny, protoze kokoti to pak pouzivaji uplne na vsechno misto aby to pouzivali s citem. Kazdou metodu pisou await async, ikdyz je to naprosto k nicemu.

Event loop je ted zrovna popularni v Jave ve Vertexu,  a nekteri by to chteli cpat na kazdou backendovou aplikaci, ikdyz je to nedebugovatelna sracka.

Na ten epoll se podivam o vikendu, tak jak pisete to urcite nefunguje, a toho sralbotku Sataie Nekolu si posleze podam 

201

Vývoj / Re:Naučení se asynchronnímu programování

« kdy: 11. 10. 2019, 15:25:57 »

To si nemyslim, smycka udalosti je z podstaty jiny typ mechanismu nez epoll.

Epoll, select a příbuzní jsou.. chvilku počkejte... dramaticka pauza... asynchronní! Používají se ve smyčce, sledují několik zdrojů a vrací řízení programu, když nastane nějaká událost. Jedna smyčka obsluhuje několik klientů.

Tomu neverim

Epoll není hejkal, abys na něj věřil nebo ne. Prostě si to nastuduj a pak se sem přijď pokorně omluvit.

Nasrat.

202

Vývoj / Re:Naučení se asynchronnímu programování

« kdy: 11. 10. 2019, 13:55:40 »

To si nemyslim, smycka udalosti je z podstaty jiny typ mechanismu nez epoll.

Epoll, select a příbuzní jsou.. chvilku počkejte... dramaticka pauza... asynchronní! Používají se ve smyčce, sledují několik zdrojů a vrací řízení programu, když nastane nějaká událost. Jedna smyčka obsluhuje několik klientů.

Tomu neverim, proc by to tak na urovni jadra pouzivali ve smycce? Na urovni jadra se musi dat operovat primo s HW prerusenimi. Kdyz ti epoll obsluhuje 10000 socketu, tak kdyz ti na nejaky z nich prijde nova message, tak ta se tam na te nejvic low level urovni dopravila udalosti HW preruseni. Na urovni jadra uz musi byt k dispozici nastroje, ktere umi HW preruseni primo obsluhovat. Od systemove funkce jako je epoll ocekavam, ze prave toto umi, tzn. ze HW preruseni vyvola kaskadu udalosti, ktere provedou obsluhu jednoho z 10000 socketu z epoll Jinak bysis taky tu smycku mohl napsat sam pres neblokujici Socket::available(), coz je dost dementni reseni.

203

Vývoj / Re:Naučení se asynchronnímu programování

« kdy: 11. 10. 2019, 00:40:45 »

Nerád by som narušil plodnú diskusiu, ale skúste zadefinovať výraz "non-blocking" a potom opäť hladať definíciu asynchronicity...

Sidenote, je tu nejaký C/C++ kóder? Imho by vedel pekne vysvetlit, naco sa pouziva epoll a preco necakame na prijatie nejakych bajtov po sieti inym sposobom?

Sidenote2: Skusme rozobrat hypoteticku ulohu. Nakodit server, na ktory uploaduju nejake "pocitace" nejake subory a server ich iba uklada na disk. Pre predstavu skusme mat server s procesorom ktory zvladne duke nukem a ma mechanicky disk s rychlostou zapisu napriklad 10MB/s. A klientov dajme 10000 (nech to je 10k problem aspon . Samozrejme kazdy klient cez svoje wifi/bluetooth/idra posiela data rychlostou napriklad 500 bajtov za sekundu a ma za ulohu nahrat 1MB velky subor. Nech je sranda, klienti zacnu posielat subor naraz... (cielom je ukazat rozdiel medzi non-blocking a async. Jeden z nich je nutny na to, aby klient, ktory sa pripoji ako druhy, mohol zacat nieco dalsieho posielat a druhy je nutny, aby to dany cpu zvladol, respektive venoval sa aj robote a nielen "context switchingu")

Takze tech 10000 klientu, resp. 10000 socketu, budu obsluhovat v jedinem vlakne pres epoll. Protoze ten disk mi stejne umoznuje jenom sekvenci zapis, tak budu mit druhe vlakno, ktere bude mit frontu na zapisy. No a po bajtech budu cist z tech socketu a posilat to do fronty. Fronta bude blokujici a mit jen urcitou maximalni velikost.

Vystaci na to 2 vlakna. No a ted problem je, ze nekteri by na to byli schopni udelat event loop, nebo na to napasovat Actor design pattern. A ruzne takove dalsi "fajnove" veci.

Řešení přes epoll implikuje smyčku událostí.

To si nemyslim, smycka udalosti je z podstaty jiny typ mechanismu nez epoll.

204

Vývoj / Re:Naučení se asynchronnímu programování

« kdy: 10. 10. 2019, 23:54:04 »

Nerád by som narušil plodnú diskusiu, ale skúste zadefinovať výraz "non-blocking" a potom opäť hladať definíciu asynchronicity...

Sidenote, je tu nejaký C/C++ kóder? Imho by vedel pekne vysvetlit, naco sa pouziva epoll a preco necakame na prijatie nejakych bajtov po sieti inym sposobom?

Sidenote2: Skusme rozobrat hypoteticku ulohu. Nakodit server, na ktory uploaduju nejake "pocitace" nejake subory a server ich iba uklada na disk. Pre predstavu skusme mat server s procesorom ktory zvladne duke nukem a ma mechanicky disk s rychlostou zapisu napriklad 10MB/s. A klientov dajme 10000 (nech to je 10k problem aspon . Samozrejme kazdy klient cez svoje wifi/bluetooth/idra posiela data rychlostou napriklad 500 bajtov za sekundu a ma za ulohu nahrat 1MB velky subor. Nech je sranda, klienti zacnu posielat subor naraz... (cielom je ukazat rozdiel medzi non-blocking a async. Jeden z nich je nutny na to, aby klient, ktory sa pripoji ako druhy, mohol zacat nieco dalsieho posielat a druhy je nutny, aby to dany cpu zvladol, respektive venoval sa aj robote a nielen "context switchingu")

Takze tech 10000 klientu, resp. 10000 socketu, budu obsluhovat v jedinem vlakne pres epoll. Protoze ten disk mi stejne umoznuje jenom sekvenci zapis, tak budu mit druhe vlakno, ktere bude mit frontu na zapisy. No a po bajtech budu cist z tech socketu a posilat to do fronty. Fronta bude blokujici a mit jen urcitou maximalni velikost.

Vystaci na to 2 vlakna. No a ted problem je, ze nekteri by na to byli schopni udelat event loop, nebo na to napasovat Actor design pattern. A ruzne takove dalsi "fajnove" veci.

205

Vývoj / Re:Naučení se asynchronnímu programování

« kdy: 10. 10. 2019, 23:41:12 »

.

206

Vývoj / Re:Naučení se asynchronnímu programování

« kdy: 10. 10. 2019, 07:49:18 »

Prisel jsem na to, co to vlastne u sw developmentu to asynchronni znamena. Vztahuje se to k tomu, ze mam nejake behove programove flow, a to flow ma nejakou posloupnost v pogramovem kodu. Mira asynchronity aplikace je mira toho, jak moc se skutecne flow pri behu aplikace, ktere muze byt v podstate reprezentovano Stacktrace vlakna, lisi od posloupnosti kodu aplikace, tak jak ji prirozene vnima programator. Jde tedy o miru asynchronity vzhledem k tradicni programatorske ergonomii pri programovani aplikace. Kdyz se to lisi hodne, ba dokonce je nam stacktrace uplne na govno, jako v pripade Event loop, tak mira asynchronity je vysoka.

Kdyz mam system na zpracovani objedavek, tak vyrobeni objednvky vzhledem k uzivateli je mozna asynchronni prvek, nicmene je to neco odlisneho od pojmu asynchronni programovani.

No a ja rikam, abyste neprogramovali asynchronne, protoze je to na 3.14cu, protoze to nema dobrou ergonomii

Coz mi pripomina, jak asi vypada stacktrace v pripade Coroutin s await async. Zda-li je zmrsena, nebo zda-li vypada stejne jako kdybych asynchronni cast kodu provedl v samostatnem vlakne, tedy ze ta odvetvena cast kodu ma svou vlastni peknou stacktrace.

207

Vývoj / Re:Naučení se asynchronnímu programování

« kdy: 09. 10. 2019, 21:10:43 »

Hosi nevyrabejte asynchronni systemy, nebo se z toho zblaznite.

No ještě jsi neodpověděl na otázku "Co to je "synchronní systém na zpracování objednávek"?", takže nevíme, co nemáme vyrábět.

Synchronni system na zpracovani objednavek je system na zpracovani objednavek takovy, ktery nezpracovava objednavky asynchronne.

A asynchronní definuješ

Ja si myslim, ze asyncrhonni znamena neco konkretniho a docela presne. Znamena to totiz, ze neco neni neni synchronni.

Genialni, ze?

208

Vývoj / Re:Naučení se asynchronnímu programování

« kdy: 09. 10. 2019, 20:36:51 »

Hosi nevyrabejte asynchronni systemy, nebo se z toho zblaznite.

No ještě jsi neodpověděl na otázku "Co to je "synchronní systém na zpracování objednávek"?", takže nevíme, co nemáme vyrábět.

Synchronni system na zpracovani objednavek je system na zpracovani objednavek takovy, ktery nezpracovava objednavky asynchronne.

209

Vývoj / Re:Naučení se asynchronnímu programování

« kdy: 09. 10. 2019, 17:59:32 »

Ja si myslim, ze asyncrhonni znamena neco konkretniho a docela presne. Znamena to totiz, ze neco neni neni synchronni.

Jasný. A "synchronní" znamená, že to není asynchronní, ne?

V synchronnim systemu zpracovani objednavek na takovy problem nenarazis.

Co to je "synchronní systém na zpracování objednávek"? Tam nejsou fronty? Nedá se to škálovat na víc počítačů? Když kliknu na webu, tak ten web zmrzne, dokud někdo ve skladu objednávku fyzicky nevyřídí a neklikne na "odesláno"?

Nebo co to je?

"Slovo Asynchronie, asynchronní označuje stav, který není synchronizován"
https://cs.wikipedia.org/wiki/Asynchronie
 

Asynchronni system na zpracovani objednavek je system, ktery je uplne na 3.14cu

Hosi nevyrabejte asynchronni systemy, nebo se z toho zblaznite.

210

Vývoj / Re:Naučení se asynchronnímu programování

« kdy: 08. 10. 2019, 22:00:46 »

Mrkni na dnešní Event Sourcing, CQRS, Eventual consistency. Problémy jsou stále stejné. Např vytvoření objednávky v systému, vytvoří se událost, událost se vloží do fronty, z fronty událost vybere nějaky microservice, a vytvoří objednávku ve své databázi. Client pošle dotaz na vytvořenou objednávku, ale objednávka není ještě uložena. Client pošle dotaz znovu, objednávka stále není vytvořena a řekněmě, že už postráda smysl. Co teď? Je operace idempotentní? Zrušit? Jak? Kompenzační událost, která zruší předchozí událost? Jak? Událost je pravděbodobně stále ve frontě a čeká na zpracování. Takže objednávka muže existovat než příjde kompenzační událost na řadu?

Tady jsi krasne ukazal, jak se muzes zamotat do Asynchronniho programovani. V synchronnim systemu zpracovani objednavek na takovy problem nenarazis. Tak je to dycky s tim asynchronnim udalostmi rizenem programovani. Myslis si ze sis neco ulehcil, ale pritom neulehcil, protoze musis resit takoveto filozoficke problemy.