reklama

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 - user398

Stran: [1]
1
Vývoj / Re:Bezpečná session v PHP
« kdy: 18. 03. 2020, 11:22:40 »
Aj na UOOU to pisu:

Pro cookies nezbytně nutné pro zajištění provozu webových stránek a internetových služeb není nutno získat souhlas uživatele (interpretační vodítka k určení takových cookiesposkytuje WP194).

2
Vývoj / Re:Bezpečná session v PHP
« kdy: 18. 03. 2020, 11:18:37 »
S tymi cookies to nieje tak ze zakladne first-party cookies (sem patri aj session cookie) potrebne na beh webu su v GDPR povolene a netreba pytat suhlas. Suhlas je potrebny na statisticke, reklamne, 3rd party cookies a podobne.

3
Vývoj / Re:Ukládání různých typů produktů do databáze
« kdy: 20. 12. 2019, 13:23:00 »
U variantov produktov je problem napriklad ako ukladat cenu daneho variantu produktu.

Povedzme ze mame produkt tricko (base price 10€) s atributmi: velkost (s, m, l, xl), farba (green, blue, red) a potlac (ano, nie), pricom niektore atributy nam mozu ovplyvnovat aj zakladnu cenu (velkost XL +5€, farba blue +5€, potlac ano +10€). Takze mame dokopy 24 moznych kombinacii s roznou vyslednou cenou:

Kód: [Vybrat]
s, green, ano(+10) = 20€
s, green, nie = 10€
s, blue(+5), ano(+10) = 25€
s, blue(+5), nie = 15€
s, red, ano(+10) = 20€
s, red, nie = 10€
m, green, ano(+10) = 20€
m, green, nie = 10€
m, blue(+5), ano(+10) = 25€
m, blue(+5), nie = 15€
m, red, ano(+10) = 20€
m, red, nie = 10€
l, green, ano(+10) = 20€
l, green, nie = 10€
l, blue(+5), ano(+10) = 25€
l, blue(+5), nie = 15€
l, red, ano(+10) = 20€
l, red, nie = 10€
xl(+5), green, ano(+10) = 25€
xl(+5), green, nie = 15€
xl(+5), blue(+5), ano(+10) = 30€
xl(+5), blue(+5), nie = 20€
xl(+5), red, ano(+10) = 25€
xl(+5), red, nie = 15€

Ak varianty priradujeme k produktu naivne, napriklad takouto tabulkou ProductVariants:
FK product_id: 123 (->tricko)
FK attribute_id: 456 (->velkost)
FK atribute_value: 789 (->XL)
price: +5

tak mame minimalne 2 problemy:
1. nevieme pokryt vsetky mozne kombinacie cien, ale len tychto 24. Ak nejakej hodnote atributu priradime cenu (potlac ano = +10€) tak sa objavi vo vsetkych kombinaciach kde atribut vystupuje. Lenze marketing bude chciet pre kombinaciu atributov potlac s modrou farbou (lubovolna velkost) len +5€ miesto +10€ za potlac, pretoze potlac na modru farbu je lacnejsia ako na ine...
2. Aku cenu zobrazovat v product listingu ked si user prechadza kategorie? Logicky najmensiu, ale nemozeme tam dat automaticky cenu base produktu (10€) pretoze ak produkt ma iba take atributy ktore zvysuju cenu tak najnizsia cena nemusi byt rovnaka ako cena base produktu. Za toto pokutuje napriklad Google ak chcete byt v nejakych jeho feedoch. Musite zobrazovat cenu za aku si to moze zakaznik kupit. Urobit SQL na product listing ktory dynamycky prepocitava ceny podla atributov a vybera najnizsiu (+ rozne ine filtre ktore si user moze naklikat) je pre SQL masiny nemozne v relanom case s realnymi resourcami. Nam to davalo cca 10-30 sekund na request.
3. Su mozne este vylepsenia ze nejaky atribut moze cenu aj znizovat...

Alebo mozeme tieto vsetky mozne kombinacie atributov ukladat zvlast pod vlastnym ID a pokladat to za samostanty produkt, takze miesto jedneho tricko produktu budeme mat max 24 produktov. To je fajn pretoze mame volnost nastavovat lubovolnej kombinacii atributov lubolne ceny. Ak nejaka kombinacia atributov nedava zmysel tak ju neuvedieme (tricko velkosti S s lubovolnou farbou nevieme vyrobit s potlacou lebo sa nam nezmesti na plochu tricka) takze budeme mat menej zaznamov (24 - 3 = 21). SQLka su jednoduchsie, na ukor duplikacie dat v DB. Ale mame aj problemy:
1. Narastie pocet zaznamov v DB. A moze aj extremne. U zlozitych produktov s vela atributmi, pricom tie atributy mozu mat vela roznych hodnot mozeme dostat az milion kombinacii pre jeden produkt. Co ked mame takychto produktov vela?
2. Zlozitejsia administracia. Editor musi vediet nastavit davkovo ceny pre rozne kombinacie atributov, pretoze nechce zadavat manualne vsetky kombinacie, ale zas musi vediet nastavit ked chce aj lubovolnu moznu kombinaciu. OK, u toho tricka s max 24 kombinaciami mozeme zobrazit maticu input boxov ale co ten produkt s milion kombinaciami?

