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.


Příspěvky - Ondrej Nemecek

Stran: [1] 2 3 ... 93
1
Vývoj / Re:No code mobilní apka
« kdy: 25. 08. 2025, 12:57:54 »
A proč to radši nechceš  to programovat vibe code způsobem ?  Nebo v čem je lepší toto ve srovnání s omšelým no code nebo archaickým PWA?
Podle zadání to vypadá, že stačí statický HTML soubor. Nebo se mýlím, a ta aplikace bude mít nějakou logiku (no pun intended).?

Vždyť píše, že to má mít

Citace
ale i nějaký malý chat, čili interaktivní věci, formuláře

čili je potřeba minimálně i nějaké server-side api.

2
Software / Re:Lokální LLM AI moduly
« kdy: 23. 08. 2025, 00:44:11 »
má otázka je zda jde dělat něco jako inkrementální trénování AI, že vemu hotový LLAMA ale něco bych si dotrénoval ze svých dat nebo jako hotový a nový vzniklý model propojit, jestli se to takhle dá nazvat)

Asi se ptáš na RAG https://cs.wikipedia.org/wiki/Retrieval-augmented_generation

3
Software / Re:Funkční webová galerie
« kdy: 03. 08. 2025, 12:13:45 »
Koukni, zda by nevyhovoval https://picapport.de/en/

Obávám se, že většina používá Google Photos, neboť nevědí, co činí. Motivace k tvorbě galerií je tím oslabena a když k tomu připočtu, že zdaleka ne každý opensource je kvalitní, může být skutečně problém si něco rozumného vybrat.

4
Server / Re:Načtení HTML z hostingu za méně než 80 ms
« kdy: 12. 07. 2025, 11:59:45 »
Jste autorem té aplikace? Je potřeba tu aplikaci profilovat - buď na srovnatelném hardware a se srovnatelným objemem dat, anebo přímo na hostingu, pokud to je technicky a provozně možné. V aplikaci je nutno vyřešit, aby to bylo dost rychlé. Pokud chcete mít data na klientovi do 80ms a 50ms bude trvat přenos dat, tak ať aplikace html vygeneruje do 30ms. Profiller zobrazí, kde aplikace tráví nejvíc času, podle toho příslušnou část aplikace upravíte (upravíte dotazy do databáze, databázové indexy, vylepšíte zpracování dat, některá data si připravíte předem, použijete vhodnější datové struktury apod.). Pokud budete data přenášet komprimovaně, ušetříte na přenosu dat, takže se přenesou třeba za 15ms a zbyde vám větší rezerva pro aplikaci. Toto byste měl udělat vždy, nestojí to skoro nic, stačí přidat kompresi do konfigurace nginx. Klient ovšem musí mít pro kompresi podporu a vyžádat si data komprimovaná, což je ale dnes většinou standard (prohlížeče to mají defaultně zapnuté, u REST klientů to lze zapnout).

Pak můžete ladit dál - když na generovaný obsah, který se moc nemění, zapnete cachování na straně serveru, tak aplikace nebude muset data  vůbec generovat a po dobu životnosti cache se pak bude uplatňovat pouze čas nutný pro přenos - takže v příkladu výše dostanete data  za 15ms. Je potřeba se zabývat tím, která data cachovat a jak dlouho. Cachovat může nginx anebo přímo aplikace.

Zejména u webových aplikací můžete dále zlepšit odezvu tím, že budete klientovi posílat správné cache hlavičky, pak může cachovat i klient přímo u sebe, typicky se vyplatí u webových aplikací cachovat css, js a grafické assety (ikony, písma, pozadí, ...). Klient pak vyrenderuje celou stránku rychleji a zlepší se uživatelský dojem.

Akorát je potřeba myslet na to, že přestože má klient data v cache, může posílat aplikaci dotaz na příslušné resource a zpracovávat http hlavičky, kde bude uvedené, zda se resource od minula změnil nebo nezměnil. Tento round-trip musí být pro stav "nezměněno" co nejrychlejší, protože pokud bude klient čekat na odpověd stejně dlouho, jako na plná data, tak se ušetří pouze čas nutný na přenos dat, avšak čekání zůstane.

