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

Stran: [1] 2 3 4
1
Vývoj / Re:Nahodne chyby v UI testech - jak resite?
« kdy: 23. 12. 2020, 13:55:16 »
Ješte by stálo za to se zamyslet, zda místo toho že se nestíhá něco načíst při testech (ačkoliv je to asi nejpravděpodobnější varianta).
Tak zda náhodou není problém skutečně v aplikaci/ testované stránce (například něco přeteče, nebo se použije něco z chache která se nestihla vyčistit atp.).
Ale to je spíše pro případ že ta chyba je alespoň trochu konzistentní (myšleno dokud neuděláte změnu v testech tak se vyskytuje na přibližně tom samém místě), a také na tom jak je ta aplikace postavena(běží celá na serveru, nebo větší část v prohlížeči,...)

2
Vývoj / Re:Nahodne chyby v UI testech - jak resite?
« kdy: 23. 12. 2020, 13:44:46 »
V podstatě pan Filip Jirsák odpověděl, ale kdybych to mněl napsat trochu více polopaticky, soustředil bych se hlavně na to zda v testech nemáte někde natvrdo delay/sleep a (nejen ) tam doplnil čekání až budou data a potřebné prvky UI načteny a zobrazeny.

Pár dalších tipů, i když pravděpodobně už je znáte :)

Osvědčilo se mi v některých případech přidat čekání na jquery atp (postup se dá vygooglit).

Správné čekání je třeba zajistit také pokud třeba část dat nejprve načtete jako html a pak parsujete zvlášť mimo selenuim(někdy se dělá kvůli rychlosti) - občas někdo zapomene.

Případně, pokud už to nejde jinak tak se někdy dá najít nějaký prvek který je zobrazen jako poslední až po načtení všech dat a nejprve na něj počkat. A až pak pokračovat, ale je to spíše workaround a ne vždy možný.

Dále někdy může být problém, pokud danou instanci prohlížeče používáte moc dlouho.
Pokud to není nutné z hlediska testu(např kontrolujete zda nedojde k problémům pokud padesátkrát přepnete v rámci aplikace na jinou stránku - fuj), tak může být lepší(i když někdy pomalejší) mít pro každý test(nebo alespoň sadu testů) samostatnou instanci.
Ze zkušenosti, občas nemá selenium/webdriver rád když se ta instance používá moc dlouho - jedna na všechny testy, ale může se lišit i dle prohlížeče a verze,... .

A obecně mít jednotlivé testy na sobě nezávislé - ostatně myslím že to je i v nějakých doporučeních co jsem viděl, určitě je dobré se  na ně podívat.

Také může být užitečné, pokud to neděláte,  uložit si screenshot, html, či nějaké další detaily při chybě. Aby se dalo snáze najít co se nestíhá.

3
Windows a jiné systémy / Re:Grafika ve Windows
« kdy: 30. 09. 2020, 09:30:46 »
Třeba si to nerozumí s těmi dvěma kartami, zkus pro ten program vynutit aby jel na té jedné konkrétní grafice (začal bych tou radeon). Ale nejsem si ale jist kde to nastavit, možná naklikat v sw pro grafickou kartu nějaký "herní" profil pro tu konkrétní aplikaci, nebo vygooglit.

Jednou mi to v podobné situaci pomohlo.

4
Hardware / Re:Životnost SSD šifrovaného na úrovni OS
« kdy: 02. 09. 2020, 10:19:48 »
TRIM může ovlivnit případnou rychlost zápisu ale podle mne by to životnost disku ovlivnit (moc) nemělo.

Pokud to hodně zjednoduším(ignoruju složitost wearleveling algoritmů) tak při předpokladu že zapisovat se může jen do smazané oblasti, tak TRIM umožnuje fyzicky smazat bloky dat které už nejsou potřeba v čase kdy se nic jiného nedělá, místo toho aby se mazalo až při povelu na zápis/přepis dat(což zápis zpomaluje).

Počet přepisů ani mazání by to přímo ovlivnit nemělo, ačkoliv to může mít vliv na chování wearleveling algoritmu.

