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 - Standa Blábol

Stran: [1] 2 3 ... 19
1
Hardware / Re:Nový notebook hučí jako vysavač
« kdy: 09. 05. 2025, 08:29:51 »
Na IT praci se u Leninova kupuje Thinkpad rada P, T, kdyz malo penazi tak E.
Jeste bacha na suffix S, treba P16s, to s znamena šméčko.
Thinkbook neni Thinkpad

Thunkbook je perfektni pro uctarnu, obchodnika, holky z HR, kde nejvetsi zatez dela excel.

2
Software / Re:Software pro test zátěže webu
« kdy: 24. 04. 2025, 17:01:32 »
https://github.com/JoeDog/siege

Pokud jsou ty stranky SPA a backend je jenom cisty REST, pak jedine selenium/chromedriver/chrome - existuje na to komplet docker, ktery ma tohle vsecko v sobe

3
/dev/null / O2 šméčko při přechodu O2TV na Oneplay
« kdy: 22. 04. 2025, 13:02:26 »
Používám O2 internet a k tomu jsem mel přibalenou nepoužívanou službu O2TV Modrá zdarma.
Při současném přechodu na Oneplay je tato služba změněna na placenou službu Oneplay Komfort za 200Kč.
Reálná náhrada je tarif "Oneplay k internetu" zdarma, v aplikaci Moje O2 však tuto volbu není možno vybrat, nikde se ani nepíše o její existenci.

Je nutno zavolat na 800 02 02 02, odpalkovat AI, a probojivat se k živému operátorovi, kterému nutno říct, že chcete "Oneplay k internetu"
Operátor změnu provede a v seznamu tarifů se tento tarif ukáže.

Pokud pouzivate internet od O2, doporucuju kontrolu v aplikaci moje O2 a viz postup výše.

4
Server / Re:Nevýhody InnoDB oproti MyISAM v MariaDB
« kdy: 17. 04. 2025, 22:29:10 »
Jo a nezapomen pak i na to patroni, kde bude leader urcen ciste pro zapisy a cteni backup dat apod na replikach.
jako bonus k tomu dostanes HA setup.

Pomoci haproxy nebo pgbounceru s externim chckem leadera si vystavis port pro zapis na 6543, port pro ciste cteni z repliky na 7432 a tvoje aplikace nemusi zadne prepinani nijak resit, staci aby umely reconnect spadle konexe

5
Server / Re:Nevýhody InnoDB oproti MyISAM v MariaDB
« kdy: 17. 04. 2025, 22:22:13 »
Jo a postgresa instaluj z postgresql.org, anzto tuto verzi podporuji originalni timescale baliky
V distre h byva postgres i timescale, ale jenom v pure OSS variante, ktera je orezana a neumi komprimaci. Potrebujes community versi, to je mezistupen mezi pure OSS a komercni variantou

6
Server / Re:Nevýhody InnoDB oproti MyISAM v MariaDB
« kdy: 17. 04. 2025, 22:18:06 »
Mno, nebylo receno o jaka data jde, lec kdyz je rec o mozne ztrate 20 vterin dat, asi pujde o nejaky time-series.
A na to je v postgresu extenze TimescaleDB, ktera ma luxusni vlastnosti vcetne automatickeho komprimovani time-series dat, vysledek je ze zabere na disku cca 10% mista. Resi problematiku ruchleho zapisu.
K tomu patroni cluster a prohledavani dat a backup resit na online replice.

Jedná se o telefonní hovory. TimesclaDB vypadá, že by  mělo jít použít i když to není úplně typický případ a nenašel jsem žádný příklad, že by to někdo používal na ukládání hovorů.  Každý hovor má hodně atributů. Nejdůležitější je čas, linka, uživatel, volající, volané číslo, délka, délka zvonění,destinace, cena. A spousta dalších méně důležitých atributů.

Asi by to chtělo ze začátku ukládat tím starým způsobem a navíc i do TimescaleDB. Mohu tam také zkušebně nalít ty data zkusit jestli se operace výrazně zrychlí. V každém případě by to byl dost velký zásah v porovnání jen se změnou z MyIsam na InnoDB.

jednodusene receno, timescale je parttitioning na steroidech. Pokud mas atribut, podle ktereho to muze data rozsekat na chunky, typicky cas, a pokud tcoje dotazy typicky dotazuji pres casova okna, hodne ti to pomuze.

PoC mas hotovy za den, pgloaderem natahej mysql data vcetne komplet steuktury do postgresu, ty velke datove tabulky zkonvertujj na timescale hypertabulky s kompresi treba pro tyden stare chunky. Co zkomprimujes uz neupdatujes, to ale v tvym usecase nevadi.
Hylertabulka je z pohledu klienta pro CRUD transparentni.
Hlavni prinos je hlavne v tom chunkovani, postgres pracuje jenom s prave potrebnymi chunky a i mazani starych dat se dela zahazovanim chunku bez nutnosri transakcniho delete.
 A pri instalaci nezapomen na timescaledb-tune, tahle utilitka ti poladi konfigurak postgresu