Pokud nejste autorem aplikace
a nemáte možnost spolupracovat s autorem, můžete hledat, zda není úzké hrdlo na hostingu. Bohužel parametry hostingu se v čase mění, nejlepší postup je vyzkoušet několik hostingů a provést standardizované měření a podle toho se rozhodnout. Nezřídka se mi stalo, že hosting šel kvalitativně dolů a bylo potřeba upradovat balíček nebo přejít jinam. Záruky vyhrazeného výkonu dostanete totiž jen na dedikovaném hostingu nebo přímo na dedikovaném hardware, cena je ale logicky vyšší.

5
Vývoj / Re:Implementace vlastního WYSIWYG editoru
« kdy: 12. 07. 2025, 01:22:16 »
Tak to jsem zvedav, zda dokazes ukocirovat treba situaci, kdy uzivatel vybere pulku nadpisu a pulku odstavce (uprostred slov, ne vedle mezery), a klikne na bold. Takova vec se v MD mozna ani neda reprezentovat..

Povolené budou jen stavy, které dávají smysl. Dávno takový typ editorů schází, bohužel to asi průměrný uživatel neocení a proto vládnou nedodělky a průměrnost...

6
Vývoj / Re:Vyplatí se koupit Tailwind?
« kdy: 07. 07. 2025, 11:35:02 »
Jako např. který? Přecejenom bych řekl, že dneska je Tailwind nej. Potom už znám jenom aterial design jako Vuex a další. A nebo jednoduché, jako je classless.de.
Máte v tom pěkný zmatek. To, co vidíte odkazované v projektech a v článcích, co se hodně používá, je Tailwind CSS. To je CSS framework založený na utilitních třídách. A používá se proto, protože zjednodušuje tvorbu CSS i pro lidi, kteří CSS neznají, a má skvělou dokumentaci. Tailwind CSS je ale jen jiný způsob, jak zapisovat CSS – není tam ani čárka nějaké šablony nebo komponent.

Pak existuje Tailwind Plus, cože je sbírka komponent a šablon vytvořených pomocí Tailwind CSS. Knihoven komponent a šablon založených na Tailwind CSS jsou mraky. Tailwind Plus je specifický jenom tím, že jsou přímo od autorů Tailwind CSS. Ty knihovny komponent a šablon založených na Tailwind CSS mohou mít různou podobu – mohou to být knihovny už hotových komponent třeba v Reactu nebo WebComponents, které jen nakopírujete do projektu. Pak je to podobné jako různé implementace Material designu, Bootstrap, PrimeVue/React/NG. Nebo to může být zdrojový kód třeba Reactových komponent, které si nakopírujete do svého projektu – třeba Shadcn/UI. A nebo – a tak je udělaný Tailwind Plus – je to dokumentace a příklady kódu v HTML a Tailwindu, případně složitější komponenty obohacené o napojení na React. Takže je to spíš taková stavebnice, ze které si vytvoříte vlastní knihovnu komponent. A šablony v Tailwind Plus jsou pak vzorové projekty vytvořené v konkrétních technologiích, často v Next.js, spolu třeba s Headless UI.

1+ hezky popsáno, snad to tazateli pomůže se zorientovat

8
Vývoj / Re:Vyplatí se koupit Tailwind?
« kdy: 06. 07. 2025, 22:44:08 »
Jestli se Tailwind vyplatí kupovat Vám konkrétně, to vám asi nikdo nepoví. Ale je spousta css frameworků, které to, co vidím v té šabloně, zvládnou levou zadní a nebudete muset platit nic.

9
Vývoj / Re:Moderný frontend - ako na to?
« kdy: 06. 07. 2025, 22:30:15 »
A teď dělám na svojem projektu, který by někdy, snad, mohl něco vydělávat, a protože se bojím, že by moje práce přišla v niveč, tak používám nejmodernější Next.js a k tomu Tailwind.