Nejsem uplně specialista na šifrování, ale např "bitlocker on the go" (verze pro flashdisky) nešifruje by default úplně celý disk, ale jen data + cca 7GB volného místa, a teprve když dochází tak ho doplňuje z zatím nevyužitého prostoru.Takže pokud nevyužijete celou kapacitu, tak na disku může zbývat více dost "nevyužitého" místa pro wearleveling i bez TRIM (ale já vlastně nevím jestli to vůbec TRIM podporuje).

Jediný důvod proč by šifrování jako takové mohlo mít vliv na životnost disku je komprimovatelnost.
Některé disky data komprimují čímž se šetří zápisy a místo pro "wear leveling" čímž se má zvyšovat "endurance". Ale přiznám se že v tomto také nejsem moc kovaný jak přesně to funguje.

5
/dev/null / Re:charakterizace směrování a forwardování?
« kdy: 27. 03. 2020, 18:41:46 »
Protože to porovnáváš předpokládám že jde o IP Routing a IP forwarding

1routování) první část, že nejde vždy o přesnou schodu, je ok, ale nedržel bych se konkrétních věcí (jako ip+maska) ale spíše jen že jde obecně o výběr nejlepší cesty na základě dostupných informací. Vliv může mít také metrika, nějaké policy, kvalita linky? A já nevím co ještě.

1forward) souhlas

2r,2f)toto je dle mne u obojího stejné, vždy jde o rozhodnutí kam packet poslat dál.
Cílová adresa se také nemění(není zde náhodou záměna s port forwardingem, to je tak trochu nezávislá funkce).

3r) Ano, Ale platí to pro obojí, ani routing ani forwarding nemusí znát cíl přímo(viz 4).

3f) ano, ale řekl bych že "na konkrétní uzel"(bez ohledu na to jestli tam paket končí nebo ne)

4r)ne, Ale dá se říci že routování je výběr/hledání "nejlepšího směru"(repektive dalšího node ne nejlepší cestě) pro danné spojení/packet kam se má posílat -> a tato "cesta"(respektive node/směr) se pak například "uloží" do forward table.Nebo se také dá říci že packet se dle nalezené cesty Forwarduje dál.

4f)to je trochu zamotané, Řekl bych že forwardování je vlastní přeposlání packetu podle jednoduché tabulky, Bez nějakého dalšího vyhodnocování - prostě když najdu odpovídající záznam v tabulce tak to pošlu kam tabulka říká že se má poslat.
Ale ano, je to předání/odeslání packetu na nejbližší vhodný uzel (nikoliv nezbytně cílový uzel).

5r)Ano
5f)Ano

Někdy se používá pojem routování i ve významu včetně přeposílání packetů tj (routování+forwardování) záleží v jakém kontextu je použito.

Také je tu "port forwarding", což je trochu jiná funkce, node může komunikaci "přesměrovat" ve významu změny cílové adresy/portu někam jinam - i tak se ale paket směrek od a k node routuje a forwarduje (ve smyslu IP routing/IP forwarding)

6
Software / Re:Aké povinnosti mám ak používam GPL software
« kdy: 03. 01. 2020, 21:05:27 »
Níže nerozlišuji konkrétní verzi GPL a jde spíše o obecné postřehy - jde o můj laický názor - každopádně by jste měl kontaktovat právníka přes licence!

Add 1) a 3)
Ta hranice kdy ano a kdy ne je podle mne nejasná, a určit v konkrétním sporném případě ji pravděpodobně může jen soud :(
Vytvořením mezi-části, byť by používala roury nebo TCP se nemusíte zbavit odpovědnosti respektovat GPL viz nejen poznámky níže.(a může na to být nahlíženo jako pokus o obcházení GPL, zejména ale nejenom pokud autoři oficiálně prohlásí že to není v souladu s jejich výkladem)

Některé další (nekompletní) postřehy ohledně výkladu k 1) a 3)

Podle některých výkladů se o "odvozené" dílo jedná i pokud je program distribuován jako celek (např. instalátor nainstaluje zároveň vaší aplikaci i databázi je na hraně, neřkuli pokud rovnou bude nakonfigurované jejich propojení).

