Příspěvky

1

Vývoj / Re:Vezme AI ajťákům práci?

« kdy: 30. 11. 2025, 10:02:46 »

Ad viz vyse:

LLM samozrejme nezvysuje senioritu, lec VYRAZNE zvysuje produktivitu.

Anzto vyznamne snizuje mentální zatez zpusobenou trivialitami vukol.

Ukoly typu vytvor typescript formatovaci funkci, ktera prevede cislo na lidsky citelny text se suffixem K,M,G,T davam komplet LLM a funguje to dobre. Usetrim tim 10 minut prace ale hlavne usetrim unavu mozku, ktery svoje kapacity muze venovat necemu podstatnejsimu.

Opravdovou dusevni praci neni mozno delat dyl nez par hodin denne a cokoliv co mozku odlehci od trivialni zateze velice pomaha produktivite.

A casto LLM necham zkontrolovat muj kod a casto prijde s opravdu peknym napadem na vylepseni, najde ci jsem prehlidl, upozorni na side effect.

Programovani se holt meni, stejne jako kdyz prisel C kompiler a libc. Nyni je dulezitejsi analyza, vlastni kodovani vicemene prevezmou stroje.

2

Desktop / Re:Jak používáte více displejů?

« kdy: 27. 10. 2025, 09:32:02 »

Mam 17" notas FHD a po stranach 2x27" 4k.
Obvykle vpravo VSCode, uprostred chrome napr. kdyz zrovna delam ve VUE tak tam hned vysledky zmen, nalevo dokumentace/zadani, Teams, Outlook, co je potreba.
Sedim na otocny zidli a tocim se cely, ne jenom vytoceny krk.

3

Bazar / Re:Koupím hardware vhodný na domácí server

« kdy: 22. 10. 2025, 18:35:13 »

BTW: Produkcni stroje, bez disku, s 512GB ramkou a 2x CPU ... s 2x 1k zdrojema ve skutecnosti v prumeru papkaji neco kolem 300W.  Takze spotreby bych se nijak moc nebal.

300W avg, pri 10kc/kwh (bezna sazba domacnosti D02d, u vysokoodberovych sazeb je NT platba nizsi) to dela ucet 2160Kc mesicne.
Asi nic, z ceho bych se polozil, ale znam lepsi veci, kam strcit 2 klacky mesicne.

4

Bazar / Re:Koupím hardware vhodný na domácí server

« kdy: 22. 10. 2025, 16:37:33 »

co sa tyka hluku a spotreby to je mi asi jedno pretoze by to bolo v suterene...

To me zaujalo, 1kW spotreba, pri cene elektriny 10kc/kWh D02d, to mame 240Kc, denne, 7200Kc mesicne, 87600Kc rocne.

Ono i pri tretinove spotrebe mi prijde platit 30k rocne za nejakou hracku ve sklepe krapet neekonomicke.

Osobne taky pro vyvoj potrebuju hromadu VM a kontejneru, bezi mi v Hyper-V/podmandesktop/WSL primo na desktopovem pocitaci a kdyz na tom nedelam, cely candrbal vypnu.

Home assistant utahne rapsberry.

5

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?

6

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

7

Vývoj / Re:Přechod z Javy na Rust. Ano či ne?

« kdy: 29. 09. 2025, 11:45:42 »

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

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.

8

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.

9

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

 

10

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.

11

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

12

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

13

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.

14

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.

15

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