1
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« kdy: 08. 10. 2025, 15:03:12 »
Jenom pro zajimavost, rust neznam, jde v rustu udelat carmackuv fast inverse square root?
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.
2
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« kdy: 06. 10. 2025, 14:39:21 »Co se tyce knihoven vs vlastní kod, je tu este vykonovy aspekt.
Psal jsem nedavno jeden primitivni stream procesor, na stdin prijde hromada JSONu, udela to urcitou analyzu pres klouzave okno, vysype na stdout, slouzi jako plugin do jineho softu.
Prototyp v pythonu funguje ok.
Predelavka do go s ocekavanim narustu vykonu, realita, vykon je tretinovy.
Profilingem zjisteno, ze python je sice pomalejsi jazyk, ale ze jeho knihovny pro práci se stdio a JSON jsou mnohem rychlejsi, zrejme psane v C.
A ja se obavam, ze moje knihovny hy hyly este horsi, nez ty GOckove.
To mi přijde velmi podezřelé.
Co se týče stdin, tak tuším, že v pythonu je ve výchozím stavu bufferovaný, v golang ne. Jinak nevím, v čem by práce se stdin mohla být jiná/více optimální.
No, to je prosta realita. JSON processing pomaly jaxvina a co se tyce stdio, golang furt na neco cekal, veru nevim na co. Ted uz nemam vystup profileru, ale tusim, ze se tam potloukal GO oblibeny pthread_cond_wait, pricemz neslo o nic jinyho, nez vzit stdio nasekany podle newline a strkat do nekolika channelu, kde si to prebiraly gorutiny. Pokusel jsem se tam pozapinat nejake lepsi nez default cachovani, ale to pomohlo tak 20% vykonu nahoru.
A popravde GO samo sebe nijak nepropaguje jako realtime jazyk, proto me prekvapuje, ze se chova v defaultu tak debilne.
A veru me sejri, ze i takovou trivialitu musim resit a ladit, v pythonu pro pojidace kolacu jede vse na lusknuti prstu...
3
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« kdy: 29. 09. 2025, 11:45:42 »A to jste vzal kde? Zas nějaký pochybný žebříček, který se vždycky co měsíc totálně zpřehází? C++ a Java jsou z hlediska jobu sázky na jistotu a zároveň dobrého ohodnocení. Ani jeden z těchto jazyků přitom nemusím a nedělám v nich, i když se asi připravuju o peníze (duševní zdraví je mi cennější - správný objektový návrh umí udělat málo lidí, rozhodně mnohem méně, než kolik se jich o to pokouší, resp. se to po nich chce - mně tento design programu také není blízký a evidentně ani autorům většiny učebnic OOP; problém navíc je, že jen málokdo si to dokáže sebekriticky přiznat).Pokud se tím plánuješ živit, tak odpověď je "spíš ne". Full-time jobů v Rustu (ne RUSTu btw) je docela málo. Full-time jobů v Javě je hodně. Rust totiž za rychlost běhu programu platí větší pomalostí při psaní kódu (je fakt hodně přísnej) a to se na většině projektů nevyplatí.
jop ,je tak nevyužitelný ze rust programatori jsou nejlépe ohodnoceni v oboru zatímco ta jista java se nedostala ani do první sedmičky a to tam najdeš jak go tak python + typescript a kotlin a bonus .. scalu
A pritom je OOP tak strasne jednoduchy koncept.
Staci znat par pravidel a selsky rozum, objektovy je cely svet vukol.
Staci vedet, ze kdyz ten jazyk nejake moznosti nabizi, ze je veru neni potreba nasrat vsude.
Ze napr. dedeni se pouziva, kdyz potrebuju ROZSIRIT funkcionalitu existujiciho objektu, pokud potrebuju jenom polymorfismus, na 99% bude vhodnejsi prosty interface.
Ze je potreba selsky rozum, abych dovedl poznat, ktery objekt je v danem kontextu aktorem, ktery je prosty objekt, se kterym aktor manipuje.
Vidle.naberHnuj(hnuj) je spravny pristup
Hnuj.naskocNaVidle(vidle) je magorina.
Pak je potreba v ramci mozkoveho mysleni este urcit, ze v danem kontextu objet User zrejme nebude clovek, alebrz vstupni karticka, co se strka do pichacky a kterou se oteviraji dvere, ze je treba lepsi ten objekt pojmenovat AuthToken a tedy ze neni potreba do toho nasrat i cislo bot realneho Usera, to se klido strci do jineho objektu, co upravdu reprezentuje cloveka.
A ano, knizky o OOP jsou vetsinou blbe, tam prave dedi trojuhelniky a ctverce z obecneho polygonu, aby ve zdedenem objektu vymenili sakuprask vsecko, tady je lepsi prosty interface.
Chapu, ze treba Spring Boot potrebuje vsecky ficury javy vcetne introspekce a apod. Prave proto Spring vznikl, aby bezny programator business logiky se s tim prdolit nemusel.
Ja pri psani ve Springu z celeho OOP pouzivam interfacy (popr anotace, tedy interfacy v jinem formatu), encapsulaci a konec.
4
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« kdy: 27. 09. 2025, 07:31:00 »
Co se tyce knihoven vs vlastní kod, je tu este vykonovy aspekt.
Psal jsem nedavno jeden primitivni stream procesor, na stdin prijde hromada JSONu, udela to urcitou analyzu pres klouzave okno, vysype na stdout, slouzi jako plugin do jineho softu.
Prototyp v pythonu funguje ok.
Predelavka do go s ocekavanim narustu vykonu, realita, vykon je tretinovy.
Profilingem zjisteno, ze python je sice pomalejsi jazyk, ale ze jeho knihovny pro práci se stdio a JSON jsou mnohem rychlejsi, zrejme psane v C.
A ja se obavam, ze moje knihovny hy hyly este horsi, nez ty GOckove.
Psal jsem nedavno jeden primitivni stream procesor, na stdin prijde hromada JSONu, udela to urcitou analyzu pres klouzave okno, vysype na stdout, slouzi jako plugin do jineho softu.
Prototyp v pythonu funguje ok.
Predelavka do go s ocekavanim narustu vykonu, realita, vykon je tretinovy.
Profilingem zjisteno, ze python je sice pomalejsi jazyk, ale ze jeho knihovny pro práci se stdio a JSON jsou mnohem rychlejsi, zrejme psane v C.
A ja se obavam, ze moje knihovny hy hyly este horsi, nez ty GOckove.
5
Vývoj / Re:Framework vs. čistý kód
« kdy: 19. 08. 2025, 09:52:29 »Každý framework má nějaké části, které nejsou ideální, někdy i úmyslně z důvodu, že se jedná o experimentální složku frameworku a vy jste testeři.
Nebudu tady říkat, co třeba má Spring, se kterým denně dělám, ať se tu zase nepřetahuju zbytečně s Jirsákem.
Mimochodem, není tak velký rozdíl v principu používání mezi Reactem a třeba vanilla PHP. Těch rozdílů není zase tolik, jak by se mohlo zdít, když je mým cílem udělat fungující web. Hlavní a zásadní rozdíl vidím v tom, že React mi umožňuje definovat model pro moje formuláře (tím je JS objekt), kdežto v PHP musím ručně vepisovat "name" atributy (definuju si je jako konstanty).
V Javě to nebyli schopni něco podobného udělat až do vzniku Thymeleafu, a i Thyemeleaf má problémy s fragmaenty a jejich podporou v IDE, kde pro takto zásadní a elementární věc nefunguje ani našeptávání parametrů do fragmentu. To mě brutálně točí.
A proč to říkám a proč mě to tak sejre. Protože tím, že všechno to byly kompromisní technologie, kde jedna měla haprující to a druhá zase ono, tak kvůli tomu je všechny převálcoval React, který má vesměs všechno Done right. A jeden z důvodů, proč je React všechny převálcoval, jsou "ty kecy a kydy" co se tady dlohá desetiletí šířily, že backing kód musí být v separátním souboru, a do template si musím všechno připravit předem a ani Math.round si tam asi nesmím v tom template zavolat. Jedním ze šiřitelů těchto polopravd a frází je mimochodem i Jirsák.
Heh, to je ale snuska blabolu. Jojo, dokud Pivotal neprisel s Thymeleafem, nic jako JSTL (defacto to samy jako Thymeleaf, ktery prinesl jenom jednodussi syntaxi) neexistovalo. A JSF2 taky neexistuje.
A widgety taky neexistujou, Apache Wickets je dilo heretiku.
A treba JSF2 widget library Primefaces, tady mas jednu nahodne vybranou komponentu na ukazku
https://showcase.primefaces.org/ui/menu/menubar.xhtml?jfwid=cb934
V realu se React rozsiril z jedineho duvodu, a to ze je v javascriptu spustitelnem v browseru, tedy vhodny pro client-side SPA aplikace a rozsiril se jenom proto, ze byl prvni.
Jinak je Ract naprosty otres navrzeny magory, co v zivote o computer science neslyseli, eco jako useEffect() muze vymyslet jenom jouda, co v zivote nevidel jediny navrhovy vzor...
Naproti tomu pozdeji vznikle VUE bylo navrzeno clovekem s prislusnym vzdelanim a VUE3 se "script-setup" syntaxi, typescriptem, k tomu Vue router a Pinia je uz velice slusny stack, co neurazi cloveka s alespon matnyM tusenim o computer science...
6
Vývoj / Re:Framework vs. čistý kód
« kdy: 18. 07. 2025, 09:13:06 »Ahoj, mam dotaz na vas profesionaly.
Kamarad mi rikal ze opravdovy programator nepouziva framework. Prirovnava to k horolezci s kyslikem (framework) a bez kysliku (real programator). Framework je podle nej vlastne "podvod"...
Co si o tomto nazoru myslite?
Ze je to blbec.
7
Vývoj / Re:Moderný frontend - ako na to?
« kdy: 05. 07. 2025, 16:18:49 »
A co je, probuh, na Vue3 sloziteho?
Prumernemu gibbonovi na pochopení staci dopoledne a Vetur plugin ve VSCode si vsecko pohlida.
Vue ma jediny problem a to zastarale turorialy roztahane po webu.
Staci se ucit z oficialnich zdrouju, tedy script-setup a s typescriptem, k tomu router a pinia, opet trivialni, a mam luxusni komponentove orientovany nastroj.
Navic pro to existuje hromada hotovych komponent, treba PrimeVue.
Chapu, ze nekdo neni nadseny z Reactu, protoze to splacali matlaci, ale VUE navrhoval clovek s Computer science backgroundem a je to videt
Prumernemu gibbonovi na pochopení staci dopoledne a Vetur plugin ve VSCode si vsecko pohlida.
Vue ma jediny problem a to zastarale turorialy roztahane po webu.
Staci se ucit z oficialnich zdrouju, tedy script-setup a s typescriptem, k tomu router a pinia, opet trivialni, a mam luxusni komponentove orientovany nastroj.
Navic pro to existuje hromada hotovych komponent, treba PrimeVue.
Chapu, ze nekdo neni nadseny z Reactu, protoze to splacali matlaci, ale VUE navrhoval clovek s Computer science backgroundem a je to videt
8
Vývoj / Re:Možnosti mobilných aplikícií
« kdy: 29. 06. 2025, 08:11:22 »
Jako prvni bych zacal se studiem, co to vubec OAUTH/SSO je, pak bych procet kapitolku Keycloak, Getring started
9
Vývoj / Re:Komerční web a SEO - JQuery a PHP?
« kdy: 19. 06. 2025, 09:13:00 »
Podivej se na Nuxt3, pokud mas neco rozdelaneho ve vue, prvni volba.
Umi to i hybrid rendering, kde si jenom SEO important casti nechas udelat serversice a ostatni jako klasicke clientside vue komponenty.
Jako prvni pokus klidne jenom spravne nastavovat title a meta tagy.
Umi to i hybrid rendering, kde si jenom SEO important casti nechas udelat serversice a ostatni jako klasicke clientside vue komponenty.
Jako prvni pokus klidne jenom spravne nastavovat title a meta tagy.
10
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.
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.
11
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
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
12
/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.
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.
13
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
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
14
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
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
15
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