Někde jsem také viděl uvedeno že se považuje za odvozené dílo, pokud jsou využívána nějaké specifika, nebo interní struktury díla které je kryto pomocí GPL.
A to bez ohledu na to jestli s pro komunikaci používají třeba roury nebo TCP, využití API - včetně i dost obecných API(asi extrémní výklad ale někteří autoři to tak mohou vidět).

Komunikaci s databází většinou zajišťuje nějaká knihovna která je přímo integrovaná do vaší aplikace. Takže je třeba se podívat i na její licenci, zda náhodou také není, nebo neměla by podléhat GPL, pak ji také musíte respektovat.

Ale není to tak černé.
Je třeba se ještě podívat na co všechno se licence aplikuje. Pokud není specifikováno, tak je bezpečnější předpokládat že na vše. Ale může být uvedeno(pokud možno veřejně), že např. na používání určitého API se GPL nevztahuje(pokud na to ovšem nepoužíváte knihovnu která je pod GPL).

Takto např. funguje uživatelské api v linuxu, nebo tuším že nějaký sw to měl pro podporu ne-gpl pluginů.
Je možné že k vaší DB existuje nějaký license-FAQ který osvětluje zda umožňuje použití clientských knihoven nebo API i v GPL nekompatibilních programech případně kterých a za jakých podmínek. Viz zmiňovaná MariaDB
Pokud je to nějaká známá a rozšířená databáze je ke zvážení zda to risknout(věřit že si to nerozmyslí a nebudou pak své uživatele licenčně trolovat).

Add 2)Je tu více možností, prosím přečtěte si tu licenci. Podle jedné z možností je ale povinnost poskytnout kód každému kdo vlastní binárky(což možná nutně neznamená že je má přímo od vás).
Nejjednodušší je ale rovnou dodat "zdrojáky" spolu s binárkami či zařízením (forma i rozsah zas dle licence).

Obecně)
Asi by bylo dobré si projít(přinejmenším):
 - stránky GPL produktu který chcete zakomponovat.
 - anglickou verzi GPL licence
 - anglické stránky www.gnu.org včetně různých FAQ
 - české stránky www.gnu.org včetně různých FAQ
 - různá fóra a poradny

Potom navštivte právníka přes licence a spolu s ním rozhodněte(pořadí není nutně dle preference):
a)Uvolnit vše v souladu s licencí GPL
b)Vyhnout se kombinováním děl s GPL licencí a děl s nekompatibilními licencemi. (respektive najít si jinou DB)
c)Vyžádat (nejlépe přes právníka a písemný) souhlas autora/autorů/nadace která dannou GPL část vyvíjí, zda je vaše použití v souladu s jejich výkladem.
d)Riskovat, že váš výklad licencí a případných výjimek je správný

7
Server / Re:Maximální počet klientů vlastního TCP serveru
« kdy: 19. 12. 2019, 20:44:24 »
Dik za reakce, zkousim co se da...googleni, zmena bufru a nic nepomaha. Vse se zda ze by to melo fungovat.
Posledni reakce:
Citace
Střelba od boku: nepoužíváš náhodou select()?
Tak zde jsem ze zaseknul, protoze select skutecne pouzivam....
Nedávno jsem si dělal takový teoretický průzkum tak jsem na to narazil.
Viz ten odkaz co jsem dával, pro takhle velký počet to na linuxu nejspíš nebude fungovat.
Ono obcně pro tolik socketů je select považován za pomalý a používá se spíš něco jako poll nebo epoll.
Případně nějaké knihovna co použije to co na danné platformě je, třeba libevent.

Jinak ten problém může být i jinde, jak už tu bylo napsáno, to bych nepodceňoval.
Možná by pomohl log návratovými hodnotami jednotlivých funkcí, nebo alespoň těch co vrací chybu :) .


Nějaké odkazy:
http://man7.org/linux/man-pages/man2/select.2.html
http://byteliu.com/2019/05/08/LINUX-–-IO-MULTIPLEXING-–-SELECT-VS-POLL-VS-EPOLL/
https://blog.cloudflare.com/io_submit-the-epoll-alternative-youve-never-heard-about/