7
Server / Re:Nevýhody InnoDB oproti MyISAM v MariaDB
« kdy: 17. 04. 2025, 19:08:47 »
A když už do toho hrabete, nechcete to předělat rovnou na postgresql?
O tom jsem přemýšlel. Ale pokud vím postgreSQL vyniká hlavně  v konzistenci a pokročilém použití. Já spíše potřebuji jen hrubou rychlost a funkčnost 24/7 na což postgreSQL zas tak dobrý není. Pokud by se mi ztratil náhodně jeden záznam z milionu, netrápí mne to. Stejně tak mne netrápí kdybych např. při výpadku elektřiny (počítám že by se mohlo přihodit jednou za 10 let) přišel třeba o 20 vteřin dat. Naopak kdybych musel někdy v noci opravovat či optimalizovat nějakou tabulku třeba půl hodiny a proto ji uzamčít, je to velký problém.
A taky se mi nechce učit nic nového, když vlastně nevím jestli bych si vůbec polepšil. Spíše nikoli.

Od MyISam odcházím z toho důvodu, že zápisy blokují následující čtení.    Tedy pokud bych měl dva delší selecty, mohou probíhat paralelně bez problémů, pokud mezi nimi nebyl žádný zápis. Ale pokud v okamžiku delšího selectu přijde zápis, tak ten čeká na dokončení selectu. A následující select zase čeká na dokončení toho zápisu, takže se to celé ucpe jen kvůli jednomu delšímu selectu.  To by mělo innodb vyřešit.  Pokud by ale existovala možnost nastavit u MyIsam, že má zápis menší prioritu než čtení a zápis by čekal až na okamžik, kdy není žádný požadavek na čtení, mohli bychom dále používat myIsam. Zápis je totiž  v našem případě vždy rychlý. Ale bohužel změnit tu prioritu se mi nepovedlo.

Mno, nebylo receno o jaka data jde, lec kdyz je rec o mozne ztrate 20 vterin dat, asi pujde o nejaky time-series.
A na to je v postgresu extenze TimescaleDB, ktera ma luxusni vlastnosti vcetne automatickeho komprimovani time-series dat, vysledek je ze zabere na disku cca 10% mista. Resi problematiku ruchleho zapisu.
K tomu patroni cluster a prohledavani dat a backup resit na online replice.


8
Hardware / Re:Doporučte notebook okolo 1000 eur
« kdy: 17. 02. 2025, 08:59:36 »
Lenovo E16 gen2

Existuje spousta variant, u alzaka se to da porovnavat, prepinat mezi variantama.
Ma to 2xDDR5 slot a 2xNVME.
Osobne bych sel variantou koupit zakladni verzi a strcit si to toho svoje RAM (2x32) a druhy NVME, pokud bude potreba.
Upgrade je trivialni, staci odsroubovat zadni dekl a vse je krase pristupne.

S takovym setupem si muzes udelat v Podman desktop minikube cluster (i na windows) a vyvijet na tom.

9
Vývoj / Re:Proč se cpe JavaScript na backend?
« kdy: 07. 02. 2025, 10:57:36 »
O PHP nema cenu se bavit, to zoufale bylo, je a bude.
A hlavne uz pristi rok umre, uz dvacet let :-)

To si nemyslim.
PHP tu bude s nami i nadale, stejne jako krysy, tyfus a nestovice.

10
Vývoj / Re:Proč se cpe JavaScript na backend?
« kdy: 07. 02. 2025, 09:12:16 »
Tohle je zrovna taková školácká chyba. Už v úvodu do Javy se člověk dozví, že == porovnává u objektových typů přesnou shodu (tatáž instance). Tzn. že to pro 100 zrovna vrátí true je jen náhoda resp. optimalizace, ale používat to nemáš. To ti řekne i IDE (třeba NetBeans).

Na rozdíl od třeba C++ tu není přetěžování operátorů, takže == se chová všude stejně. Jestli je to dobře nebo špatně, to je otázka - asi jak pro koho - ale vzhledem k tomu, že to je jazyk pro široké masy, tak je to asi spíš dobře.

nikoliv náhoda, ale jak správně píšeš, optimalizace, dokumentovaná ve specifikaci, probíhá unboxing malých 8-bitových čísel (-127 až 128). Ano, je to školácká věc, avšak dokáže potrápit kdejakého zajetého vývojáře, když nemá IDE.

Ano, stejně tak mi IDE řekne ty chyby s porovnáním v JS. O to právě vůbec nejde. Horší je, když se ten jazyk chová nedetermisticky v čase. Tohle se naučíš a nepříjde ti to.

