Příspěvky

1

Vývoj / Re:FP a error handling

« kdy: 04. 12. 2025, 18:50:04 »

algebraické efekty

Algebraické efekty jsou super věc. Další z těch, které teprve čekají na objevení v mainstreimových jazycích. A taky GADTs, toho se taky jen tak nedočkáme.

2

Vývoj / Re:FP a error handling

« kdy: 03. 12. 2025, 03:30:56 »

Nemůže to být tím, že hodně FP jazyků směřuje ke statickému typování a tam jsou výjimky tak nějak komplikací - jiný kanál?

Co se týče syntaxe, tak třeba Rust se svýma "?" je docela zkousnutelný.

Kód: [Vybrat]

(a div (b - c))? + 4

3

Vývoj / Re:JavaScript vs. TypeScript: rovnaký alebo rozdielny jazyk?

« kdy: 14. 11. 2025, 17:36:48 »

To je skvělá logika: používejme antipatterny a známé zákeřnosti. Stačí přece, že testy, co si napíšem opatrně tak, aby se to nerozbilo, projdou.

Testy se píší tak, aby se to rozbilo. Nejspíš žiješ v jiném světě.

Problém je, že bez ohledu na to, jak moc si s tím dáš práci s testama, první týden na produkci se najde nějaký ..., co zkusí něco, co tě vůbec nenapadlo v testech pokrýt. Spoléhat se na to, že kód může být hromada hnoje, a testy to ohlídají... eh, s tím bych fakt pracovat nechtěl.

+1

4

Vývoj / Re:Zobrazenie obrázkov z DB na webe bez koncovky

« kdy: 08. 11. 2025, 19:57:16 »

Preco si do db neukladat proste zakladne info o obrazku a samotne obrazky ukladat na disk, napr. pod nejakym hash nazvom. Skript si proste urobi jednoduchy select podla toho hash, z db vytiahne potrebne info a posle to klientovi aj so spravnymi hlavickami. Funguje to tak roky.

Drahý.

5

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

« kdy: 08. 11. 2025, 16:56:08 »

protože extendujete nějakou parent entitu,
...
Drupal patří ke špičce toho, co jde vymyslet. A to právě i kvůli tomu Symfony.

Nešťastné spojení.

Za mě:
Symfony je to lepší z php frameworků.
Drupal díky Symfony rozhodně získal.
Ale že by to byla špička, natož špička toho co jde vymyslet, to je dost odvážné.

Je nutné si uvědomit, že Drupal je starý kód a vždy hladový po financích. Takže nikdy to nebude dobrý kód. Tak nějak z principu.

6

Vývoj / Re:Zobrazenie obrázkov z DB na webe bez koncovky

« kdy: 08. 11. 2025, 16:22:10 »

Teda rôzne typy obrázkov by som ukladal do rôznych podadresárov a tým nastavil príslušný ForceType.

Na první pohled to vypadá jako super nápad. Ale když se nad tím zamyslím, jak budete z "/imgs/5b17f8185e71449983e3600a0c2d8527" rozlišovat do jakého podadresáře se má dotazovat?

Boli by tam adresáre ako images/jpeg, images/png atď. Logika kontrolera je potom asi takáto...

• Príde dopyt na ImageCacheService, napr. na https://.../cache-service/123
• ImageCacheService urobí rýchly select do DB, aby zistil správy mime-type, timestamp a vyskladal cestu ako https://.../public/images/jpeg/123. Selectu sa teda nevyhneme, ale je podstatne rýchlejší ako ťahať z databázy celé raw dáta.
• Ak je to potrebné, príslušný obrázok na disku v adresáry /var/www/public/images/jpeg/123 sa vytvorí, prípade updatne.
• Kontroler odpovie pomocou 302 Moved Temporarily https://.../public/images/jpeg/123
• Browser načíta daný obrázok, ktorý Apache odošle so správnym mime type.

Tento prístup s 302 sa môže zdať ako okľuka, ale umožňuje práve updatovanie zmenených obrázkov, kontrolu prístupových práv a tak podobne. V prípade potreby by sa to dalo vyriešiť aj bez neho, keď by sa obrázky updatovali napr. vždy v noci.

Rozumím. V tom případě to je spíše horší než lepší nápad. Protože se bavíme o cache, a o tom jak to udělat co nejlevněji. A toto, pokud mě něco podstatného neuniklo, je stále dražší než se prostě jen ptát na existenci souboru a maximálně si vytáhnout info o mime ze sousedního souboru nebo z xattr.

V každém případě dík za info. Ve skutečnosti jsem ForceType neznal.

7

Vývoj / Re:Zobrazenie obrázkov z DB na webe bez koncovky

« kdy: 07. 11. 2025, 21:24:26 »

Teda rôzne typy obrázkov by som ukladal do rôznych podadresárov a tým nastavil príslušný ForceType.