8
Server / Re:Maximální počet klientů vlastního TCP serveru
« kdy: 19. 12. 2019, 15:48:23 »
Střelba od boku: nepoužíváš náhodou select()?
Tam je limit FD_SETSIZE pro jednu sadu socketů což může být zrovna těch 1024.
A navíc se zdá že to může mít problém s hodnotou handle>1023
Viz http://man7.org/linux/man-pages/man2/select.2.html

Pokud ano, tak zkus kouknout na alternativy (poll, epoll,...)

9
Hardware / Re:Stabilita ESP8266
« kdy: 24. 10. 2019, 13:50:23 »
V navázání komunikace to není, ta je bez problémů. Třeba problém na kterej jsem nikdy nepřišel když je ESPčko připojené k TCP serveru a to spojení někde na cestě zanikne. Toto není v TCP nijak ošetřeno nebo nevím jak. ESPčko si stále myslí, že je spojení aktivní a čeká na příchozí data, protože z pohledu aplikační vstvy je v komunikaci slave. Těch se už nikdy nedočká. Toto je pro mě situace ze které se ten client jednoduše nedostane. Toto je samozřejmě řešitelné. Hůř řešitelná situace je, když espčko samo náhodně spadne. Z mých zkušeností to je v 99% způsobeno při mechanizmu přidělování dynamické paměti, který zkolabuje. Toto je samozřejmě také řešitelné, ale už je to v celku náhodný proces, který se nedá jednoduše ladit. Jedině zkoušením.

S ESP nemám zkušenost tak nevím jestli podporuje.
Ale obecně, pokud nemůžete nebo nechcete zasahovat do komunikace(přidat si tam nějaké "pingy" každých x vteřin/minut), tak může být řešením povolit na tcp spojení(respektive socketu) tzv TCP keepalive, který to dělá na pozadí komunikace, ale je třeba si pohlídat že to druhá strana podporuje, a upravit časy - defaultní jsou většinou dost dlouhé ale trošku to také zatěžuje linku, tak to zas moc nepřehánět.
Na malých "procesorech"je taky třeba fávat pozor na stav TIME_WAIT pokud ukončujete na straně zařízení.

10
Vývoj / Re:Dotaz na yield (PHP)
« kdy: 20. 10. 2019, 10:22:15 »
Zajímá mě, jestli by se z toho kódu mezi file() a ksort() dala udělat funkce která bude yieldovat výstup do toho $indexes.

Vložit yield mezi file() a ksort() mi v tom kontextu nedává smysl, podle mne nic neušetříš.
Na začátku totiž načítáš najednou celý obsah souboru do paměti.
A právě aby nemusel být celý soubor v paměti najednou, můžeš přepsat kód tak že bude číst data po jednotlivých řádkách (např tou funkcí fgets( )) a zpracovávávat postupně. Během zpracovávání souboru pak bude muset být v paměti jen právě jedna zpracovávaná řádka. (mluvíme tady o vstupních datech $emails, nikoliv o datech které ukládáš do indexes)

Namísto načtení kompletního obsahu souboru pomocí $emails = file("adresy.txt"); bys tedy mohl použít "generátor" $emails = getLines("adresy.txt");
To pak funguje tak že v tom foreach se vždy provede kousek toho "generátoru" až dokud nevrátí hodnotu pomocí yield.
Pak se provede kód v tom foreach a pak zase ze provádí kód v tom generártoru,od místa kde skončil, až do dalšího yield, a tak pořád dokola až dokud generátor neskončí.
Nahrazení tohoto prvního řádku (a přidání generátoru dat jednotlivých řádek) je jediná věc co bys měl v kontextu tvého odkazovaného článku udělat.

Výhoda je že si můžeš do toho "generátoru" dát další logiku, npř filtrovat nevhodné řádky nebo třeba kompletně parsovat a vracet už zpracované řádky nebo třeba kompletní objekty atp.
Případně se dají generátory vrstvit, třeba jako filtry atd.


P.S. nezapomeň také ošetřit uzavření souboru v případě vyjímky (což je dobrý nápad v každém případě)
např zde: https://www.php.net/manual/en/language.generators.overview.php
Kód: [Vybrat]
function getLines($file) {
    $f = fopen($file, 'r');
    try {
        while ($line = fgets($f)) {
            yield $line;
        }
    } finally {
        fclose($f);
    }
}

