Příspěvky

1

Hardware / Re:Zkušenosti s monitory Dell U3325QE alebo BenQ RD320U

« kdy: 13. 10. 2025, 15:22:15 »

Mám Dell U2723QE (úplně se v těch označeních nevyznám, ale nejspíš je to 27" analogie toho tvého) v práci i doma a zatím s ním nebyly žádný problémy.
Na druhou stranu nejsem zrovna náročný na kvalitu obrazu - co se mi hodí a doma využívám je zabudovaná "rozbočka" na USB - když jde obraz z notebooku, posílá signál z klávesnice a myši (které jsou zapojené do monitoru) do notebooku, když jde obraz ze stolního PC, tak posílá signál tam. Power Delivery se taky hodí - mám pak notebook připojený jen jedním USB-C kabelem, kudy jde napájení, obraz, klávesnice i myš.

2

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

« kdy: 10. 10. 2025, 06:16:33 »

1) Samo že jo. Aniž bych znal Rust, tak stačilo cca 10s googlení abych našel transmute_copy.

Což je zrovna unsafe věc. Bez unsafe se to dá udělat pomocí f32.to_le_bytes a u32.from_le_bytes (otázka je, jak dobře to zvládne zoptimalizovat)

3

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

« kdy: 08. 10. 2025, 08:08:30 »

Dokázal byste si představit, že by se v něm dal naprogramovat engine 2,5D počítačové hry třídy AAA?

Pokud pomineme to, že 2,5D AAA hra je nejspíš blbost, tak na programování AAA her se Rust oproti C++ zrovna až tolik nehodí.
U high-end her je potřeba vyždímat každý kousek výkonu PC, zato vlastně moc nevadí, když dojde k memory problému - hra prostě spadne, hráč si trochu zanadává, pustí ji znova a jede se dál...

Takže ano, dokázal bych si představit, že by se v něm dal naprogramovat engine (dokonce bych si dokázal i představit, že to někdo udělá), ale oproti enginu v C++ nebude mít v podstatě žádnou výhodu.

4

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

« kdy: 26. 09. 2025, 08:51:39 »

Napsat si něco sám má své výhody i nevýhody. Výhodou je, že nad tím mám plnou kontrolu - dodržuji zpětnou kompatibilitu, když to potřebuji, nedávám tam funkcionalitu, co nepotřebuji. Nevýhodou je, že stojí čas si to napsat. Občas to je však méně času, než se naučit používat cizí knihovnu, nebo tu cizí knihovnu ohnout, aby fungovala, jak potřebuji.

Ještě jsi zapomněl na jednu další nevýhodu - zavedeš si tam bugy. Žádný kód nejde napsat bez bugů, a na rozdíl od cizí knihovny ti je nikdo neopraví. Všechny je musíš najít a opravit sám (ano, pokud by ta cizí knihovna byla nekvalitní, tak v ní nejspíš bude víc bugů než ve tvojí implementaci, ale u kvalitní, zavedené a "battle-tested" knihovny to až tolik nehrozí).

5

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

« kdy: 23. 09. 2025, 12:31:11 »

Rád bych se zeptal, co Vás nejvíce zdržuje při porovnání programování v Java/C#/PHP oproti Rustu? Je to čtení kódu, odlišná syntaxe Rustu, odlišnost přístupu k přísným datovým typům (im/mutability) Rustu, neexistující knihovny, automatické doplňování kódu v IDE (jaké nástroje používáte? VS Code nebo JetBrains RustRover etc.) nebo ještě něco jiného? Rád bych totiž našel řešení, jak zrychlit vývoj v Rustu oproti Java/C#/PHP a hlavně oproti C++ tak, aby to bylo obráceně: přinejmenším Java/C#/PHP = 2 jednotky času oproti Rust = 1 jednotka času. Ale rád bych dosáhl poměr 1:10 ve prospěch Rustu. Bylo by to reálné? Třeba i s popmocí A.I.?

Předem díky za odpověď,
nm

A proč by to mělo jít? Proč by ty vylepšení měly jít použít jenom v Rustu a ne i v těch ostatních jazycích?
V Rustu za absenci GC platíš složitější architekturou kódu.
Pokud by šlo v Rustu psát všechno rychlejí než v Javě/C# a zároveň by to pak běželo rychleji a žralo míň paměti, nebyl by (skoro) žádný důvod je použít.

6

Vývoj / Re:Přechod z JAVA na RUST (ANO či NE)

« kdy: 20. 09. 2025, 19:21:57 »

Inak ja som JS dev

...

v tomto prípade Java a PHP sú celkom špatné jazyky, kvôli obskurdnej syntaxi v prípade Javy a nekonzistentnému API v prípade PHP

...

vyhoď Javu a PHP

To je teda objektivní příspěvek :-) Chápu, že máš rád JS a nemáš rád Javu a PHP, ale objektivně jsou všechny tři na stejné úrovni. Třeba já osobně bych mnohem radši dělal v Javě nebo PHP než se patlal s JS/TS peklem.

7

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

« kdy: 19. 09. 2025, 19:54:29 »

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

Ale z tvýho doplňujícího příspěvku to vypadá jako že se programováním neživíš. A že v Javě vlastně neděláš. Takže moc nevím, jak myslíš to "přejít".

