Příspěvky

1

Vývoj / Re:JavaScript: ako sledovať websocket upload?

« kdy: 13. 12. 2024, 13:40:43 »

A co posílat informace ze serveru na klienta, kolik dat se už poslalo? Na serverové se ví, kolik dat přiteklo, takže pomocí něakého identifikátoru, který si client/server vymění, posílat informace skrze WS kolik toho bylo přijato.

Nebo potom použit XMLHttpRequest, který to umí :-/

2

Server / MariaDB query cache a InnoDB

« kdy: 28. 02. 2024, 13:59:02 »

Ahoj všichni,

obecná otázka, má smysl dneska ještě zapínat query cache na MariaDB/Mysql pokud jsou data pouze v InnoDB (a vlezou se do RAM) a jede to na vícejádrovém procesoru? Není zapnutí kontraproduktivní?

Na produkci jsem ji vypnul a nevidím žádné zhoršení (poměr read/write je 70/30). Na vývoji mám "on demand" ale vlastně je to hloupost, protože stejně se musí DB dívat do cache zda tam něco není (přičemž SELECT SQL_CACHE se v aplikaci nachází vyjímečně).

Jde mně o bottlenecky způsobené sdílením prostorem query cache.

Díky za odpovědi

3

Vývoj / Re:JS regex

« kdy: 16. 02. 2024, 07:52:27 »

Omlouvám se za trochu offtopic, ale vzpomněl jsem si na kolegu, který na všechno psal regexpy. Na co DOM, json, Xpath, vytahnu to regexpem!

4

Vývoj / Re:MySQL a přecenění se změnou DPH

« kdy: 01. 01. 2024, 21:24:47 »

To se ta diskuze teda rozjela.. Eshopy dělám dlouho a zatím mne vychází ze nejlepší je evidovat jako hlavní cenu tu bez DPH, jakékoliv převody totiž dal jsou jednoduší (do cizí měny, vývoz zboží do EU, reverse charge, OSS). Stejně tak, když se mění sazba DPH tak přecenění zboží je jednoduší. A zároveň evidovat u tu sazbu a cenu s DPH pro některé případy, aby se s tím dobře pracovalo a pohlídat si, aby vždy v DB vše sedělo, pak je to ideál (i z pohledu dalších věcí jako, dát nějakou slevu pokud obj. je nad X částkou (a ta je zase někdy s a nekdy bez DPH).

PS: řeším to z pohledu, že systém umí vystavovat doklady (a rozlišovat jednotlivé položky a členění DPH s návaznosti dále - intrastat, dovoz a vývoz). Samozřejmě tohle menší eshop neřeší, tam to nějak udělá dal účetní - pokud tyto případy vůbec nastanou..

5

Vývoj / Re:XSL podmíněný foreach

« kdy: 29. 08. 2023, 14:53:25 »

current() má i XSLT 1.

Jinak lze celý výstup zabalit do proměnné a pak projet for-eachem. Nevím jak to má Saxon, tam se zdá to funguje by-default, jinak použít node-set()

https://xsltfiddle.liberty-development.net/6r5EJSU/24

Na rychlost ohledně for-each VS apply-templates se musím podívat, jak to vychází..apply templates právě moc nepoužíváme (ale máme malé XMLka), někde by se to mohlo hodit...

6

Vývoj / Re:XSL podmíněný foreach

« kdy: 29. 08. 2023, 14:27:59 »

Počkat.. vy chcete udělat jen group by Row/ItemCode a následně projete všechny ItemCode? postupně?

7

Vývoj / Re:XSL podmíněný foreach

« kdy: 29. 08. 2023, 13:36:08 »

Nebo přímo ve for-each:

https://xsltfiddle.liberty-development.net/6r5EJSU/21

Kód: [Vybrat]

<xsl:for-each select="ResultSet/Row[not(preceding-sibling::Row/ItemCode=ItemCode)]">
  <xsl:copy-of select="." />
</xsl:for-each>


8

Vývoj / Re:XSL podmíněný foreach

« kdy: 29. 08. 2023, 12:34:29 »

Příklad s "if", sedí to?

https://xsltfiddle.liberty-development.net/6r5EJSU/20

Kód: [Vybrat]

<xsl:for-each select="ResultSet/Row">
  <xsl:if test="not(preceding-sibling::Row[current()/ItemCode=ItemCode])">
    <xsl:copy-of select="." />
  </xsl:if>
</xsl:for-each>


9

Vývoj / Re:XSL podmíněný foreach

« kdy: 29. 08. 2023, 12:22:39 »

Porovnání ItemCode=ItemCode je zjevně nesmysl, XPath procesor nemůže vědět, že tím jednou myslíte ItemCode z kontextu před spuštěním XPath výrazu a podruhé ItemCode v rámci XPath výrazu.

Doplním, že pro tyto případy lze použít funkci current(), která kontext určí přesně. Takže podmínka pak jde použít nějak takto:

ItemCode=current()/ItemCode

Používám běžne pro for-each, kdy chci rozlišit zda hodnota se vztahuje na data uvnitř for-eachu, nebo vně.

10

Vývoj / Re:Trendy v PHP

« kdy: 07. 09. 2022, 10:33:47 »

to je zase flame..

11

Vývoj / Re:SQLite key-value atribúty

« kdy: 11. 04. 2022, 10:00:43 »

Není v tabulce headers sloupec ID zbytečný? Jeden soubor asi nemůže mít více stejných hodnot, pak bych PK volil (id_file, key).

12

Vývoj / Re:javascript prototype

« kdy: 07. 03. 2022, 15:42:23 »

V prvním případě je funkce sdílená napříč všemi instancemi (v prototypovém řetězci). V druhém případě se anonymní fce (uložená do proměnné starne) vytváří pokaždé znova.

13

Vývoj / Re:Je „responsivní“ design až zase tak potřebný?

« kdy: 28. 01. 2022, 09:17:46 »

Já mám za to, že responsive vznikl na základě lenosti programátorú/koderů, zkrátka se nechtělo dělat samostatné weby pro různá zařízení...

No, to máte za to špatně. Důvodem pro responzivní weby je, že separátní weby se mají neustále tendenci rozjíždět, pořád se řeší, že v desktop verzi chybí něco, co je v mobilní nebo naopak, nebo hůř, že tam je jedna věc implementovaná různým způsobem, část uživatelů to mate a chce to sjednotit, část zuřivě brání současné řešení. Plus se i přes sdílení kódu nevyhnete duplikování práce... Peklo. Proto je tlak na to, aby to byla jedna aplikace s maximálním sdílením kódu a lišil se jen styling. Ne vždy to jde a i tak se některé věci musí implementovat 2x, protože mobilní verze je příliš odlišná, ale přesto je to lepší cesta.

A dalším, IMHO hlavní motivací bylo a je to, že není jeden mobilní web. Ale je jich asi padesát. To chcete dělat padesát různých webů?

BTW: Lenost je někdy dobrá vlastnost :-)