Okrem ceny sa samozrejme k jednotlivym variantom ukladaju aj ine udaje, napr. skladove zasoby. Modrych triciek velkosti XL mam na sklade ine mnozstvo ako cervenych L. Musim vediet vypinat docasne niektore kombinacie atributov,...

Ak vysledkom ma byt tzv faceted search tak by som zvazil pouzit kombinaciu SQL DB + ElasticSearch/Solr. Pri administracii zapisujem do SQL a potom synchronizujem do ES. ES je perfektny na product listing, ked si user filtruje podla roznych parametrov (product name obsahuje 'Adidas' (fulltext), velkost L, modra farba, cenova hladina 10-20€, kategoria 'Panske tricka', na sklade). S ElasticSearchom dostavame response v milisekundach.

EAV pouziva napr. Magento ale tiez maju tzv flatten tabulky, pretoze EAV je moc kosate a rozumny product listing nad tym neurobis. Plus samozrejme tiez tam ide pouzit NoSQL na zrychlenie.

4
Hardware / Re: Krabička k TV/IPTV nebo GPU do serveru?
« kdy: 12. 12. 2019, 10:36:58 »
Zvladne RPi4 video 4k@60fps s vysokym datovym tokom?

5
Modelovy priklad: zamestnavatel ze sve neschopnosti a amoralnosti zamestnava a vydruze kretena obecneho, ktery sikanuje sve podrizene. Tuto skutenost zatajil.

Zakon na to mysli, konkretne na to sluzi 2-mesacna skusobna doba, vtedy mozes odist hned. Za ten cas by si mal zistit ako to vo firme funguje, ake su tam vztahy a ci tam chces zostat.

BTW a preco vlastne to chces riesit? Ved sa podvol a vydrz to tie 2 mesiace. Nie vsetky bitvy v zivote musis vyhrat. Ber to tak, ze ludom sa stavaju zle vecy a jedna sa nahodou stala tebe. Je to osud.

6
Vývoj / Re:Váš názor na kombinaci několika technologií
« kdy: 02. 08. 2019, 09:22:53 »
Java v soucasnosti stale nema zadnou konkurenceschopnou alternativu pro enterpsise backend.

A čo hovoríš na PHP?

7
Vývoj / Re:Domácí meteostanice
« kdy: 10. 07. 2019, 12:25:44 »
Byl tam nejaky endpoint, kteru vracel meteostanice v okoli. Neco jako /stations/find?lat=xxx&lon=yyy&count=10
Ted ho nemuzu najit, ale tenkrat bylo api verze 1. Dokonce jestli si dobre vzpominam tak meli mapu stanic.

https://openweathermap.org/stations#get_stations

8
Vývoj / Re:Je Swagger utter crap?
« kdy: 04. 04. 2019, 00:28:43 »
Zaprve je treba si ujasnit, proc chceme dat pryc SOAP. Z meho uhlu pohledu jediny rozumny duvod ktery jsem slysel je, ze se to blbe pouziva treba prave javascriptarum.

Ale to je validný a rozumný dôvod. Angular, React, Vue,.. konzumuje zvyčajne REST API, nie SOAP. Použitie RESTu v komunikácii backend -> JS frontend je správne! Neznásilňuj rokmi overené postupy!

Podle me je SOAP v principu genialni a nikdo nevymysli nic lepsiho - tehda moc dobre vymysleli, jak mezi sebou maji backend komponenty komunikovat.

Jo, na komunikáciu medzi backend komponenty si nechajte SOAP. Javascriptár z frontendu vám nemá čo kecať ako si vy budete komunikovať medzi backend komponenty! A naopak, ak Javascriptár chce na frontend REST tak mu ho dajte a nekecajte mu do jeho práce!

Neni zde zadny prostor pro impresionisticke umelce programatory, a to je vzycky dobre.

Jo, ale impresionistické by bolo posielat chudákovi Javascriptarovi SOAP, tam frčí REST!

9
Vývoj / Re:Je Swagger utter crap?
« kdy: 03. 04. 2019, 19:02:03 »
Ak som to pochopil správne tak jediný problém je, že tam kde ste mali použiť RPC máte REST. Použili ste dobrú technológiu na nesprávnom mieste a teba to serie. Vaša chyba.

PS: Prečo tam nedáte GraphQL?!  :D

Stran: [1]

reklama