Načež prio. no 1 je Tailwind, ikdyž bych toho samého docílil s CSS - a proč. Protože nemůžu umět všechno, a v CSS mi přijde, že nacházím dost nekvalitní šablony. Přitom cokoliv jde v Tailwind, jde i v CSS.

Takže kdybyste někdo věděli, kolik tak stojí grafik a výstupy od grafika, tak bych klidně dal 10k za grafika, ať mi udělá pořádný design - a nemusím platit amerikánům 7500,- Kč za Tailwind. Ale bohužel grafika žádného neznám a nevím, kolik stojí a jak vypadají jejich výstupy - mám podezření, že by mě grafik přišel o dost dráž.

Jinak celkem "žeru" na forum.root.cz ten Heading - udivuje mě, jak jeden černý obdelníček a k tomu pěkně zvolený font a další věci, dokáže vypadat dobře. To je přesně to, co umí udělat grafik...

Přesně od toho CSS frameworky jsou, aby zajistili s minimum práce a trochou poučenosti kvalitní výstup. Já bych grafika najímal leda na tvorbu vizuální identity - logo, font, barvy, ukázkové aplikace. Jinak bych najmul spíš CSS kodéra, který použije můj oblíbený CSS framework a pomůže mi v něm pracovat efektivně a který mě poučí o základních pravidlech UX/UI. Když bude kvalitní, tak se i dokáže přizpůsobit odvětví, pro které je aplikace určená - a nebude mi nutit něco, co nechci. Pak už bych si jako backend vývojář dokázat UI komponenty dělat sám, protože by mě od většiny nepříjemných implementačních detailů CSS framework odstínil. S tímto přístupem začal Bootstrap, ale dnes už budou asi i lepší alternativy. Zda se to bude renderovat na klientovi nebo na serveru je vedlejší, tam bych se rozhodoval podle požadavků na interaktivitu.

10
Bohužel mi celý Android přijde zmatený, třeba odebírání oprávnění - WTF? Nastavím aplikaci oprávnění a on mi je zase náhodně odebere. Třeba appka MujRozhlas mi funguje správně jen určitou dobu po nainstalování, pak se začne ukončovat a to i když ji mám na popředí. Důvod neznám, ale možná přišla o nějaká oprávnění, která neumím přidat. Pomůže reinstalace. Mimořádně otravné.
MujRozhlas mám a nic takového se mi už neděje, ale dělo než jsem si vše nastavil, a to mám Xiaomi, které je ukončováním a mazaním známé. Jednak žádná extra oprávnění nepoužívá, dále u všech aplikací, které se nějak někam přihlašují či mají uložena jiná důležitá data, mám vypnuto v Podrobnostech o aplikaci Pozastavit aktivitu aplikace, když se nepoužívá,  pokud má aplikace běžet bez problémů na pozadí, tak u Baterie nastavit Žádné omezení.
Automatické odebírání oprávnění je bezpečnostní opatření pro telefony v rukou běžných BFU (99,99%), kteří si do telefonu instalují kde co a pak na to zapomenou. Znalý člověk si to může u konkrétních aplikací vypnout.

Tak jsem zkusil nastavit u MujRozhlas tohle:

- vypnout: Pozastavit aktivitu aplikace, když se nepoužívá
- nastavit: Baterie  Žádné omezení

A uvidím. Pokud to vyřeší problém tak to bude skvělé  ;D

11
Vývoj / Re:Moderný frontend - ako na to?
« kdy: 06. 07. 2025, 13:01:11 »
Spousta lidí má svůj js framework jako náboženství (...)  S čistým HTML / CSS, někdy s pomocí HTMX udělám často "lepší" (rychlejší, spolehlivější, v prohlížeči plně funkční) aplikaci a to rychleji (...) Vue taky používám celkem často - je to pro mě jednoduchá cesta jak si v electronu, apod. splácat aplikaci do androidu. Že by to dávalo smysl na běžném webu, na to jsem zatím nenarazil.

Proto jsem pomyslně rozdělil weby na dokumentové weby (= např. zpravodajský portál) a aplikační weby (= github).