Nevím zda si rozumíme. Já říkám udělat mobilní web, který bude perfektně fungovat vč. toho, že se bude dobře zobrazovat na malých i velkých displejích (takže lehce responziv) a to stejné pro desktop. Pak je výsledek nejlepší možný. Lenost je někdy dobrá vlasnost, o tom žádná Ale, nemělo by to být na úkor kvality (a ano, jsou weby kde se to nevyplatí a stačí "nějaký" responsive, ať to nějak funguje na všech zařízení a hotovo).

14

Vývoj / Re:Je „responsivní“ design až zase tak potřebný?

« kdy: 27. 01. 2022, 22:09:11 »

Já mám za to, že responsive vznikl na základě lenosti programátorú/koderů, zkrátka se nechtělo dělat samostatné weby pro různá zařízení...

No, to máte za to špatně. Důvodem pro responzivní weby je, že separátní weby se mají neustále tendenci rozjíždět, pořád se řeší, že v desktop verzi chybí něco, co je v mobilní nebo naopak, nebo hůř, že tam je jedna věc implementovaná různým způsobem, část uživatelů to mate a chce to sjednotit, část zuřivě brání současné řešení. Plus se i přes sdílení kódu nevyhnete duplikování práce... Peklo. Proto je tlak na to, aby to byla jedna aplikace s maximálním sdílením kódu a lišil se jen styling. Ne vždy to jde a i tak se některé věci musí implementovat 2x, protože mobilní verze je příliš odlišná, ale přesto je to lepší cesta.

To říkáme oba dva to stejné, jenom každý trochu jinak. Duplikování je peklo, ale tím že udělám responsive, ten problém přesunu akorát jinam a částešně i na návštevníka...a pak je otázka, co je horší.

Responsive si nese negativa: nikdy nemůže být tak dobrý na ovládání jako mobilní/desktopová verze, která je na míru. Tahá se hromada kódu navíc, obecně má ve WebVitals horčí skóre a pak se to vše projevuje na tržbách (pokud je to e-shop). Jsou to drobnosti, ale ve výsledku to udělá hodně.

15

Vývoj / Re:Je „responsivní“ design až zase tak potřebný?

« kdy: 27. 01. 2022, 14:40:15 »

Já mám za to, že responsive vznikl na základě lenosti programátorú/koderů, zkrátka se nechtělo dělat samostatné weby pro různá zařízení a tak zkouší takto. Někdy to funguje dobře, vetšinou však ne..

Za mně: pro mobil je nejlepší mobilní web, stejně jako pro desktop desktopový. Responsive bych nasadil na obě verze webu (mobil/desktop) pro případy, kdy je rozlíšení různé (malé velké displeje/monitory) - pak je to ideál pro návštevníka, vždy to má přesně tak, jak potřebuje. (viz třeba alza, která má mobilní web..)