391
Vývoj / Re:PHP SRV_SQL charset vracia zle enkodovane znaky
« kdy: 07. 12. 2020, 21:46:01 »MySQL není moje doména
Bacha, tady jde o MS SQL, a podle prvotního popisu je Slovak_CI_AS nastavené správně.
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.
Bacha, tady jde o MS SQL, a podle prvotního popisu je Slovak_CI_AS nastavené správně.
392
Server / Re:Automatizace nasazení na sdílený webhosting
« kdy: 07. 12. 2020, 15:46:26 »
Já bych na to použil existující službu a netříštil bych na této činnosti moc síly. Viz např. deployhq.com. Stáhne si aktuální (nebo vybraný) commit, provede potřebné příkazy (composer, npm/yarn, ...) a soubory, které se liší od posledního deploy to nahraje pomocí FTP/SSH a kdoví čeho ještě na server. Nastaveno během asi 15 minut.
393
Distribuce / Re:Proxy přístup na internetové repozitáře
« kdy: 04. 12. 2020, 07:01:26 »Tak pouzij socks5 proxy.
Proboha proč? To už je díra jak vrata.
Podle mě se dá nasazování na server udělat bez toho, aby na serveru vůbec byl nainstalovaný git a další nástroje a přístup ven na internet.
Podle mě je škoda, když si někdo dal práci, aby to odizoloval, to ničit.
394
/dev/null / Re:Zrušená objednávka směle míří ke mně
« kdy: 04. 12. 2020, 06:58:56 »
Neobjednané plnění - toto ustanovení se týká dárků zdarma, nebo toho, když Vám prodejce k telefonu pošle štangli salámu. Ustanovení slouží k tomu, aby při odstoupení od smlouvy nemohl salám požadovat zpět. Taky se tím předchází tomu, aby prodejce nezaslal další zboží s tím, že "jestli ho nechcete, tak ho vraťte - pokud si ho necháte, tak ho ale zaplaťte".
To, co popisujete, že nastalo, je bezdůvodné obohacení.
To, co popisujete, že nastalo, je bezdůvodné obohacení.
395
Distribuce / Re:Proxy přístup na internetové repozitáře
« kdy: 03. 12. 2020, 21:14:26 »
No, pokud je na serverech vypnutý přístup na internet, většinou to má dobrý důvod a naopak není důvod to porušovat.
Přístup do repozitářů a vývojové nástroje bych na server nedával.
Obvykle se projekt sestaví a teprve výsledek se deployuje na server. Na to stačí push přes SFTP, SCP atp.
Přístup do repozitářů a vývojové nástroje bych na server nedával.
Obvykle se projekt sestaví a teprve výsledek se deployuje na server. Na to stačí push přes SFTP, SCP atp.
396
Vývoj / Re:SQL JOIN priradene stlpca podla ID
« kdy: 11. 11. 2020, 13:32:11 »
No nejdřív si spojte související události start-stop k sobě. Cílem je "tabulka", ve které bude na jednom řádku spolu související start a stop.
Pak si potřebujete doplnit "sloupec", který z timestampu udělá jen obyčejný date. Samozřejmě, že si musíte určit, jestli je rozhodný den startu, nebo stopu. Můžete si doplnit ještě vypočtenou dobu mezi startem a stopem.
Pokud tyto data máte, osobně bych si je vystavěl jako VIEW.
Nad tím view pak můžete pomocí WHERE omezit datum a pomocí sum, count sečíst časy nebo spočítat četnost a pomocí GROUP BY určit, jestli je to po dnech, dekádách, pětiletkách
.
Pak si potřebujete doplnit "sloupec", který z timestampu udělá jen obyčejný date. Samozřejmě, že si musíte určit, jestli je rozhodný den startu, nebo stopu. Můžete si doplnit ještě vypočtenou dobu mezi startem a stopem.
Pokud tyto data máte, osobně bych si je vystavěl jako VIEW.
Nad tím view pak můžete pomocí WHERE omezit datum a pomocí sum, count sečíst časy nebo spočítat četnost a pomocí GROUP BY určit, jestli je to po dnech, dekádách, pětiletkách
.
397
Vývoj / Re:SQL JOIN priradene stlpca podla ID
« kdy: 11. 11. 2020, 13:13:36 »
Nepoužívám mysql, protože má dost omezené možnosti (mysql nazývám parodií na SQL databáze).
Ale obecně to samozřejmě lze v SQL řešit a je správně to řešit.
Řešení existuje víc, neumím pochopit z popisu, jestli je to vždy:
START
STOP
START
STOP
START
STOP
nebo jestli může nastat situace:
START
STOP
STOP
STOP
START
STOP
STOP
START
STOP
Podle toho se pak v SQL (a taky podle schopností databáze) liší řešení.
Jedním z možných řešení je využít subselecty:
V PostgreSQL by se to řešilo pomocí
Lze to pravděpodobně řešit i JOINEM, jak jste psal. Tam pak záleží na tom, jak jsou data uspořádaná. Pomocí WHERE a DISTINCT ON zle vyfiltrovat a setřídit data tak, aby se ke každému startu našel nejbližší stop, nebo všechny související stopy.
Osobně si myslím, ale opravdu nejsem znalý, že je to přes schopnosti MySQL.
Určitě je správné to řešit na úrovni SQL, řešit to v PHP je prasárna. Do PHP byste si musel natáhnout spoustu dat a v jeho pomalém kódu řešit filtrování. Když to ponecháte na SQL, má databáze možnost dotaz optimalizovat (značná úspora času) a navrátit Vám jen data, která žádáte.
Za dotaz, jestli můžu, tak chválím. Většinou to prasátka napíší v PHP a ani je nenapadne, že by přesně tyto operace mělo řešit SQL, že od toho je.
Ale obecně to samozřejmě lze v SQL řešit a je správně to řešit.
Řešení existuje víc, neumím pochopit z popisu, jestli je to vždy:
START
STOP
START
STOP
START
STOP
nebo jestli může nastat situace:
START
STOP
STOP
STOP
START
STOP
STOP
START
STOP
Podle toho se pak v SQL (a taky podle schopností databáze) liší řešení.
Jedním z možných řešení je využít subselecty:
Kód: [Vybrat]
SELECT
[sloupce],
(SELECT ...nejbližší_stop... FROM [tabulka_stopů] WHERE [vodné podmínky])
FROM
[tabulka_startů]V PostgreSQL by se to řešilo pomocí
Kód: [Vybrat]
JOIN LATERALLze to pravděpodobně řešit i JOINEM, jak jste psal. Tam pak záleží na tom, jak jsou data uspořádaná. Pomocí WHERE a DISTINCT ON zle vyfiltrovat a setřídit data tak, aby se ke každému startu našel nejbližší stop, nebo všechny související stopy.
Osobně si myslím, ale opravdu nejsem znalý, že je to přes schopnosti MySQL.
Určitě je správné to řešit na úrovni SQL, řešit to v PHP je prasárna. Do PHP byste si musel natáhnout spoustu dat a v jeho pomalém kódu řešit filtrování. Když to ponecháte na SQL, má databáze možnost dotaz optimalizovat (značná úspora času) a navrátit Vám jen data, která žádáte.
Za dotaz, jestli můžu, tak chválím. Většinou to prasátka napíší v PHP a ani je nenapadne, že by přesně tyto operace mělo řešit SQL, že od toho je.
398
Hardware / Re:Monitor od Dellu (řada P) - mrtvý pixel
« kdy: 10. 11. 2020, 14:18:36 »Moc děkuji za vaší pomoc.
Nelze říct, nikdo neusleduje výrobce, jak stále mění sortiment.
Osobně bych se na ně šel podívat, vzal bych si nějaké testovací obrázky (třeba i screenshoty pracovní plochy) a sledoval bych, co mi na oči sedí nejvíc při různých jasech (v krámě mají vše nastaveno snad na 120 %). Mně třeba hodně vadí nehomogenita plochy - asi nejlíp se pozná na našedivělých plochách á la pozadí oken. Ale každé oko je jiné a jinak shovívavé k různým nedokonalostem.
399
Hardware / Re:Monitor od Dellu (řada P) - mrtvý pixel
« kdy: 10. 11. 2020, 13:15:06 »Pokud bych monitor vrátil a koupil třeba z Alzy, také žel nemám jistotu, že to bude v pořádku.
Podle mě se to zas tak často nestává, není velké riziko, že další monitor bude mít zase vadu.
Jen počítej, že pokud se to vyskytne později, není to důvod k reklamaci - pokud to nepřekročí tu jejich specifikaci.
400
Hardware / Re:Monitor od Dellu (řada P) - mrtvý pixel
« kdy: 10. 11. 2020, 11:57:16 »Doporučil bys za podobnou cenu jiný monitor, který by za ty peníze opravdu stál? Měl jsem za to, že je to "profesionální" model. Samozřejmě, že do monitoru nemohu dát desetitisíce...
Co třeba Samsung U28R550?
Nechtěl jsem Tě urazit, určitě je to nadprůměrný monitor. Jen se mi zdálo, že se možná hněváš na Dell, že to mohli dopustit. Prostě se to může stát, a jak psal kolega výše, tak pokud je to na firmu, tak se to i blbě reklamuje. Takový servis se dá očekávat u grafických monitorů, nebo nakupovat na krámě a vyzkoušet si to.
Dell, Samsung vyrábějí taky dobré monitory. Mně na stůl nepáchne nic jiného, než EIZO, ale tam je prostě cena jiná. Jde o to, jestli řešíš barevné podání. Pokud ano, pak nezbývá moc možností. LED podsvícení je monochromatické a nabarvit bod správně není úplně lehké, navíc když luminifory mění stářím svoje charakteristiky.
Samsung U28R550 má proti tomu Dellu zase jiné nevýhody. Menší jas. Ale má zas 10bit zpracování barev. (Nezapomeň, že na to potřebuješ grafiku, která umí 10bit nakrmit). Myslím, že Dell vs. Samsung bude už o tom, co se Ti líbí víc. Oba budou mít kompromisy, ale každý trochu jiného typu.
Doporučil bych, jestli máš možnost monitor vyměnit, tak vyměň. Zhaslý bod Tě bude štvát celou dobu
.
401
Hardware / Re:Monitor od Dellu (řada P) - mrtvý pixel
« kdy: 10. 11. 2020, 11:03:04 »
Na vadné pixely jsou normy uvedené výrobcem a v rámci nich ten monitor kupujete.
Osobně bych ho vyměnil ve 14denní lhůtě, pokud máte takovou možnost.
Dell P2720DC není profesionální monitor, je to o něco lepší a dražší kancelářský model (s tradiční kancelářskou 8bitovou hloubkou), takže bych byl určitě shovívavý, stát se to může každému výrobci.
Osobně bych ho vyměnil ve 14denní lhůtě, pokud máte takovou možnost.
Dell P2720DC není profesionální monitor, je to o něco lepší a dražší kancelářský model (s tradiční kancelářskou 8bitovou hloubkou), takže bych byl určitě shovívavý, stát se to může každému výrobci.
402
Server / Re:Zbavit se Googlu?
« kdy: 09. 11. 2020, 11:46:57 »Tak existují veřejné blacklisty pro SPAM®.
Hehe, a s nimi jako nejsou žádné problémy, žádná starost?
GMail je zdarma, tak kdo ví kde ty ode mne berou.
GMail je zdarma leda tak ve své okleštěné podobě. Když jste se ptal, jestli raději variantu vlastního serveru, je jasné, že byste musel mít vlastní doménu.
Takže otázka pravděpodobně nezní, jestli vlastní server, ale jestli mít e-mail na @gmail.com, nebo @vlastní-doména.tld. Tam je jednoznačná odpověď - pro nezávislost je lepší mít mailovou doménu vlastní.
Nijak se to ale nevylučuje, abyste ji měl obhospodařovanou Googlem (gmail.com), nebo třeba Microsoftem. Tam už bych já osobně raději platil těch pár fufníků, co za to chtějí, než se staral o celý vlastní mailserver.
403
Server / Re:Zbavit se Googlu?
« kdy: 09. 11. 2020, 11:24:54 »Do cloudu moc chodit nechci. Nemám moc rád "black box" řešení. Tady spíše jde o jestli se mi ta práce vyplatí.
Ale to je pořád dokola to slovo "vyplatí". Co to znamená? Já mám serverů k dispozici hodně, ale část služeb mám v cloudu nebo u velkých poskytovatelů a jsem přesvědčený, že se mi to "vyplatí". Mám zákazníky, kteří si to přejí jinak, a taky jsou přesvědčení, že se jim to "vyplatí".
Můj pohled je z úhlu jediného neškálovatelného prostředku, který mám k dispozici: času. Kdybych neměl co na práci, tak si klidně udělám vlastní mailserver, budu si ladit pravidla, průběžně antispam, řešit viry, ... Když čas nemám, jsem rád, že se mi o to někdo za rozumný bakšiš postará.
S IT je to jako s jídlem. Můžete si vařit, můžete kupovat polotovary a můžete chodit do restaurace. Můžete být mlsný, nebo skromný.
Jak chcete, aby Vám někdo viděl do hlavy?
404
Server / Re:Zbavit se Googlu?
« kdy: 09. 11. 2020, 10:06:31 »Zálohu těch klíčů mám asi na 4 různých mistech, takže to záloha je.
A data zálohovaná máte?
Spíše mířím na to, jestli se mi vyplatí selfhost.
Nevím, čemu říkáte "vyplatí". Finančně, a kvalitou služeb se to "nevyplatí". Z pohledu nezávislosti se to "vyplatí".
Osobně se k tomu stavím tak, že současné služby, které za něco stojí, čerpám. Jsem ale v nějakém částečném střehu, že se situace může změnit a v takovou chvíli jsem připraven si poradit jinak.
Každopádně data v cloudu nemáte v žádném bezpečí. Nic Vám negarantují, nic Vám nenahradí. Naopak nad cloud se staví zálohování nezávisle. Obvykle je vstup do cloudu poměrně levný, ale když započtete tyto "vedleší" činnosti, tak náklady +/- srovnají s on-premise řešením.
405
Sítě / Re:Mikrotik a OpenVPN?
« kdy: 01. 11. 2020, 21:27:33 »Na Windows jde spustit i OpenVPN server, ne? Bych udělal ten.
Vcelku ne dobrý, ba přímo hloupý, nápad vystavovat firemní Windows server přímo do internetu. Ale každého volba
Ono záleží na okolnostech.
Každopádně je pitomina utíkat k OpenVPN nebo Wireguardu, pokud obě strany podporují něco standardního. Např. IKEv2. Dobře funguje i SSTP.
Pokud jsou oba konce pevné, tak bych neuvažoval o ničem jiném než o GRE a IPsec.
Mimochodem, pokud má OpenVPN smysl, tak možná na vyhnilých linkách, kde se naopak hodí TCP režim, který má Mikrotik. Spousta lidí za to Mikrotik kritizuje, ale podle mě neprávem. Na dobré linky existují lepší volby, a na špatné je tu právě OpenVPN.
