Příspěvky

1

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

« kdy: 11. 02. 2026, 01:54:38 »

Boss nakonec rekl, ale tak jedina halucinace byly ty neexistujici funkce?

Bylo to celé super, akorát to nefungovalo no.

2

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

« kdy: 31. 01. 2026, 23:38:09 »

Google uvedl projekt Genie (vytvori z promptu interaktivni 3d scenu https://deepmind.google/models/genie/ ) . V reakci na to akcie hernich studii behem jednoho dne citelne oslabily - Unity o 20 %, CDProject red o 8 %, TakeTwo o 16 % atd. Prehnana reakce? V kratkem horizontu urcite ano. V dlouhem... kdo vi ;-)

Tak kup akcie v očekávání že se to srovná, ne?

3

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.

4

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

5

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

6

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

7

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.

8

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.

9

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?

10

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

11

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.

12

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

13

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.

14

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.

15

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