11
Trochu jsem si pro sebe googlil protože mne něco podobného možná čeká (mám v dlouhodobém plánu zkusit napsat jednu servisu), třeba to tazateli pomůže, případně to někdo rozvede více :)

Po delším googlení "NT AUTHORITY\NetworkService" atp jsem narazil na pojem "Windows service isolation" - ale nic moc popis k tomu,jen že je to od Vist výše a že to používá třeba mssql.
A po další delší době jsem našel - Virtual accounts "NT SERVICE\ServiceName"  a pro doménu "Managed accounts"
A k tomu se už dá googlit lépe:
https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/service-accounts
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd548356(v=ws.10)?redirectedfrom=MSDN

"Virtual accounts" jsou jako jako NT AUTHORITY\NetworkService ale je to izolovaný "uživatel" jen pro tu službu, ale nemusí se řešit hesla, ale jdou nastavovat práva např pro adresáře.
Jen škoda že není i alernativa pro NT AUTHORITY\LocalService (nebo jsem ji nenašel)

12
Vývoj / Re:Jak se chránit pro XSS útoku na php serveru?
« kdy: 12. 10. 2019, 21:27:34 »
Naopak se mi jeví generování XML a HTML přes DOM velmi snadné a elegantní. V žádném případě se nejedná o kanón na vrabce. Dokonce můžeš importovat statické HTML, změnit libovolné nody a poslat na výstup v podstatě stejně jako v Javascriptu. Všechny šablonovací systémy se proti takové jednoduchosti použití mohou zahrabat. Kodérovi stačí, pokud umí HTML a Javascript.

V PHP si zpracuji vstup, načtu či modifikuji data v databázi, načtu šablonu, vložím do ní data, vyplivnu na výstup a hotovo. Vše má PHP v základní výbavě, frameworky nejsou potřebné. Je dobré, pokud použiješ architekturu MVC a budeš se držet zásad SOLID, které bývají ve frameworcích tak často porušovány.

Dovolil jsem si hodně zjednodušený příklad:

Varianta 1:
Kód: [Vybrat]
<?php
 $TextForInsert
='<script>alert(123)</script>';
?>

<html>
    <head>
        <title>PHP Test</title>
        </head>
    <body>
        <div id="TestID">
            <?php echo htmlspecialchars($TextForInsert); ?>
        </div>
    </body>
</html>

Varianta 2:
Kód: [Vybrat]
<?php
$TextForInsert='<script>alert(123)</script>';
?>


<?php
$HtmlTemplate 
= <<<'EOD'
<html>
<head>
<title>PHP Test</title>
</head>
<body>
<div id="TestID">
</div>
</body>
</html>
EOD;
 
$dom = new DOMDocument();
 
$dom->loadHTML ($HtmlTemplate);
 
$dom->getElementById('TestID')->appendChild($dom->createTextNode($TextForInsert));
 echo 
$dom->saveHTML();
?>


V první variantě
 - je třeba zvolit správnou funkci podle toho kam se text vkládá

V druhé variantě
 - Je třeba získat správnou část DOMu
 - Je potřeba vytvořit nový element a vložit do DOm (funkce opět závislá na tom co a kam vkládám)

Pokud máš nějaký větší, složitější systém s více stránkami, sdíleným kódem, dynamickými templaty atp. , tak se druhá varianta asi vyplatí.
Ale pro pár jednoduchých stránek mi to přijde zbytčné. A za snadné a elegantní (oproti první variantě) bych to také trovna neoznačil.

13
Vývoj / Re:Jak se chránit pro XSS útoku na php serveru?
« kdy: 12. 10. 2019, 17:44:07 »
Při prezentaci je zase nutné předat data do HTML, proto se obvykle používá funkce htmlspecialchars(). Z mého pohledu je poněkud zastaralá - PHP nabízí lepší, objektové řešení, u kterého už nemusím přemýšlet nad typem eskejpování v daném kontextu.
Myslíš jako pomocí DOMDocument? nebo něco jiného?
Ideálně prosím dej nějaký příklad kde se to používá.
Ano, mám na mysli DOMDocument. Vyleze z toho hotové XML či HTML, kde jsou potenciálně nebezpečné znaky řádně transformovány do entit.
DOMDocument je možná bezpečnější, ale to "lepší" se mi moc nezdá (spotřeba paměi,výkon,nutnost kompletního DOMu před odesláním na clienta).
Navíc transformace DOMu se dost liší od běžného použití php jako preprocesoru. To už mi přijde "lepší" použít nějaký framework, než toto.Ale to už jsme mimo téma.