12
Vývoj / Re:Moderný frontend - ako na to?
« kdy: 06. 07. 2025, 12:56:58 »
Přesně tak, geneze současného stavu vznikla tristním zneužitím html zobrazovadla k něčemu, k čemu rozhodně nebyl určen. Problémy jsou s tím dodnes. Ale na druhou stranu to doiterovalo do stavu, který je na všech GUI platformách skoro stejný a vypadá takto:

- nějaký značkovací jazyk, který popíše GUI
- nějaký stylovací mechanismus, kterým lze v GUI upravit vzhled
- mechanismus observerů, lisnererů a životního cyklu, kterými se na GUI navěsí...
- ...třídy, které poskytují data a aplikační funkčnost

JavaFX, QT, GTK Glade, XCode Interface Builder i webové frameworky to mají všechny +- stejně. A v těch webových frameworcích se dnes píšou i desktopové aplikace. Takže na druhou stranu si není moc na co stěžovat, ta architektura je docela dobrá.

13
Vývoj / Re:Moderný frontend - ako na to?
« kdy: 05. 07. 2025, 16:54:21 »
Můj osobní názor: Pro weby, které nemají charakter aplikace (=dokumentově orientovaný web), je ideální dobře ostylované čisté HTML, může být krásně responsivní, mít i různé CSS efekty, animace, pokud se bez nich neobejdeme. Nedivil bych se, pokud bychom se dočkali renesance, s trochou nadsázky ve smyslu https://justfuckingusehtml.com/cs-CZ Ať se celé html posílá ze serveru, může to být extrémně rychlé, extrémně dobře cachovatelné, strojově dobře zpracovatelné. Takový měl web původně být!

Pro weby, které mají charakter aplikace (=uživatel se naloguje a vidí data, která jsou unikátní s ohledem na provedené interakce), je podle mě ideální použít js framework typu Vue, Angular. Pak se webové aplikace programují podobně jako desktopové aplikace, data se tahají přes REST API a komponenty webového GUI v reálném čase zobrazuje data aktuálně obsažená v modelu. Stačí se naučit knihovnu widgetů a pak se programuje dost vysokoúrovňově, člověk neřeší implementační detaily, což by jako aplikační vývojář ani řešit neměl. Ideálně použije  Typescript. Čistý javascript má přínos právě v tom, že to je dnes už dobrý podvozek pod ty js frameworky a umí v základu vše, co dříve řešilo JQuery, které už je však dnes jednoznačně přežitek.

Nevýhoda js frameworků a celého JS světa byl překotný vývoj, použitý vývojový stack zastaral klidně během pár měsíců. To se ovšem zlepšilo, protože dnes už se z celého odvětví stal mainstream a konzervativní volba.

14
Na tohle Android není dělaný, použij standardní operační systém a nebudeš mít problém. Pokud má něco běžet na Androidu trvale, musí to být naprogramované jako služba, což normální appky nejsou. Bohužel mi celý Android přijde zmatený, třeba odebírání oprávnění - WTF? Nastavím aplikaci oprávnění a on mi je zase náhodně odebere. Třeba appka MujRozhlas mi funguje správně jen určitou dobu po nainstalování, pak se začne ukončovat a to i když ji mám na popředí. Důvod neznám, ale možná přišla o nějaká oprávnění, která neumím přidat. Pomůže reinstalace. Mimořádně otravné.

15
Vývoj / Re:Možnosti mobilných aplikícií
« kdy: 29. 06. 2025, 14:22:41 »
OK, to som prave chcel vediet.

Z vyssie uvedeneho mi vychadza, ze asi najvhodnejsie riesenie bude mat povodne jednoduche riesenie, ak BAR nechce riesit moc logiky, a vsetko riesi klient cez prehliadac, ale zaroven mat aj moznost oauth, aby to mohol riesit aj backend webu/aplikacie BAR ak chce.

Ano a do budoucna bych pak už počítal jen s Oauth - je to standard.

Stran: [1] 2 3 ... 93