Na první pohled to vypadá jako super nápad. Ale když se nad tím zamyslím, jak budete z "/imgs/5b17f8185e71449983e3600a0c2d8527" rozlišovat do jakého podadresáře se má dotazovat?

8

Vývoj / Re:zobrazenie obrázkov z DB na webe bez koncovky.

« kdy: 07. 11. 2025, 02:13:23 »

1/ Ukládat si do filecache včetně koncovky. Pomocí htaccess následně řešíš jen existenci

2/ Ukládat si do filecache bez koncovky, ale s fixním typem. IMHO poněkud vachrlaté. A u toho originálu se ti to asi nebude chtít.

3/ Ukládat si do filecache bez koncovky, a hned vedle ukládat soubor s mime. Něco jako "5b17f8185e71449983e3600a0c2d8527" = obsah. "5b17f8185e71449983e3600a0c2d8527.mime" a v něm obsah "image/png". Pokud se dotazuješ na soubor bez koncovky tak stejně budeš muset posílat nějak hlavičku, takže nějaká mikro-proxy tam bude potřeba. Pomocí čistě htaccess by to asi nešlo. Možná nějaké pravidlo na serveru, záleží.

9

Vývoj / Re:Prečo nie je Lisp populárnejší?

« kdy: 06. 11. 2025, 19:09:50 »

Volání funkcí je v prefixové notaci. V matematice používáme i postfixovou notaci a nepřipadá nám to divné. Lisp udělal jen to, že vše sjednotil do prefixové notace, aby to bylo jednodušší.

Mno, a teď teda řekněte, proč v jazycích, které to umožňují, je taková scháňka po přeťěžování infixových oprátorů, pokud je prefix tak výhodnější.
Troufám si tvrdit, že většina programátorů radši napíše s1 + s2 + s3 nez CONCAT(s1, s2, s3), stejně tak Octonion a = b + c a ne Octonion a = ADD(b, c)

A nemůže to být prostě jen tím, že zvyk?

A opravdu je po tom taková scháňka?

Třeba v Haskellu je možné definovat naprosto zběsilé operátory, jako >>=, <$>, *>, >@>, které jsou automatikcy infixové. A autoři knihoven to všelijak používají, s větším či menším úspěchem stran čitelnosti. Ale neřekl bych, že by po tom byla jakože vysloveně poptávka. Spíše, když maj tu možnost, tak to použijou, protože se jim to víc líbí. A nebo třeba taky ne.

10

Vývoj / Re:Prečo nie je Lisp populárnejší?

« kdy: 06. 11. 2025, 17:53:04 »

Ehm, já vím, že to tady bude znít trochu jako rouhání, ale mít sny ve strojovém kódu NENÍ normální.

Počítám v hlavě tak, že seskupuji objekty: trojůhelníky, čtverce, krychle, kvádry. Třeba desítka jsou dvě krychle a kvádr. Nevím, jestli je to normální, asi možná spíše ne :-)

11

Vývoj / Re:Prečo nie je Lisp populárnejší?

« kdy: 06. 11. 2025, 17:50:10 »

Clovek nema vubec mentalni kapacitu cist prefixove vyrazy. Uz jen takovyhle jednoduchy vyraz da praci. To, ze je to vyhodne pro pocitace je jina vec (lispovsky S-vyrazy).

Priklad:
 ^ * + 5 2 - 6 3 2

coz je

((5+2)*(6-3))^2

Dobrý postřeh. Samozřejmě jsem to hned zkusil. Překvapivě se mi to čte dobře, ani ty závorky nepotřebuju. Nejvíc mě trklo, že to vlastně krásně řeší váhání nad prioritami. A vzhledem k tomu, že se nepovažuji za úplně nejvíc geniálního, tak nevím, co si o tom teď mám myslet.

To vám fakt nevěřím.

Beru na vědomí.

A teď si vemte, že jsem se v té rovnici spletl. Protože jsem četl:
 ^ * + 5 2 - 6 3 2
jako (5 + 2) * (6 - (3 - 2)) ^ 2
A když jsem si tu chybu uvědomil, tak jsem zaujal postoj, že autor té prefixové rovnice to napsal blbě, protože samozřejmě očekávám, že operátor sežere všechny argumenty až po první operátor. Přišlo mi to jasné a pohodlné.

Co z toho vyvodíme?

Pro mě by bylo zajímavé sledovat zastánce praktického používání prefixové notace, jak to prakticky používá, tj. jak v tom počítá, upravuje výrazy, řeší rovnice...

To asi nejsem.

Třeba jsem ale pozoroval, že funkce jako konstrukt mám hodně pod kůží. Když jsem mé paní vysvětloval něco a používal formulace jako "no to máš jako funkci, že...", tak jsem se zarazil, že na mě blbě kouká. A na druhou stranu, řešit (složitější) matematické rovnice není věc, kterou bych dělal každý den. Možná ani jednou za rok ne.

Principielně proti infixové notaci nic nemám.

