361
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.
362
Odkladiště / Re:Bezpečnost elektronických voleb
« kdy: 30. 08. 2020, 17:55:31 »nemel duvod cokoliv manipulovat, i podle opozice Lukasenko ziskal pres 60%, vyhral by tak jako tak, obvineni z manipulace by prisla tak jako tak, ty protesty byly planovane davno pred volbami (vzpomente na zatcenou Cesku), probehly by nezavisle na jejich prubehu. Cele je to divadlo, treba ti stavkujici byli udajni "byvali zamestnanci" tech podniku, soucasni zamestnanci se od toho distancuji. Opozice je financovana ze zahranici, musi vykazovat cinnost, aby nenastvala sponzory. https://www.newsbreak.com/news/2046657620645/leader-of-belarus-opposition-meets-with-bernard-henri-levi-frances-leading-cruise-missile-internationalist„[Některé volby] jsou jen divadýlkem pro ty, co kolaborují s autoritářským režimem (včetně lidí v zahraničí – autoritářské režimy mají bůhví proč spoustu sympatizantů v jiných státech).“ Tím jsem ale nemyslel, že se tu hned musíte hlásit.
vas nazor, pro me jste kolaborant vy, pokud sympatizujete se silami stojicimi za jejich opozici.
363
Odkladiště / Re:Bezpečnost elektronických voleb
« kdy: 30. 08. 2020, 16:19:06 »Chtěl bych oživit tuto mrtvolku aktuálním tématem. Opakovaně zde a ve vedlejší diskuzi zaznívalo, že papírové volby nejde large-scale manipulovat, protože byste museli podplatit každou volební komisi, kterých je moc.Papírové volby je těžké manipulovat, protože je třeba ovlivnit hromadu lidí. To je náročné a hrozí že to praskne.
Co se stalo v Bělorusku?
Ale pak samozřejmě záleží na tom, jestli má někdo potřebné prostředky a moc. A taky co se stane, pokud to praskne.
Někdo jako Lukašenko má dostatečnou moc a hrozí mu zatraceně málo. V Bělorusku prostě všichni mimo pár fanatiků tuší, že je to totální fraška. Akorát se k tomu různí lidé staví různě.
V našem kontextu je taková manipulace výrazně méně pravděpodobná.
nemel duvod cokoliv manipulovat, i podle opozice Lukasenko ziskal pres 60%, vyhral by tak jako tak, obvineni z manipulace by prisla tak jako tak, ty protesty byly planovane davno pred volbami (vzpomente na zatcenou Cesku), probehly by nezavisle na jejich prubehu. Cele je to divadlo, treba ti stavkujici byli udajni "byvali zamestnanci" tech podniku, soucasni zamestnanci se od toho distancuji. Opozice je financovana ze zahranici, musi vykazovat cinnost, aby nenastvala sponzory. https://www.newsbreak.com/news/2046657620645/leader-of-belarus-opposition-meets-with-bernard-henri-levi-frances-leading-cruise-missile-internationalist
364
Software / Re:Hrátky s textem
« kdy: 17. 08. 2020, 16:08:36 »doporucuji pouzivat perl jako nahradu sedu, dialekt regexu v sedu je v dnesni dobe dost nestandardniCož v tomhle případě nehraje žádnou roli, protože nejprimitivnější regex udělá přesně to co má.Kód: [Vybrat]sed 's/;.*;/;;/'
pravda, ale pokud je oddelovac delsi slovo, musite ho opakovat v nahrade.
365
Software / Re:Hrátky s textem
« kdy: 16. 08. 2020, 16:26:13 »Mirek Prýmek: Nikde jsem napsal co je nebo není středník. Moc se fixuješ na data v mém příkladu. Zleva může být jméno, ale taky to může být adresa. :-D
listoper: Díky moc, tvoje řešení funguje dokonale. Paráda, díky moc. :-)
Děkuji i všem, co se snažili mi pomoci.
nalevo pouzit nongreedy match
Kód: [Vybrat]
perl -pe 's/(.*?;).*(;.*)/$1$2/'
oddelovac muze byt i viceznakove slovo
Kód: [Vybrat]
perl -pe 's/(.*?slovo).*(slovo.*)/$1$2/'
doporucuji pouzivat perl jako nahradu sedu, dialekt regexu v sedu je v dnesni dobe dost nestandardni
366
Vývoj / Re:Kolko cyklov zbehne
« kdy: 13. 08. 2020, 17:20:33 »
Cele je to jeden cyklus, ktery probehne 12 krat, ty funkce vraci iteratory, zpracovava se to po jednotlivych prvcich.
367
Server / Re:Tabulka v MySQL (MariaDB)
« kdy: 04. 08. 2020, 16:53:53 »
selekt vsech sloupcu podle primarniho klice je rychly. Primarni klice jdou vyselektovat poddotazem nad materializovanym pohledem s tim neprimarnim indexem id. Asi se to lisi v ruznych DB. Neni to uplne primocare, ale podle me stale rychlejsi a uspornejsi na prostor nez v radkovych DB.
To nemůže být z principu - u tohoto typu dotazu prostě sloupcová databáze musí udělat víc operací než řádková databáze - bez ohledu na skutečnost, že sloupcové databáze dost často mají větší velikost stránky. A pokud uděláte materializovaný pohled (projekci ve Vertice), tak jste si defacto vyrobil řádkovou verzi vašich dat, za kterou samozřejmě zaplatíte při aktualizacích (prostor na disku, IO operace). Neexistuje formát (způsob) uložení dat, který by byl efektivní pro hromadné operace i pro operace nad jedním řádkem. Stonebraker (jeden z autorů Postgresu a Cstore (prototyp Vertiky)) dokazoval, že takový formát existovat nemůže.
i tech nekolik operaci byva v souctu rychlejsi, prave diky dokonalejsi komprimaci vetsinou pracujete s mensim mnozstvim dat.
Vertika neni uplne nejlepsi priklad state of the art sloupcove databaze https://clickhouse.tech/benchmark/dbms/
prezentace, ktera vyvraci to tvrzeni Michaela Stonebrakera https://www.percona.com/sites/default/files/ple19-slides/day1-pm/clickhouse-for-timeseries.pdf
368
Server / Re:Tabulka v MySQL (MariaDB)
« kdy: 04. 08. 2020, 16:11:15 »
prave mazani po celych dnech partioningem resit lze, ale diky mnohem mensim narokum na misto muzete mazat i po delsich intervalech.
zajimal by me konkretni selekt nad jednou tabulkou, ktery je v libovolne radkove databazi rychlejsi nez napr. v clickhouse, podle me budete mit problem jen vytvorit tak velkou tabulku v radkove databazi na beznem HW, na ktere by se sloupcova databaze zapotila.
SELECT * FROM tab WHERE id = 29292;
a id bude nad oindexovanym sloupcem s mene nez 1% vyskytu, a tabulka bude mit 20-30 sloupcu.
Jakmile byste zacal vic joinovat, a stale by se vyplatil nested loop, tak by se to sloupcovym databazim moc nelibilo. Mezi sloupcovymi databazemi jsou dost velke rozdily - ale pokud bych vzal ty, ktere maji podporu SQL - Vertika, Vectorwise, Monet, .. tak jsou optimalizovane pro OLAP ulohy nad denormalizovanym star schema, snowflake schema modelem. Tam funguji spickove, pro OLTP, a OLTP obvykle dotazy mohou byt pomalejsi - resp. to co je vyhodou pro OLAP je nevyhodou pro OLTP.
selekt vsech sloupcu podle primarniho klice je rychly. Primarni klice jdou vyselektovat poddotazem nad materializovanym pohledem s tim neprimarnim indexem id. Asi se to lisi v ruznych DB. Neni to uplne primocare, ale podle me stale rychlejsi a uspornejsi na prostor nez v radkovych DB.
369
Server / Re:Tabulka v MySQL (MariaDB)
« kdy: 04. 08. 2020, 14:34:48 »Pouzit sloupcovou databazi, ty jsou primo stavene pro tento use case. Selekty nad miliardami zaznamu v realnem case nejsou problem. Vetsinou maji mnohem dokonalejsi komprimaci, nahravani byva mnohem rychlejsi, mazani po dnech doporuceny zpusob. Nektere maji i rozhrani z/do mysql.
Jsou různé sloupcové databáze - nicméně mezi jejich silné stránky patří agregace nad větším balíkem dat, ale mohou mít pomalejší vyhledávání - právě díky komprimaci, která zlevňuje sekvenční načítání při hromadném zpracování, a naopak prodražuje přístup k nějakému konkrétnímu řádku. Pokud se nepoužije partitioning tak mazání, update záznamů je naopak velice pomalý - výrazně pomalejší než u řádkových databází. Takže hodně záleží na tom, co tazatel potřebuje a dělá, a také na konkrétní databázi - mezi sloupcovými databázemi jsou hodně velké rozdíly.
pochopil jsem dotaz tak, ze update zaznamu tazatel nepotrebuje, jen odmazavani starych zaznamu.
Jednak tam byl nástin seeku, který sloupcovým databázím nemusí být úplně po chuti (díky větší velikosti bloku), a i delete bývá na sloupcových databázích problém (pokud se neřeší partitioningem). Možná jste nemyslel sloupcové databáze, ale time series databáze - https://en.wikipedia.org/wiki/Time_series_database
prave mazani po celych dnech partioningem resit lze, ale diky mnohem mensim narokum na misto muzete mazat i po delsich intervalech.
zajimal by me konkretni selekt nad jednou tabulkou, ktery je v libovolne radkove databazi rychlejsi nez napr. v clickhouse, podle me budete mit problem jen vytvorit tak velkou tabulku v radkove databazi na beznem HW, na ktere by se sloupcova databaze zapotila.
370
Server / Re:Tabulka v MySQL (MariaDB)
« kdy: 03. 08. 2020, 21:58:21 »Pouzit sloupcovou databazi, ty jsou primo stavene pro tento use case. Selekty nad miliardami zaznamu v realnem case nejsou problem. Vetsinou maji mnohem dokonalejsi komprimaci, nahravani byva mnohem rychlejsi, mazani po dnech doporuceny zpusob. Nektere maji i rozhrani z/do mysql.
Jsou různé sloupcové databáze - nicméně mezi jejich silné stránky patří agregace nad větším balíkem dat, ale mohou mít pomalejší vyhledávání - právě díky komprimaci, která zlevňuje sekvenční načítání při hromadném zpracování, a naopak prodražuje přístup k nějakému konkrétnímu řádku. Pokud se nepoužije partitioning tak mazání, update záznamů je naopak velice pomalý - výrazně pomalejší než u řádkových databází. Takže hodně záleží na tom, co tazatel potřebuje a dělá, a také na konkrétní databázi - mezi sloupcovými databázemi jsou hodně velké rozdíly.
pochopil jsem dotaz tak, ze update zaznamu tazatel nepotrebuje, jen odmazavani starych zaznamu.
371
Server / Re:Tabulka v MySQL (MariaDB)
« kdy: 03. 08. 2020, 17:50:57 »
Pouzit sloupcovou databazi, ty jsou primo stavene pro tento use case. Selekty nad miliardami zaznamu v realnem case nejsou problem. Vetsinou maji mnohem dokonalejsi komprimaci, nahravani byva mnohem rychlejsi, mazani po dnech doporuceny zpusob. Nektere maji i rozhrani z/do mysql.
372
Vývoj / Re:CSS selektor podle následujícího elementu
« kdy: 27. 07. 2020, 14:03:23 »
Tohle v cistem css nejde, asi nejjednodussi reseni je pridat tem predchudcum tridu javascriptem.
373
Vývoj / Re:Názory na javascriptový framework Svelte
« kdy: 27. 07. 2020, 13:27:41 »Já taky dělám v Reactu, na Svelte jsem se podíval kvůli tomu hype co kolem něj je a mě teda nenadchnul. Přijde mi to jako dost prasárna. Na nějaký menší projekt je to asi OK, ale větší projekt bych v tom dělat (a hlavně debugovat) nechtěl. Že si netahá runtime také není pravda, runtime je ten vygenerovaný kód.
Na Reactu se mi líbí právě jeho jednoduchost. Koncept, že komponenta je jednoduchá funkce je prostě geniální. Ale chápu, že pro lidi zvyklé prasit něco s plain JS / JQuery je ten paradigm shift na komponentově orientovanou aplikaci netriviální a Svelte má výhodu v tom, že tam mohou alespoň jednoduché aplikace dělat (skoro) jak jsou zvyklí.
Resi to vykonostni problem Reactu v nekterych pripadech. S odsudky bych si pockal, za prasarnu byl ve sve dobe oznacovan i React.
374
Studium a uplatnění / Re:Office a remote práce po pandemii
« kdy: 26. 07. 2020, 19:15:41 »Nevim, co tu stale resite, uz pred pandemii existovala spousta firem umoznujici neomezeny remote. Ja tak pracuji roky. Je to vec poptavky a nabidky, asi to zas tak velke lakadlo na zamestnance neni.
Jednoduše se změnil tou pandemií kontext, tedy proto jsem toto téma chtěl otevřít. Pokud je někde podobné vlákno živé v posledním pár měsících, prosím dejte link. Rovněž se nebavím o full remotu, ale o hybridním modelu a jak to bude mít 80% lidí. Full remote bych upřímě nechtěl, dle zkušenosti z března, dubna a části května.
Proc by to firma delala? Je pro ne vyhodnejsi 100% remote, vyber zamestnancu neni omezen na lokalitu, nemusi pronajimat kancelar. Tech 20% casu v kancelari velky rozdil v neudela, ale stoji je penize. Proc byste vy trval na 20% ve firemni kancelari, kdyz musite mit zajistenou kancelar jinde?
375
Studium a uplatnění / Re:Office a remote práce po pandemii
« kdy: 26. 07. 2020, 18:40:38 »
Nevim, co tu stale resite, uz pred pandemii existovala spousta firem umoznujici neomezeny remote. Ja tak pracuji roky. Je to vec poptavky a nabidky, asi to zas tak velke lakadlo na zamestnance neni.
Musite mit vlastni kancelar v dome nebo nekde pronajimat, pro vetsinu lidi je kancelarske misto ve firme plus.
Musite mit vlastni kancelar v dome nebo nekde pronajimat, pro vetsinu lidi je kancelarske misto ve firme plus.
