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 ... 5
1
Vývoj / Re:Alternativa za Excel Visual Basic?
« kdy: 22. 11. 2022, 08:45:42 »
Pokud je třeba opravdu programovat (např GUI klikátka, in place modifikace atp), tak bych se tomu asi vyhnul a udělal normální program mimo excel.
Větší věci (s pár jsem se uživatelsky setkal) mají tendenci se rozbíjet přo aktualizacích.

Pokud by stačila transformace - to co je v prvním příspěvku (nahradit hodnoty ve sloupci nulou pokud absolutní hodnota je menší než 0.1) by se dalo udělat v powerquery který je  součástí excelu už pár let.
Není to ale vb/vba programování, spíš je to trochu podobné sql dotazování - místo modifikace tabulky v místě, jde vlastně o dotaz který je směrován do své vlastní tabulky, kterou ale lze aktualizovat, podobně jako kontingenční tabulka.
A powerquery toho umí ještě mnohem víc (externí soubory/databáze spojování tabulek,....)

2
Ahoj,
Nejsem úplně expert ale pár zkušeností s EFS mám takže pár rad:
Klíč určitě pro jistotu zálohovat!
EFS je pro šifrování jednotlivých souborů(narozdíl od bitlockeru, který šifruje celé oddíly) a windows požaduje zálohu když je klíč vytvořen a není zálohován.
Takže nějaké soubory nejspíše šifrovány jsou nebo byli.
Seznam EFS šifrovaných souborů lze získat programem cipher.exe:
cipher /u /n /h > %UserProfile%\Desktop\EFS_EncryptedFiles.txt
Hledá to ale jen na lokálních jednotkách, pokud bylo něco zašifrováno na USB nebo síťovém úložišti tak to nejspíš nenajde. Stejně tak pokud už došlo ke smazání toho šifrovaného souboru.

3
Vývoj / Re:localtime a (ne)tvorba nových dát v pamäti
« kdy: 26. 07. 2021, 19:20:07 »
https://linux.die.net/man/3/localtime
https://www.cplusplus.com/reference/ctime/localtime/

Protože standardní localtime/gmtime/... používají nějakou vnitřní sdílenou strukturu, tak to není zrovna bezpečné
Možná je lepší se rovnou pohlédnout po jiných funkcích např localtime_r (ale jukněte do dokumentace), obzvlášť pokud jedete s více vlákny.
A k malloc není důvod, stačí normálně zkopírovat přiřazením.
Kód: [Vybrat]
struct {
  struct tm time1; 
  struct tm time2;
} Item;
Item.time1=*localtime(&rawtime);
localtime_r(&rawtime,&Item.time2);


4
Sítě / Re:UTP kabel z routeru do patch panelu nebo do switche
« kdy: 19. 07. 2021, 10:42:39 »
Modem/router se switchem bych propojil patchkabelem napřímo  - ale pěkně vyvázat ať tam není pavučina :) .

Do patch panelu (podle mne) patří ukončit kabely které mají uvnitř plný drát (nikoliv lanko jako mají tzv patchkabely).
Je to proto že ty dráty se při pohybu, obzvlášť pokud jsou starší, mohou zlomit a pak to dělá neplechu.
Tyhle dráty se používají většinou právě do stěn atd protože je to levnější, a ve stěnách se to obvykle moc nehýbe. Je ale třeba je ukončit zásuvkou nebo patch panelem. Použít je na volno, si říká o průšvih.

Naproti tomu patchkabely mají uvnitř místo plných drátů lanka, takže na lámání tolik netrpí, a vzhledem k tomu že se dávají do míst dobře dostupných, tak ani případná výměna tolik nebolí. A vzhledm k obvykle malé délce ani tolik nevadí že jsou dražší.

I na drátové kabely lze samozřejmně dát přímo rj45 koncovky a použít přímo.
Ale v tom případě se dejte alespoň pozor na to že pro drát  a lanko jsou trochu různé koncovky a samozřejmně počítejte že to za pár let nejspíš odejde. Navíc se to pak chová spíš divně/chaoticky, než že by to prostě přestalo fungovat). To mi připomíná že už bych ten jeden co mám takhle doma měl doma taky vyměnit :), bo to blbne.