12

Vývoj / Re:Prečo nie je Lisp populárnejší?

« kdy: 06. 11. 2025, 16:30:06 »

Clovek nema vubec mentalni kapacitu cist prefixove vyrazy. Uz jen takovyhle jednoduchy vyraz da praci. To, ze je to vyhodne pro pocitace je jina vec (lispovsky S-vyrazy).

Priklad:
 ^ * + 5 2 - 6 3 2

coz je

((5+2)*(6-3))^2

Dobrý postřeh. Samozřejmě jsem to hned zkusil. Překvapivě se mi to čte dobře, ani ty závorky nepotřebuju. Nejvíc mě trklo, že to vlastně krásně řeší váhání nad prioritami. A vzhledem k tomu, že se nepovažuji za úplně nejvíc geniálního, tak nevím, co si o tom teď mám myslet.

13

Studium a uplatnění / Re:Je programátorů moc, nebo málo?

« kdy: 30. 10. 2025, 23:11:50 »

Vzpomínám si, jak jsme kdysi v jedné firmě, plné výborných vývojářů, zkoušeli zavádět unittesty. Já jsem z nich o tom překvapivě věděl nejvíc, tak jsem dostal za úkol udělat nějaké seznámení. Používání testů je užitečný, dnes už to moc lidí nekritizuje. A má svá úskalí. Své nadšence a odpůrce. V případě LLM to vidím jako podobný pattern.

Já LLM dost masivně používám. Ale přesto v porovnání s popisy některých místních, jsem evidentně ještě dost konzerva.

Mám kamaráda, který o tom hrozně básní. Asi si k němu sednu a budu pozorovat, jak to používá.

14

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

« kdy: 08. 10. 2025, 03:32:32 »

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

https://fyrox.rs/
https://bevy.org

15

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

« kdy: 02. 10. 2025, 23:34:03 »

Nedávno jsem tady do nějaké diskuse napsal, že generování XML je někdy lepší si napsat sám, ručně, bez knihoven a hned se seběhli místní trollové, co že si to dovoluji si takovou věc psát sám… Přitom to generování XML je výrazně jednodušší než parsování (byť si nepíšeš vlastní parser asi zpracováváš SAX události nebo pracuješ nad DOMem nebo něco podobného). (jen dodávám, že cílem toho mého generátoru nebylo generování libovolného XML, ale určité podmnožiny, která je pro moje potřeby dostačující – důležité je, aby výstup bylo validní XML)

Ty výhrady k tomu generovanému kódu částečně chápu. Sám jsem s tím bojoval u Swaggeru resp. OpenAPI, kde generátor nebyl dost zralý, některé věci to nepodporovalo vůbec nebo to generovalo nesmysly… to bylo dost peklo. Něco vyřešili autoři generátoru v novějších verzích, něco jsme vyřešili sami vlastními šablonami. Ale i tak si myslím, že je většinou lepší si jednou odladit šablony/generátor než to psát pokaždé ručně. A JAXB je oproti tomu mnohem zralejší a spolehlivější technologie (byť to zemětřesení, které přišlo po Javě 8, s tím nepěkně zamávalo).

Nevím, proč by zrovna generování xmlka nemělo jít lepením stringů. Do určtié velikosti projektu je to naprosto good enough.

Jedna ze zkušeností, co mne v tomhle ovlivnila, byla, když  jsem  kdysi  pozoroval  lidi, kteří seděli asi dva metry od sebe, jeden psal server v Javě, druhý psal klienta v JavaScriptu a neustále řešili, že ten druhý posílá  atribut  s „jiným  názvem“ nebo  „starým  způsobem“…  v každé  verzi  byly  chyby tohoto typu a pořád se na to plýtval čas a vyvolávalo to hádky. Mezi sebou si sdíleli dokument ve  Wordu,  ve kterém  měli příklady, jak se má služba volat… Takže když mi dneska někdo tvrdí, jak nepotřebuje schéma, a že je to prý jednoduché a že stačí napsat pár příkladů a všem to bude jasné… tak se mi otevírá pomyslná kudla v kapse, protože vím, jak to dopadá. Přitom tohle se v oboru řeší od pradávna a obecně  se  to  jmenuje IDL  (interface  description language). Konkrétních implementací je spousta, ale podstatná je ta myšlenka, že máš nějakou strojově  čitelnou  specifikaci,  která definuje ten kontrakt, a ze které obě strany vycházejí.

Ale každopádně, pokud si píšeš parser ručně ale máš tu specifikaci a ne jen pár příkladů, tak je to ještě ten lepší případ.

To jsme takhle s kamarádem dělali jeden projekt. Měl jsem nápad, a on si z toho udělal bakalářku. To jsem si zavařil. Rozvíjel jsem ten nápad, a on mě furt otravoval, jestlu už to bude hotové, a já mu furt měl tendenci měnit specifikaci, protože to jinak nešlo.