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 - Ondrej Nemecek

Stran: 1 ... 22 23 [24] 25 26 ... 90
346
Asi bych to spustil ve screen. Je to jednoduchý a k tomu určený nástroj.

Vysvětlení & disown a nohup viz https://unix.stackexchange.com/a/148698

347
Vývoj / Re:PHP MySQL vs MSSQL
« kdy: 06. 11. 2020, 16:24:22 »
V PHP doporučuju použít PDO, pak může být PHP kód stejný pro všechny databáze. SQL dotazy se budou muset mírně upravit dle databáze, pomůže pokud jsou všechny SQL konzistentně na jednom místě.

348
Software / Re:GIMP a změna barvy na konkrétní barvu
« kdy: 05. 11. 2020, 14:04:12 »
AI a postscript většinou importuji do Inkscape bez problémů. Rozdíly bývají ve struktuře, poskládání vrstev apod. Při potřebe úprav se občas vyplatí vyplatí vyzkoušet nejvhodnější formát. Pro záměnu barvy je to asi skoro jedno.

349
Software / Re:GIMP a změna barvy na konkrétní barvu
« kdy: 05. 11. 2020, 00:51:45 »
Další možnost je otevřít ten obrázek v Inkscape, použít menu Křivka -> Vektorizovat Bitmapu.

Získáte vektorovou podobu, kterou pak vyplňujete barvou a máte přesné a plynulé okraje objektu.

U grafiky, co jste uvedl jako příklad, to bude asi vhodnější postup.

Vedlejším efektem je možnost libovolného škálování při zpětném exportu do JPG, PNG a další benefity vektorového formátu.

350
Vývoj / Re:Kotlin nebo Scala pro backend?
« kdy: 04. 11. 2020, 15:59:38 »
Java má pitomá a neintuitivní generika a na cokoli trochu zavánějící pozdní vazbou se musí použít reflexe, i když by de fakto stačila interface. To jsou podle mě největší bolesti javy.

351
Vývoj / Re:PHP SQL spočítání řádků za posledí hodinu
« kdy: 02. 11. 2020, 21:51:56 »
Minuty a sekundy můžete odříznout pomocí DATE_FORMAT. Takže:
Kód: [Vybrat]
-- date >= start AND date < end:

SELECT count(*) AS cnt
FROM log WHERE
date >= CONVERT(DATE_FORMAT(NOW(),'%Y-%m-%d %H:00:00'), DATETIME)
date <  CONVERT(DATE_FORMAT(DATE_ADD(NOW(),INTERVAL 1 HOUR),'%Y-%m-%d %H:00:00'), DATETIME);

Nebo úspornější zápis:
Kód: [Vybrat]
-- date BETWEEN start AND end:

SELECT count(*) AS cnt
FROM log WHERE
date
BETWEEN CONVERT(DATE_FORMAT(NOW(),'%Y-%m-%d %H:00:00'), DATETIME)
AND CONVERT(DATE_FORMAT(DATE_ADD(NOW(),INTERVAL 1 HOUR),'%Y-%m-%d %H:00:00'), DATETIME);

V Mysql je pro CONVERT výchozí DATETIME formát 'YYYY-MM-DD HH:MM:SS', takže pokud použijete tento formát, nemusíte používat STR_TO_DATE() ale stačí CONVERT. On ani ten CONVERT není asi potřeba, jelikož se zavolá implicitně.

352
Zkusit jiný prohlížeč?

353
Seznam příjemců lze mít uložený jako skupinovou adresu. Pokud budete mít skupinu porada pak do příjemce napíšete porada a příjemci se sami doplní. Ale subjekt a tělo mailu to nedoplní. Podíval bych se na rozšíření Thundebirdu, subjekt i tělo lze snadno zakódovat do mailto: protokolu, takže je možné, že nějaké rozšíření na to bude. Anebo použít šablonu, to je asi běžnější řešení.

Co se týče pozvánek na události, můžete také řešit pomocí nějakého plánovacího kalendáře s podporou posílání notifikací.

354
Sítě / Re:Nákup Wi-Fi AP s PoE
« kdy: 23. 10. 2020, 16:52:10 »
Čemu říkáte roaming? Pokud bude všude stejné SSID, měl by roaming fungovat automaticky. Takže v případě wifi v bridge režimu a s centrálním dhcp chodíte kam chcete a zařízení se připojují samy kam uznají za vhodné a mají stále stejnou IP. Nevýhoda je, že se připojují k AP dle vlastního uvážení (lze ovlivnit nastavením agresivity roamingu - občas to lze na klientovi nastavit).

Jinak základem je mít AP na patro a mít je umístěné centrálně v budově (resp. centrálně k místům užití wifi) a zohlednit vliv stavebních materiálů (železobeton, AL fólie... - IMHO nejlepší je to manuálně vyzkoušet). Dále použít vzájemně se nerušící kanály (je nutno proskenovat rušení jinými AP). Pokud se ta AP umí vzájemně domluvit, je to výhoda - to je plus pro hotová řešení, které by měla tyto problémy řešit jaksi integrovaně (Ubiquity). Ale nemá cenu si myslet, že pojede vše na 100% teoretické rychlosti. Se systémem MESH nemám zkušenost, ale pro rodinný dům mi to přijde kanón na vrabce. V nezarušeném prostředí se podle dá rodinný dům řešit slušně i nízkorozpočtově, zejména pokud se člověk vyhne nesmyslům jako různým 220V extenderům a pokud má ethernetovou páteř. Co má velký význam je umístění těch AP (s ohledem na vyzařovací charakteristiky), což je často největší oříšek vzhledem k možnostem domu (náročnost úprav nutných k umístění).

POE se dá řešit i POE injectorem.