Na hraní je Rust určitě zajímavej, minimálně tě naučí uvažovat v kontextu, kdo co vlastní, což se může pak hodit i v jiných jazycích.

8

Bazar / Re:Sháním starší notebook pro kamaráda na web

« kdy: 12. 09. 2025, 10:29:34 »

Ubuntu (což mi připadá jako nejjednoduší systém, kamarád se v PC nevyzná skoro vůbec)

Jo, nám na rootu to tak připadat může, ale z vlastní zkušenosti BFU tyhle alternativní systémy moc neocení. Být tebou bych přece jen zvážil Windows.

9

Studium a uplatnění / Re:Jak na angličtinu?

« kdy: 30. 08. 2025, 17:49:36 »

Ešte jedna otázka. Poraďte nejaké rádio, kde by som mohol počúvať angličtinu?

Myslím, že dneska většina lidí poslouchá spíš podcasty (já teda ne, jsem čtecí a ne poslouchací typ). Třeba bys našel nějaký v oboru, co tě zajímá...

10

Vývoj / Re:Framework vs. čistý kód

« kdy: 17. 08. 2025, 12:08:33 »

Opravdový programátor se taky zabývá zajímavými a zábavnými věcmi. A to reimplementace spousty věcí, které již mají kvalitní implementaci, fakt není.

Bohužel pro spoustu lidí jo, a proto taky je NIH tak rozšířená věc (sám k tomu mám sklony a často se musím krotit, abych použil knihovnu, která třeba nedělá 100% to, co bych chtěl, a nezačal si to psát sám)

11

Vývoj / Re:Framework vs. čistý kód

« kdy: 29. 07. 2025, 19:07:55 »

100% fungují jen PHP, prvotní varianta JSP bez EL, nové JTE

JTE je jen další template engine, který má taky "vymyšlené svoje tagy". Jen mu prostě udělali dobrý plugin do Intellij. Není to, že to "samo funguje", protože to vypadá jako Java. Zdrojáky IDE pluginu mají 7247 řádků ve 136 souborech.

Navíc tyhle "template je kód" svádí k prasení, kdy po chvíli lidi začnou dělat DB dotazy v šabloně, protože to jde. Někomu to vyhovuje (než se v tom zamotá tak, že musí celý projekt zahodit/přepsat), jiní mají radši striktnější oddělení...

12

Vývoj / Re:Vyplatí se koupit Tailwind?

« kdy: 04. 07. 2025, 08:19:22 »

Chvíli mi trvalo, než jsem pochopil, na co se vlastně ptáš. Tailwind je CSS framework a je zadarmo, takže "koupit Tailwind" je samo o sobě blbost. A na té stránce, kterou jsi nalinkoval, taky o kupování ničeho není ani slovo. Ale nakonec jsem pochopil, že asi myslíš "koupit Tailwind template s názvem Spotlight za $99".

Ano, pokud ho chceš použít, tak bys ho měl koupit. Někdo si dal práci s tím, aby ho vytvořil, a teď ho prodává. Nejspíš to chceš použít v projektu, za který si účtuješ peníze, takže je to prostě jenom náklad, který ušetří tvůj čas za nějakou cenu. Ono jak dlouho by ti trvalo vytahat všechny styly tím inspectem? Nebude ten čas stát víc než $99?

13

Vývoj / Re:If bez curly brackets?

« kdy: 21. 06. 2025, 11:52:33 »

Pripravte sa na budúcnosť!  https://github.com/stereobooster/wisp

Last commit: 5 years ago :-)
Ale souhlas, rozhodně se mi to čte líp (a dokonce jsem to i znal z dřívějška). Ale i tak je to furt Lisp a čte si mi to ve srovnání s "normálním" jazykem blbě...

14

Vývoj / Re:K čemu je v PHP dobré použít framework?

« kdy: 20. 06. 2025, 11:59:25 »

Je jen pár základních konstrukcí, co má umět template:

1. If else
2. Foreach
3. A jak se pracuje s fragmenty (reusable components)

Jsou to jen tyhle výše uvedené 3 základy, a pro tu poslední nemá PHP řešení.

Ještě se taky hodí, když má escaping by default. Což PHP taky nemá.

15

Vývoj / Re:Je jazyk C skutočne ťažký?

« kdy: 11. 06. 2025, 20:14:45 »

Dále nechápu to s tím assemblerem. C přesně odpovídá tomu jak jsou věci v assembleru. Je to de-facto portabilní assembler. A právě ten kdo prozkoumá věci v C až na úroveň asembleru, tak ten má pak v těch věcech jasno a žádná mentální zátěž to pro něj už není. Mentální zátěž je, když v tom jasno právě nemá a musí to pořád vyhodnocovat.

No právě že assembleru neodpovídá (viz shiftování signed intu). Tím, že se snaží být ne jeden assembler, ale všechny assemblery najednou (s tím, že každý se vlastně chová trochu jinak), tak se z něj stává guláš, kde spousta věcí musí fungovat polovičatě, jako v každé abstrakci.

Takže pokud prozkoumáš C až na úroveň assembleru, tak podle standardu C ti to je k ničemu, protože stejný kód se ti na procesoru xyz bude chovat úplně jinak.