PHP je na webu velmi rozšířené, přitom to je jazyk, které není schopný ani sjednotit argumenty a názvy funkcí, ještě se nesbavil memory leaků a jediný lék je pravidelný restarat interpreta, ve  výsledku to ale provoz nijak moc nevadí a lze s tím žít.

Tohle jsou argumenty, které můžeme my řešit u piva, ale pro aplikace to je jedno, je jedno jestli je jazyk více vláknový se zámky nebo to fejkuje přes event loop a asynchronní IO zase vlastně na té aplikaci a vývoji nemusí jít vůbec poznat (z pohledu času vývoje, náročnosti na zdroje, chybovosti atd. atd.)

Po těch letech vývoje mi je asi šumák v čem je BE/FE aplikace napsaná, důležité je, že jí bude možné dalších X let provozova a vývoj dokončit.

Dnes se bez IDE programovat neda a popravde netusim jediny duvod, proc IDE nepouzivat.
Argument o nepouziti IDE je toho ranku, jakoze kdyz nepouziju klic od zahradni branky, polezu pres plot.

Nemyslim si, ze je sumak, co bezi na backendu, prave z toho duvodu dlouhodobe podpory.
Kdyz vezmu 20 let stare WAR tak ho na novem Tomcatu rozjedu bez potizi, max veci typu rename javax-jakarta, ktere jsou peclive popsane a jsou na to konverzni tooly.
Na javascript se podivam za dva mesice, npm upodate plne hlasek o deprecated modulech, CVEcka az na mesic, nektere modyly skoncily po roce vyvoj a mam nahradit alternativou, typicky se stejne jepicim zivotem.
Do JS/TS projektu se musi NEUSTALE hrabat a kdo chvili stal uz stoji opodal.

Pararelizace dtto, Java spolu se Spring podporou velice slusne ale tezkotonazni, NodeJS Async/Await je hnus vedoici k chaosu v kodu, nejlepsi mechanismus asi goroutines/channels. A java obdoba korutin "Project Loom - Virtual Threads" ma podporu v Java 21 a Spring Boot 3.2.

O PHP nema cenu se bavit, to zoufale bylo, je a bude.

Takze mas castecne pravdu, pro male veci je celkem jedno, co je vespod a typicky se to naplaca v necem, co dostupny Lojza programator ovlada. Pokud potrebuju dlouhodobou stabilitu a udrzovatelnost, pak Java/Spring/MavenCentral/ApacheFundation. A pro masivni vykon kontejnery a mikroservisy, ty jednodussi treba v GO.

11
Vývoj / Re:Proč se cpe JavaScript na backend?
« kdy: 06. 02. 2025, 09:08:05 »
Dnešní Jakarta (dříve Java EE) nebo Spring startují v řádu několika vteřin

Ten byl dobrej, před víkendem pobavilo.  ;D

A copa te tak pobavilo?
Ted delam na backendu pro jeden portal, SSO auth keycloak, hibernate postgres, MVC a REST, takze moduly WebMVC, Security a JPA, start 4 sekundy na mem notebooku Lenovo P15 z roku 2022.

Je to ale krapet nezajimavy parametr, mam samozrejme zapnute Spring DevTools a ty meni classy za behu bez restartu, stara se o to VSCode plugin. Obcas to ten plugin otoci za cca 3 sekundy, to kdyz se hrabne do Beans dependency tree, jinak vetsinou ten class hotdeploy.


12
Server / Re:Reporting nad databází PostgreSQL
« kdy: 19. 12. 2024, 07:01:27 »
Pro tyhle ucely jsem pouzival BIRT nebo OS variantu Jasper Reports
Zrovna BIRT ma vyhodu v oeknem wysiwyg editoru, az vysledek doladis, vyexportujes XML definici, ktera je pak vstupem pro embedded BIRT viewer

13
V konzoli "net use"
A pro to, co nechces, "net use /DELETE"

Google a ChatGPT jsou tvoji pratele.

14
Vývoj / Re:Produktivita vývojáře v době AI
« kdy: 10. 10. 2024, 19:51:48 »
Pouzivam placenyChatGPT prakticky na vsechno, co pred tim resil Google.

Treba namatkou grep s regexem, co z konfiguraku odfiltruje zakomentovane a prazdne radky, napady co uvarit na veceri, ktery den v tydnu je Benatkach nejmin lidi, JSONpath vyraz pro vyhledani atributu z poskytnuteho vzrorku, jak pomoci openssl vypsat lastUpdate z CRL souboru, kod jednoduche javascript funkce s omezenim na uroven ES5, aby fungoval v embedded enginu Duktape a spoooustu dalsiho.

15
Vývoj / Re:JS: Ako najst spravnu poziciu v textarei?
« kdy: 19. 08. 2024, 08:43:45 »
Zkuz pouzit JS komponentu typu Editor, ktera je pro tyto ucely delana.

Napr Quill a jeho metodu getBounds()

https://quilljs.com/docs/api#getbounds

Stran: [1] 2 3 ... 19