Příspěvky

541

Distribuce / Re:Dvakrát mountnutý stejný disk

« kdy: 19. 12. 2019, 15:52:56 »

Stručně řečeno se bindem mountuje adresář do adresáře.

542

Vývoj / Re:Ukládání různých typů produktů do databáze

« kdy: 19. 12. 2019, 15:52:23 »

Ledaskdo považuje EAV za antipattern. Řešilo se tu na fóru už několikrát. Zároveň platí, že alespoň jednou si každý EAV musí vyzkoušet. Podle mě je nejlepší použít NoSQL možnosti SQL databází - json nebo xml typy mají databáze indexované takže to je rychlé a současně se to dobře používá.

543

Odkladiště / Re:Proč SMART TV nepřehraje běžné mp4? (konkrétní video)

« kdy: 08. 12. 2019, 15:46:02 »

Porovnal bych funkční a nefunkční video - srovnejte výstupy mediainfo na jeden a druhý soubor. První co bych porovnal jsou audio a video kodeky. Pak kontejner. Pak rozlišení. Pak zbytek.

544

Software / Re:Thunderbird neumí uložit koncept v offline režimu?

« kdy: 08. 12. 2019, 15:40:51 »

Můžete si nastavit pro koncepty lokální složku, pak ale nebudete mít rozepsané zprávy dostupné online.

Zacyklení dialogů v popsané situaci je podle mě skutečně chybně navržená funkčnost a vadné GUI. Nikdy jsem z těch dialogů nepochopil, na co mám kliknout, abych o mail nepřišel. Osobně to řeším častým ukládáním rozepsané verze (CTRL+S). Přílohy přikládám až nakonec, takže je to průběžné ukládání docela rychlé.

545

Vývoj / Re:Návrh frontend/backend model-view-controller

« kdy: 08. 12. 2019, 15:35:24 »

Ahojte.

Mame napisanu GUI aplikaciu v QT, ktora sa stara o zobrazovanie dat zo snimacov a zobrazuje ich na paneli (1024/768), coz funguje pekne a dobre. Ovsem, casto sa stava ze zakaznik chce zmenit design, navrh toho GUI na ine farbicky, poposuvat zopar okien a pod, takze sa to musi menit v QT, znova skompilovat, odtestovat a dodat...

Kedze nam doba HW poskocila, tak premyslame o tom, ze by sa dalsia verzia toho GUI prerobila do electronu, pripadne cisto na chromium s HTML, CSS, javascript. Na Paneli by bezal chromium, v nom by bolo navrhnute GUI a data by tahal v nejakom definovanom formate zo siete.

Otazka do plena, ak to postavime na chromium, je dobre do toho designu zapracovat MVC, alebo riesit cisto iba "View" a zvysok nechat na backende na serveri? Alebo napisat cele MVC v javascripte/typescripte a data pollovat zo serveru?
A do tretice, pozeral som po websockets, trochu sa mi zapacilo, bude to vhodne?

Diky

Přepisem do neznámé technologie si podle mě nepomůžete. Protože pokud nemáte aplikaci napsanou pořádně v QT, tak budete plavat i v jiné technologii. A naopak, pokud ji pořádně napsanou už máte, neměli byste mít problém s drobnými úpravami a nasazením (používáte QML?). Tolik můj odhad.

546

Vývoj / Re:WebGL a co k tomu?

« kdy: 05. 12. 2019, 13:51:48 »

Já se chci nějakým způsobem vyhnout javascriptu, takže na to je wasm ideální a můžu to psát C++, které je mi bližší než javascript. Někdo už dokonce přepsal tree.js do c++, takže by to mohlo bejt v pohodě.

To si myslite, ze budete psat webovou aplikaci v c++ jen proto, ze nekdo portoval Three.js do c++? Trochu blbost, ne? Na webu se pouziva prevazne javascript. Ostatni jsou jen frameworky nebo knihovny zjednodusujici prace. WA zatim neznam, respektive nevim, jestli se to uz jako teda pouziva nebo tak

Hlavně to nemusí fungovat. Pokud by to ovšem fungovalo, pak to taková blbost není.

Stejně bych ale doporučil jít nějakou konvenční cestou. Pokud nemá tazatel dost zkušeností s danou oblastí.

547

Vývoj / Re:WebGL a co k tomu?

« kdy: 05. 12. 2019, 02:09:32 »

Nemusí to být ani v js, je možné transpilovat třeba z typescriptu a tím se špagetám vyhnout. Jak je na tom webassembly nevím.

jak definujete špagety? Typescript je jen javascript s typovými anotacemi.

Nedefinuju je nijak, byl to jen příklad transpilace, možná blbý. Podstatou sdělení je možnost transpilace a její potenciální přínos pro organizaci kódu.

548

Vývoj / Re:WebGL a co k tomu?

« kdy: 04. 12. 2019, 20:51:52 »

Nemusí to být ani v js, je možné transpilovat třeba z typescriptu a tím se špagetám vyhnout. Jak je na tom webassembly nevím.

549