Příznivci funkcionálního programování zde mají příležitost, jak se vyřádit. Nutnost kompletního DOMu nevidím jako překážku, jen málo úloh při tom vyžaduje víc než 1 MB. Obvykle to jsou jen desítky až stovky KB, se kterými si hravě poradí v malých jednotkách ms. Odezva je tedy řádově rychlejší než u běžných frameworků. Pokud bys ten DOM nechtěl generovat naráz, tak nemusíš. Uděláš jednu větev, exportuješ, uděláš další, exportuješ,... Efektivnější je však vygenerovat vše naráz, nemusíš tak plýtvat drahým echem. Po odladění jen vypneš odsazování. Navíc se v XML, které dostaneš navíc jako bonus, hledají chyby mnohem snáze než v HTML.
Mno, asi máš pravdu, ale pořád se nemůžu zbavit dojmu že u projektů kde bych uvažoval takhle přímo psát v php je to kanón na vrabce, a jde to proti "duchu" php, jak ho chápu já, cožje víceméně preprocesor pro html s možností doplnit o nějaký ten kód, čtení z db atp.

14
Vývoj / Re:Naučení se asynchronnímu programování
« kdy: 12. 10. 2019, 16:31:10 »
Omlouvám se za trochu delší text, ale je to tak trochu v rámci samostudia :)

Začnu trochu od konce,s epoll-em

Doufám že se shodnome na tom že e to vlastně jen takový rychlejší select/poll a v nejjednodušším případě se s ním pracuje v jednom vlákně. Dále také tak trochu předpokládám neblokující sockety.

Aby to dobře fungovalo pro všechna spojení, tak musí být obsluha rychlá a neblokující.

V každém trochu složitějším případě je práce v epoll smyčce řízená nějakým stavovým automatem. Např SSL_read může požadovat opakované volání (s návratem z volané funkce až k epoll s požadavkem na čekání až bude socket připraven na čtení nebo zápis) dokud není ssl spojení kompletně navázáno.
Podobně také může být třeba se opakovaně vracet až k epoll pokud třeba není vyčten celý příchozí povel atp.(záleží na protokolu).

Pokud se pracuje s jinými prostředky (např ty soubory, db, ..)  tak také nechcete brzdit epoll smyčku synchroním voláním. Např v tom vašem příkladu jste operaci ukládání na disk odsunul do samostatného vlákna, ale tím jste si přidal práci s frontou, předáváním dat mezi vlákny atp. Co když potřebujete předat zprávu zpět z toho externího vlákna? Vrátíte zrávu zpět do epoll vlákna, nebo si budete socket pollovat ve worker threadu?
Věci se mohou začít kompikovat pokud si nedáte pozor, nebo pokud je protokol složitější, případně uchovává složitější stav.

Souhrn:
- V hlavní smyčce nesmí být synchroní/dlouhotrvající operace
- stavové automaty, pokud si nedáte pozor mohou být peklo.
- prakticky nutnost předávání dat mezi vlákny - potenciální problém
- řízení uvolňování zdrojů, a předávání zpráv o chybách mezi vlákny a stavovými automaty může být problém.
+- Trochu to nutí programátora si aplikaci rozdělit
- škálování do více vláken může být problém (pro každou databázi/disk/... jedno vlákno)?

Pokud je úloha jednoduchá, může být řešení s epoll krásně přehledné, v opačném případě je třeba uvážlivě členit aplikaci.