5
Hardware / Re:HDD do desktopu WD Black nebo Red Pro
« kdy: 08. 06. 2021, 14:27:31 »
Pokud je to určeno pro NAS, tedy do nějakého RAID pole, tak jako samostatný disk pro desktop bych to nepoužíval.

"NAS" disky mají ve zvyku hlásit případnou chybu poměrně rychle, protože se spoléhá na RAID že si s tím poradí, a že data dopočte nebo najde na jiném disku, a tak není žádoucí to zbytečně zdržovat.

Kdežto běžné desktopové disky, se snaží poměrně dlouho aby data vyčetli, což sice může způsobovat takové ty jakoby několikavteřinové záseky, ale protože se nepočítá s tím že je nad tím raid nebo nějaká další opravná vrstva, tak je to rozdíl mezi tím jestli to skončí čtením chybou(a potenciálně to shodí systém třeba), nebo chvílí čekání a také možností potenciální záchraně dat.

Pokud to ale bude v tom desktopu v odpovídajícím raidu, tak by to vadit nemuselo.

6
Server / Re:Databáze - 300 GB tabulka
« kdy: 15. 03. 2021, 10:21:36 »
Hoj, podobné tabulky jsem měl v firebirdu a celkem pohoda, dokonce i sqlite si vedla dobře akorát tenkrát neměla nějaké window funkce nebo co tak jsem to tak moc netunil. Ale očekával bych že to postgres také zvládne rozumně.

Zde jsou zpomalovače, víceméně v pořadí důležitosti a jak je obejít
  • Pomalost transakce/commit - ručně řídit transakce a dělat commit po x řádkách (já jsem měl dobré výsledky s 50tisíc řádek)
  • Vyloučení duplicitních položek - použít Merge nebo nějakou formu "Insert or ignore" která umí použít index. A samozřejmně mít na to správný index, kde se nemusí moc šahat na podkladová data. (bez tohoto se po pár desítkách tisíc zadýchá kterákoliv db)
  • Roundtrip k databázi - předem připravený prepared parametrized multi insert nebo stored procedura. Tj jedním execute vložit třeba 25 řádků
  • Aktualizace indexu - tady (někdy) pomůže temporary tabulka(pokud je pouze v ram) bez indexů do které se nejdříve naleje třeba 50tisíc řádek, a pak se jedním povelem vloží do Hlavní tabulky s indexem.
    Zkontrolovat že se temp tabulka vejde do paměti!!
    Ale třeba sqlite byla myslím rychlejší při vkládání napřímo.
  • Aktualizace indexu II - pokud je to možné tak zpracovávat data v pořadí v jakém do tabulky(indexu) patří. Např u mne to bylo si nejdříve seřadit soubory podle datumu(v názvu souboru) a pak je v tom pořadí zpracovávat a vkládat do databáze.
Případně potunit paměť pro indexy, ale moc bych to nepřeháněl.
Nějaký další fine-tununing byl tak desítka procent odhadem, ale juž je to dávno.

7
Vývoj / Re:git --graph, různá repo, různé chování ...
« kdy: 04. 02. 2021, 20:30:40 »
Git skládá konfigurace z více souborů, takže na aktuální konfiguraci těch projektů koukněte pomocí "git config --list". Popřípadě pomocí "git config --list --show-origin" lze pak vidět odkud která volba pochází.

Hádám že by rozdíl mohl být v branch.<name>.mergeOptions  (viz man git config)

Popřípadě taky zkuste git version, jestli nejsou ty verze nějak moc odlišné a pak jedině prohledat releasenoty jestli se nezměnill default nějaké volby.

8
Trochu střelba od boku, ale při startu počítače bez připojeného monitoru je možná rozlišení plochy v čase spuštění aplikace jiné než čekáte. A možná se to rozlišení změní až při připojení monitoru.
Dříve snad byly nějaké podobné problémy s VNC na stroj bez připojeného monitoru, ale už je to dost dávno.
Zkuste si přidat logování, a případně reagovat na eventy změny rozlišení.

9
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,...)

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

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

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

13
/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)

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

15
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/

Stran: [1] 2 3 ... 5