Software / Re:mapovanie disku v linuxe

« kdy: 01. 12. 2019, 22:37:47 »

Optimální je mapovat podle LABEL, protože když vyměníš disk, nastavíš mu stejný label a nemusíš nic měnit v fstab. Mapovat dle UUID není tak flexibilní, ale slespoň neselže, pokud se změní pořadí zařízení. Mapovat dle zařízení v /dev je nejmíň flexibilní oldschool způsob. Jinak bych z toho ale nedělal zas takovou vědu, funguje všechno akorát je dobré znát výhody a nevýhody.

rozdil zda podle UUID nebo LABEL, je v podstate jen v tom, ze LABEL je na prvni pohled prehlednejsi pro uzivatele...
kdyz budu menit disk a nebudu chtit menit fstab (v kterem bych mel podle UUID), tak stejne jako novemu disku, resp. oddilum na nem, muzu dat stejne LABEL jako puvodni disk, muzu dat stejne UUID jako puvoidni disk:

Kód: [Vybrat]

tune2fs -L puvodni_nazev /dev/sdXY
tune2fs -U puvodni_uuid /dev/sdXY

pripadne nastavit puvodni uuid nebo label primo pri formatovani:

Kód: [Vybrat]

mkfs.ext4 -L puvodni_nazev /dev/sdXY
mkfs.ext4 -U puvodni_uuid /dev/sdXY

No vida, díky, o této možnosti jsem nevěděl. Vždycky jsem jen použil UUID vrácené z příkazu:

Kód: [Vybrat]

# blkid

550

Software / Re:mapovanie disku v linuxe

« kdy: 01. 12. 2019, 18:12:26 »

Optimální je mapovat podle LABEL, protože když vyměníš disk, nastavíš mu stejný label a nemusíš nic měnit v fstab. Mapovat dle UUID není tak flexibilní, ale slespoň neselže, pokud se změní pořadí zařízení. Mapovat dle zařízení v /dev je nejmíň flexibilní oldschool způsob. Jinak bych z toho ale nedělal zas takovou vědu, funguje všechno akorát je dobré znát výhody a nevýhody.

551

Hardware / Re:banana PI R1 shanim anteny na wifi

« kdy: 01. 12. 2019, 18:06:02 »

Podle mě je na desce U-FL konektor (hledejte U-FL třeba na tomto přehledu). Takže potřebujete buď hotový pigtail pro banana PI R1 včetně antény anebo libovolný U-FL pigtail s vhodným zakončením na druhé straně, podle toho co tam chcete mít. Banana Pi BPI-R1 využívá 2,4 GHz pásmo IEEE_802.11n, takže na druhém konci pigtailu můžete mít cokoli, co je navrženo pro tento standard.

552

Vývoj / Re:Navrh sluzby s AOL zapisom

« kdy: 01. 12. 2019, 17:42:22 »

Neexistuje pro to nějaké hotové řešení? Co ta aplikace vlastně řeší?

553

Sítě / Re:typ routeru

« kdy: 01. 12. 2019, 17:38:08 »

Zavolám někomu, ať to vyfotí štítek zařízení a pošle mi ho mailem

554

Vývoj / Re:M:N kardinalita medzi tabulkami v odlisnych schemach

« kdy: 01. 12. 2019, 17:35:28 »

Pokud by bylo třeba listovat všechny "závislosti obrázků", tak by šlo v postgresql použít inherited tables (...)

Ale tato možnost je specifická pro postgres a navíc to vypadá, že je stranou zájmu vývojářů (některé věci tam nejsou dořešené, byť to pro daný usecase nevadí, tak je otázka, jestli tudle funkcionalitu někdy nevyřadí), takže takto bych to dělal, jen pokud bych pro to měl opravdu důvod, není to "řešení první volby".

Aha, to je poměrně zajímavá možnost. Otázka zní, za je pro to podpora třeba v nějakých ORM (pro případ, že by se nepoužívalo čisté SQL)? Pro mě by bylo totiž hlavní motivací odstranit nutnost mít pro každý foo, boo zvlášť mapování a biolerplate kód navíc.

555

Vývoj / Re:M:N kardinalita medzi tabulkami v odlisnych schemach

« kdy: 01. 12. 2019, 17:32:43 »

Prosim nerieste tu integritu, ...

Chápu tu poznámku, ale jen bych rád zdůraznil, že integrita je klíčová vlastnost, proč používat databázi :-) Takže říct: "to neřešte" je... :-)

IMHO to mělo být

Kód: [Vybrat]

foo -> foo2picture -> picture
boo -> boo2picture -> picture

Samozřejmě. Pardon!

Pokud by bylo třeba listovat všechny "závislosti obrázků", tak

Oni jsou tam boje mezi těmi, kteří by rádi postgre více objektovej, a mezi těmi, kteří "takové blbost sem netahejte". (Jsem v druhém táboře :-) )

Osobně bych to řešil manuálně pomocí view. V Postgre je to bez výkonnostní ceny.

Chápu to dobře, že byste měl nad jednou tabulku více view pro foo, boo atd?