Tak a teď ohledně async/await  (z pohledu c#)
Je to sice trochu složitější, ale dá se na to koukat jako na ten stavový automat co se používá u epollu.

Takové await se pak jakoby vrací z funkce do hlavního loopu (podobně jako by se vracelo k epollu) a "vrátí" se až když jsou data dostupná (např načtena dat přes socket) nebo pokud vznikla chyba.
Akorát je to implementováno trochu chytřeji, a neomezuje jen na sockety a async await je možný třeba i při přístupu k disku, databázi, nebo je možné snadno vrstvit třeba protokoly (TCP/IP + SSL + HTTP)
Trochu neplechu může vyvolat pokud se do práce vloží více vláken z ThreadPoolu, je třeba si pohlídat ConfigureAwait.
Ale s trochou zkušeností stačí dodržovat pár základních pravidel (podobně jako musíte dodržovat proavidla při tvorbě stavových automatů pro epoll).

S tím také trochu souvisí pravidlo, že pokud se používá async/await tak všechen (potenciálně blokující) kód by měl používat async/await, v extrémním případě spustit "blokující" kód v threadpoolu.
Navíc je nutné(pokud si nechcete zahrávat s deadlocky) používat await celou cestu vzhůru, a awaitovat výsledek namísto blokujícího task.Result a podobně.(což zjednodušeně znamený že i první funkce na stakcu měla být async, například main)
To je důvod proč možná narážíte na to že někdo "zbytečně" používá async/await.
Když se nad tím zamyslíte, tak je to vlastně logické, synchroní kód v hlavní "smyčce" blokuje provádění ostatních "Tasků" (ačkoliv zde je to trochu složitější, a špatný kód může "občas/často" fungovat nebo nefungovat kvůli připadnému provádění nebo neprovádění tasků v různých vláknech).

Souhrn:
- V hlavní smyčce nesmí být synchroní/dlouhotrvající operace
+ umí jednoduše asynchroně pracovat i s dalšími prostředky (soubory, připojení k databázi, uživatelské funkce používající async,..), ne jenom se sockety, to třeba umožňuje pěkně zapouzdřit komunikační protokol atd.
+ stavový automat za vás vygeneruje překladač (ačkoliv je dobré to tušit kvůli úspoře prostředků)
+- koncept async/await umožňuje v některých případech vyhnout se explicitnímu vytváření vláken úplně.
+- řízení uvolňování zdrojů, a předávání zpráv o chybách - celkem jednoduché jako v "synchroním" kódu, pokud
explicitně nepředáváte do workerthreadů zprávy jako v prvnímpřípadě.
+škálování do více vláken nemusí být problém
- Pokud nedodržíte základní pravidla (jako např. async/await all the way up, a pohlídat si ConfigureAwait) může kód fungovat díky shodě náhod a použitému synchronizačnímu kontextu(věc z C#).
- Pokud se věci zpracovávají na Threadpollu, je třeba si uvědomit že není nekonečný :)
- může být nutno explicině přiškrtit některé operace (což v předhozím případě mohl zajišťovat worker thread)
+ Stále je možno používat worker thready jako v předchozím případě, pokud to dává smysl.

Pro jednoduchou aplikaci, je to jednoduché, pro složitější trochu víc, ale víceméně to vypadá jako synchroní kód(s tím že je vidět kde stavový automat může navrátit řízení do "hlavní smyčky".
Pro oba případy je ale třeba dodržet základní pravidla.

15
Vývoj / Re:Jak se chránit pro XSS útoku na php serveru?
« kdy: 12. 10. 2019, 14:00:18 »
Při prezentaci je zase nutné předat data do HTML, proto se obvykle používá funkce htmlspecialchars(). Z mého pohledu je poněkud zastaralá - PHP nabízí lepší, objektové řešení, u kterého už nemusím přemýšlet nad typem eskejpování v daném kontextu.
Myslíš jako pomocí DOMDocument? nebo něco jiného?
Ideálně prosím dej nějaký příklad kde se to používá.

Ano, mám na mysli DOMDocument. Vyleze z toho hotové XML či HTML, kde jsou potenciálně nebezpečné znaky řádně transformovány do entit.
DOMDocument je možná bezpečnější, ale to "lepší" se mi moc nezdá (spotřeba paměi,výkon,nutnost kompletního DOMu před odesláním na clienta).
Navíc transformace DOMu se dost liší od běžného použití php jako preprocesoru. To už mi přijde "lepší" použít nějaký framework, než toto.Ale to už jsme mimo téma.

Stran: [1] 2 3 4