355
Desktop / Re:Android pre desktop
« kdy: 22. 10. 2020, 22:39:00 »
Já příležitostně používám taky Android-x86. Výhodu vidím v tom, že to je stabilní a kontinuálně vyvíjený projekt (poslední release 2020-05-20).

356
Software / Re:Nástroj pro práci s json/yaml
« kdy: 21. 10. 2020, 16:12:58 »
Hodí se vědět, že webové prohlížeče mají dnes prohlížeč json (třeba ve Firefoxu stačí otevřít json soubor a vidíte stromová data v nichž můžete i vyhledávat).

Pro primitivní porovnání se nabízí json normalizovat a pak porovnat textově např. pomocí meld, diff, colordiff...

357
Vývoj / Re:PHP + mysqli blbne v xubuntu focal
« kdy: 19. 10. 2020, 18:19:15 »
Použijte prepared statements, mysqli to umí, PDO taky. Počet řádků - záleží, na co to potřebujete, ale asi bych použil
Kód: [Vybrat]
SELECT count(*) AS count FROM table;
a vytáhnul si hodnotu count z výsledku.

358
Software / Re:Jiný kancelářský balík
« kdy: 18. 10. 2020, 23:54:06 »
Já té otázce rozumím...

tak jistě že lze s daty praccovat jinak než v textu (s pokusem o typografii), tabulce a prezentaci.

Můžete mít třeba mindmapu nebo nějak jinak prezentovaný graf. Hezký přístup měl původní operační systém Palmu, kde všechna data všech aplikací byly položky databáze s jednotnými metadaty, takže se daly položky z jedné aplikace bez problémů linkovat (odkazovat) v datech jiné aplikace...

Problém s těmito přístupy je že uživatelé jsou velmi konzervativní (uživatelé Linuxu taky i když si myslí že ne, většinu chtějí to samé jenomže jinak a "svobodně") a když se chytlo paradigma dokument-tabulka-prezentace a oni se ho nějak naučili nemají důvod to zkoušet jinak. "Kancelářský balík" je pro ně jenom nástroj který by po nich měl chtít co nejméně. Navíc většina lidí není schopná přílišné abstrakce, takže potřebují wysiwyg.

Tak to bych chtěl vidět, jak chcete data o třeba 8 sloupcích a 10t-20t řádcích zpracovávat formou mindmapy, nemluvě o nějakých funkcích a filtrech na nich :). Mindmapa a graf je až výsledek, prezentace to co z dat vydolujete. Btw. s mindmapami jsem se seznámil na VŠ ale popravdě mi to přijde jako taková pěkná neužitečnost typu brainstormingu. Když už chcete udělat cool prezentaci, dobré je třeba prezi.com nebo nějaká dobře zpracovaná infografika (pokud to nemá být live prezentace).

Jak už jsem psal výše, silně pochybuji o tom, že je to konzervativismem lidí, ale tím, že postupů k vytvoření něčeho je hodně, ale jen několik jich nejsou úplné kraviny.

Data o 8 sloupcích a 20k řádcích nepatří do mindmapy, textového procesoru ani do tabulového procesoru, ale do databáze. Mindmapy jsou naopak pomůckou pro vytváření vazeb mezi znalostmi. Generování mindmap je ze své podstaty nesmyslem.

Mindmapy jsou užitečné a běžně je používám pro osobní potřebu. Je třeba začít vždy uprostřed stránky papíru a je dobré používat pastelky nebo barevné fixy. K prezentaci jsou vhodné pouze v případě, že během ní vznikají.

Přesně tak, mindmapa je alternativa k ERD diagramu, nikoli k tabulkovým datům tím ERD diagramem popsaných...

S textovými daty má IMHO často smysl pracovat strukturovaně a až na konci celého workflow z nich mít nějaký výstup.

Myslím, že pro běžného uživatele by to nepřestavovalo velký problém, pokud by byl kancelářský balík v daném přístupu jednoznačný a konzistentní.

Bohužel, pod mantrou WYSIWYG se to celé zamotalo a zkomplikovalo i z pohledu běžných uživatelů. Tristní schopnost ovládat kancelářský balík většiny uživatelů to výmluvně dokládá.

359
Software / Re:Jiný kancelářský balík
« kdy: 17. 10. 2020, 00:09:28 »
Kancelářský balík je určen pro průměrného uživatele, proto jeho paradigma dost konzervativní a funkčně nedokonalé. Dokážu si představit jiné paradigma, ale nedokážu si představit, že by se to v dohledné době stalo mainstreamem.

Je obtížné udělat i systém pro kvalitní typografický výstup, natož nabalit na to další workflow pro zpracování dokumentů. Asi to naráží z jedné straně na komplexnost úlohy a z druhé strany na limity a špatné návyky uživatelů.

Typický problém začíná už u přípravy textu a korektur. Stojí dost práce, než je text vůbec způsobilý k sazbě, problém jsou dodatečné korektury, nedokonalé je sdílení textu mezi více autory a systém revizí je nedomrlý, opakované použití textu pro různé účely s automatickou distribucí změn je utopie, použití stylů vágní a nepraktické. Možná něco z toho kancelářské balíky do určité míry umožňují, ale minimum lidí s tím v běžné praxi umí pracovat a mám pochybnosti i o tom, jak kvalitně to je implementované.

Jinými slovy, líbil by se mi nástroj na sémantickou práci se strukturovaným textem, s podporou verzování, sdílení, automatickou distribucí korektur a s možností napojit na různé další workflow a použití textu, ale nic takového neznám, mimo specializovaných řešení pro specifické použití (docbook, TeX, IDE pro programovací jazyky). Podobně to vidím u databází a tabulkových procesorů.

Stran: 1 ... 22 23 [24] 25 26 ... 90