316
Server / Re:Automatické sestavení RAID1
« kdy: 06. 05. 2019, 08:26:17 »
Klasický problém, na debianu mi jej zatím vždy vyřešilo přidání definic polí do mdadm.conf (již zde uvedeno) + zavolat update-initramfs.
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.
317
Vývoj / Re:Výběr MCU ARM Cortex M0/0+/4? konkrétně
« kdy: 29. 04. 2019, 06:58:28 »
Nejlevnější blue pill stojí s dopravou jako nedávno zavedené zlevněné poštovné v TME - něco přes 40 Kč.
318
Vývoj / Re:Návrh relační databáze
« kdy: 27. 04. 2019, 13:25:52 »
OWL - zajímavé, díky.
Tohle stále ještě platí (citace z wiki)?
Limitations
No direct language support for n-ary relationships. For example, modelers may wish to describe the qualities of a relation, to relate more than 2 individuals or to relate an individual to a list. This cannot be done within OWL. They may need to adopt a pattern instead which encodes the meaning outside the formal semantics.
Tohle stále ještě platí (citace z wiki)?
Limitations
No direct language support for n-ary relationships. For example, modelers may wish to describe the qualities of a relation, to relate more than 2 individuals or to relate an individual to a list. This cannot be done within OWL. They may need to adopt a pattern instead which encodes the meaning outside the formal semantics.
319
Studium a uplatnění / Re:Ktorým smerom ďalej?
« kdy: 27. 04. 2019, 13:19:23 »
Dělej, co tě baví. Jen tak v tom můžeš být opravdu dobrý.
320
Vývoj / Re:Návrh relační databáze
« kdy: 25. 04. 2019, 23:04:21 »
Umím ocenit teorii, když má opravdu hodnotu. Třeba o jejím významu pro SQL ani o DB nijak nepochybuji. Nicméně dle mého názoru je celá řada návrhových vzorů úplně normální řešení, které každý slušnější vývojář použije, protože mu přijde správné a samozřejmé a vůbec nemusí ani tušit, že to má nějaký odborný název. Taková teorie jde mimo mě. Zrovna tenhle princip EAV je jedno z těch úplně normálních řešení.
V roce 2003 moc hotových ORM v javě nebylo, obzvláště ne s výkonově optimalizovanou podporou ACL pro read/write/delete/link/grant na úrovni jednotlivých objektů a z nich poskládaných stromových struktur. Defakto adresářová struktura s ACL, původně to sloužilo jako DMS pro přímé propojení se sambou - přístup přes file manager i přes prohlížeč. Dneska už práva na objektech tolik neřešíme, je to spíš na byznys vrstvě, ale občas jsou potřeba.
Design/vývoj javovského ORM 1 hodně šikovný člověk cca půl roku, způsob uložení dat do DB jsme měli již ověřený z dřívějšího projektu ještě v PHP (od r. 2000).
Dneska bych se podíval po něčem hotovém, ale osobně bych opět volil nějaké efektivní mapování ORM do klasického SQL, s pořádnou podporou kešování. Líbí se mi grafové databáze, ale ty principy se pomalu dostávají do SQL, což je IMO správná a užitečná cesta.
V roce 2003 moc hotových ORM v javě nebylo, obzvláště ne s výkonově optimalizovanou podporou ACL pro read/write/delete/link/grant na úrovni jednotlivých objektů a z nich poskládaných stromových struktur. Defakto adresářová struktura s ACL, původně to sloužilo jako DMS pro přímé propojení se sambou - přístup přes file manager i přes prohlížeč. Dneska už práva na objektech tolik neřešíme, je to spíš na byznys vrstvě, ale občas jsou potřeba.
Design/vývoj javovského ORM 1 hodně šikovný člověk cca půl roku, způsob uložení dat do DB jsme měli již ověřený z dřívějšího projektu ještě v PHP (od r. 2000).
Dneska bych se podíval po něčem hotovém, ale osobně bych opět volil nějaké efektivní mapování ORM do klasického SQL, s pořádnou podporou kešování. Líbí se mi grafové databáze, ale ty principy se pomalu dostávají do SQL, což je IMO správná a užitečná cesta.
321
Vývoj / Re:Návrh relační databáze
« kdy: 25. 04. 2019, 21:16:17 »
Deset minut smolím odpověď a mezitím mě zdejší geniální systém odhlásí a odpověď zahodí.
Je to normální selský rozum, jak pokud možno trochu efektivně uložit objekty s atributy a vazbami. Název mě až tak nepálí, s kolegy si to umím vysvětlit i bez teoretických pouček od akademiků.
* tabulka objektů - klíč obj_id. Objekty jsou různých typů - class_id
* tabulka druhů/názvů atributů - klíč attrib_id
* každý typ atributu má vlastní tabulku attrib_XXX, kde XXX je jeho attrib_id. Řádky jsou hodnoty pro objekty, tedy cizí klíč obj_id na objekt. Sloupec value je textový, číslo, datum, json atd., dle konkrétního typu atributu . Atributů/tabulek jsme zatím nadefinovali cca tisíc.
* tabulka vazeb s obj_from_id, obj_to_id a opět class_id - třída vazby. Vazby mají privátní číselnou položku, která určuje např. pořadí podtémat ve výpisu jedné úrovně stromu, snadno se podle toho stromy zpracovávají.
* další tabulky pro práva, fulltext nad stringovými atributy atd.
Samozřejmě to vyžaduje ORM vrstvu v javě, přes kterou se dělají všechny změny. Ta kešuje načtené objekty, atributy, vazby. Klidně úplně všechny, od toho paměť je. Změna nejdříve transakčně zapisuje do DB, když se podaří, změní i nakešovaná data, takže to samozřejmě drží synchronizované.
Jak říkám, je to selský rozum. Ale docela se to osvědčilo a zatím moc změn nevidím potřeba. Chybí atributy u vazeb, to bude potřeba pořešit. A samozřejmě to chce nativní fulltext, klasický problém spousty projektů.
Je to normální selský rozum, jak pokud možno trochu efektivně uložit objekty s atributy a vazbami. Název mě až tak nepálí, s kolegy si to umím vysvětlit i bez teoretických pouček od akademiků.
* tabulka objektů - klíč obj_id. Objekty jsou různých typů - class_id
* tabulka druhů/názvů atributů - klíč attrib_id
* každý typ atributu má vlastní tabulku attrib_XXX, kde XXX je jeho attrib_id. Řádky jsou hodnoty pro objekty, tedy cizí klíč obj_id na objekt. Sloupec value je textový, číslo, datum, json atd., dle konkrétního typu atributu . Atributů/tabulek jsme zatím nadefinovali cca tisíc.
* tabulka vazeb s obj_from_id, obj_to_id a opět class_id - třída vazby. Vazby mají privátní číselnou položku, která určuje např. pořadí podtémat ve výpisu jedné úrovně stromu, snadno se podle toho stromy zpracovávají.
* další tabulky pro práva, fulltext nad stringovými atributy atd.
Samozřejmě to vyžaduje ORM vrstvu v javě, přes kterou se dělají všechny změny. Ta kešuje načtené objekty, atributy, vazby. Klidně úplně všechny, od toho paměť je. Změna nejdříve transakčně zapisuje do DB, když se podaří, změní i nakešovaná data, takže to samozřejmě drží synchronizované.
Jak říkám, je to selský rozum. Ale docela se to osvědčilo a zatím moc změn nevidím potřeba. Chybí atributy u vazeb, to bude potřeba pořešit. A samozřejmě to chce nativní fulltext, klasický problém spousty projektů.
322
Vývoj / Re:Návrh relační databáze
« kdy: 25. 04. 2019, 17:48:09 »
Pokud to dobře chápu, máte tam Entity–attribute–value model (EAV)? Pokud ano, bylo by dobré zmínit, že to ledaskdo považuje za antipattern. Což samozřejmě neznamená, že to nemůže fungovat, otázkou je pracnost a vlastnosti.
Přiznám se, že teoretické antipatterny neřeším, zajímají mě praktické požadavky. Snadná rozšiřitelnost do všech stran, podpora spolehlivého dlouhodobého vývoje (žádná reflexe apod, vše typově hlídané) a v neposlední řadě rozumný výkon. Ale ten lze dnes nahonit HW, který je velice levný. Repas server DL580 s 512GB DDR3 12800, 40 jádry a spoustou PCI-e v.3 slotů pro NVMe disky jsme nedávno kupovali za 30k Kč s dopravou. Tichá pracovní stanice Precision T7600 2x octa e-5 xeon 128GB RAM + spoustu PCI-e v.3 vyjde na 21k Kč, s 256GB RAM něco přes 30k. Kolik je to proti měsíčním nákladům na jednoho vývojáře...
Narozdíl od nákladů na vývoj, které jen porostou. Požadavky na změny a nové funkce chodí od byznysu každý den, zatímco ruční zásah do struktury DB jsme nedělali už hodně let. Tabulky atributů si samozřejmě vyrábí ORM samo.
323
Vývoj / Re:Návrh relační databáze
« kdy: 25. 04. 2019, 16:33:47 »
Používáme už skoro 20 let defakto ORM uložení do SQL - objekty a vazby mezi nimi.
Tabulka objektů se základními parametry objektů (ID objektu, ID typu objektu, název, datum vytvoření, přístupová práva atd.). ID typu objektu odpovídá příslušné třídě v javě - potomku InfoObject. Přímo třída objektu může nést už byznys kód, protože jsou vytvořené pro konkrétní účel (téma, dokument, uživatel, firma, skupina, obrázek, žádost, atd. atd.).
Pak je evidenční tabulka atributů, která obsahuje typ (string/int/date/JSON) a ID typu atributu. Stále častěji používáme typ JSONAttrib. Opět typu atributu odpovídají třídy v javě.
Každý atribut má vlastní tabulku attr_IDatributu se sloupcem value dle jeho typu a samozřejmě id_obj s navázáním na objekt.
Tabulka relations s ID typu vazby, id_obj_from, id_obj_to + pár dalších údajů. ID vazby odpovídá příslušné třídě v javě - potomku Relation. Přímo třída vazby může nést už byznys kód, protože je pro konkrétní účel a obvykle si i kontroluje, zda se ji snažíme vázat na správný typ objektu.
Je nad tím poměrně robustní vrstva v javě, která vše přes weak vazby kešuje v paměti. Paměť je dnes velice levná. DB slouží pro perzistenci a pro vyhledávání.
Tabulka 4 mil. objektů cca 100 typů, 1000 tabulek atributů, tabulka 20 mil. vazeb cca 150 typů. Vše provázané cizími klíči přes objID včetně fulltextových tabulek - při odstranění objektu se vyčistí všechny jemu odpovídající záznamy v DB. MariaDB + innodb zcela v pohodě. Hledání je svižné i při hodně komplikovaných query (spoustu podmínek na atributy a vazby, left joiny atd.). Je fakt, že má MariaDB na produkčních serverech nastavené celkem dost RAM (100GB) a vše samozřejmě na SSD (nové servery na PCIe NVMe).
Problém je fulltext. Máme interní indexátor nad atributy textového typu přímo v mysql, ale ten neumí spoustu fulltextových vychytávek, takže bokem defakto elastic search s asynchronní aktualizací z objektové vrstvy a to není úplně dobré. Jenže kvalitní fulltext (více jazyků, přibližná hledání) je opět elasticsearch...
Drží to dobře, asi bych to dneska dělal znovu podobně, noSQL DB zatím pořád nějak nevěřím, mongo mě pro tyto účely rozhodně nepřesvědčilo (máme pro statistiky přístupů, cca 100 mil. objektů). Jenom ten fulltext je problém, snad se nativní fulltext mariadb posune (podpora více jazyků apod...)
Tabulka objektů se základními parametry objektů (ID objektu, ID typu objektu, název, datum vytvoření, přístupová práva atd.). ID typu objektu odpovídá příslušné třídě v javě - potomku InfoObject. Přímo třída objektu může nést už byznys kód, protože jsou vytvořené pro konkrétní účel (téma, dokument, uživatel, firma, skupina, obrázek, žádost, atd. atd.).
Pak je evidenční tabulka atributů, která obsahuje typ (string/int/date/JSON) a ID typu atributu. Stále častěji používáme typ JSONAttrib. Opět typu atributu odpovídají třídy v javě.
Každý atribut má vlastní tabulku attr_IDatributu se sloupcem value dle jeho typu a samozřejmě id_obj s navázáním na objekt.
Tabulka relations s ID typu vazby, id_obj_from, id_obj_to + pár dalších údajů. ID vazby odpovídá příslušné třídě v javě - potomku Relation. Přímo třída vazby může nést už byznys kód, protože je pro konkrétní účel a obvykle si i kontroluje, zda se ji snažíme vázat na správný typ objektu.
Je nad tím poměrně robustní vrstva v javě, která vše přes weak vazby kešuje v paměti. Paměť je dnes velice levná. DB slouží pro perzistenci a pro vyhledávání.
Tabulka 4 mil. objektů cca 100 typů, 1000 tabulek atributů, tabulka 20 mil. vazeb cca 150 typů. Vše provázané cizími klíči přes objID včetně fulltextových tabulek - při odstranění objektu se vyčistí všechny jemu odpovídající záznamy v DB. MariaDB + innodb zcela v pohodě. Hledání je svižné i při hodně komplikovaných query (spoustu podmínek na atributy a vazby, left joiny atd.). Je fakt, že má MariaDB na produkčních serverech nastavené celkem dost RAM (100GB) a vše samozřejmě na SSD (nové servery na PCIe NVMe).
Problém je fulltext. Máme interní indexátor nad atributy textového typu přímo v mysql, ale ten neumí spoustu fulltextových vychytávek, takže bokem defakto elastic search s asynchronní aktualizací z objektové vrstvy a to není úplně dobré. Jenže kvalitní fulltext (více jazyků, přibližná hledání) je opět elasticsearch...
Drží to dobře, asi bych to dneska dělal znovu podobně, noSQL DB zatím pořád nějak nevěřím, mongo mě pro tyto účely rozhodně nepřesvědčilo (máme pro statistiky přístupů, cca 100 mil. objektů). Jenom ten fulltext je problém, snad se nativní fulltext mariadb posune (podpora více jazyků apod...)
324
Vývoj / Re:výběr MCU ARM cortex M0/0+/4? konkrétně
« kdy: 23. 04. 2019, 17:27:34 »
Už to tu dřív zaznělo, ale doporučuji se podívat na ChibiOS. Vyvíjí to Ital, který dělá pro ST v Neapoli, velice dobře komunikuje. Pro Windows má plně nakonfigurované eclipse se všemi potřebnými závislostmi, stačí rozbalit, mírně pokonfigurovat dle konkrétní desky a rovnou nahrávat příklady. Zkoušel jsem to na blue pill z ebaye za 50Kč, i v linuxu to bylo bez problémů. K většímu otestování než připojení TFT LCD, rozchození napojení na ugfx a pár základním příkladům s texty a dotykem jsem se zatím bohužel nedostal, přišly jiné priority, ale chibiOS běží již roky a rozhodně bych se toho pro STM32 nebál.
325
Desktop / Re:Dotyková obrazovka má invertovaný dotek
« kdy: 19. 04. 2019, 14:11:41 »
Pokud stále platí, že při instalaci (liveUSB?) to bylo OK a po instalaci se to rozhodí, tak to musí být jen nějaká ptákovina. IMO by neměl být zásadní problém porovnáním zjistit, co je z live bootu jinak než z nainstalovaného.
326
Software / Re:Přehráváni 24bit wav little endian
« kdy: 01. 04. 2019, 00:07:10 »
https://stackoverflow.com/questions/40297935/alsa-using-pcm-s24le/40301874#40301874
https://patchwork.kernel.org/patch/8868851/#18659311
wav neumí uložit formát S24_LE.
Buď bych zkusil S24_3LE (tedy skutečné 3 bajty), nebo S32_LE (tedy s nulovým bajtem na LSB pozici). S24_LE je obskurní formát.
https://patchwork.kernel.org/patch/8868851/#18659311
wav neumí uložit formát S24_LE.
Buď bych zkusil S24_3LE (tedy skutečné 3 bajty), nebo S32_LE (tedy s nulovým bajtem na LSB pozici). S24_LE je obskurní formát.
327
Desktop / Re:Jak plnohodnotně pracovat ve VM
« kdy: 26. 03. 2019, 10:51:26 »
Proč si kvůli hardwaru takhle komplikovat život?
Tichá stanice Precision T7600 2x 8-core xeon E5-2665 128GB DDR3 1333 ECC vyjde na 21 tis. bez DPH https://www.ebay.com/itm/Dell-Precision-T7600-2x-Xeon-8-Core-E5-2665-16x-2-4GHz-32Th-128GB-Perc-H310/293012651527 , prodejce se tím živí https://www.quantelectronic.de/Server-und-Workstation/Dell-Precision-T7600-2x-Xeon-8-Core-E5-2665-16x-24GHz-32Th-128GB-RAM-Perc-H310-1300W-i5_46185.htm . Nebo rovnou s 256GB RAM za 34 tis. https://www.ebay.com/itm/Dell-Precision-T7600-Workstation-2x-Xeon-E5-2650-Ram-256GB-HDD-600GB-SAS-2TB/372622076976 , ale to by asi šlo výhodněji od plátce DPH. Tahle stanice pojede ještě spoustu let. Když do ní nastrkáš NVMe disky (má 1 x PCIe3-x4 a 5x PCIe3-x16), bude lítat jako blesk.
IMO není žádný důvod při dnešních cenách HW a mzdových nákladech vývojářů si hardwarem snižovat efektivitu práce.
Tichá stanice Precision T7600 2x 8-core xeon E5-2665 128GB DDR3 1333 ECC vyjde na 21 tis. bez DPH https://www.ebay.com/itm/Dell-Precision-T7600-2x-Xeon-8-Core-E5-2665-16x-2-4GHz-32Th-128GB-Perc-H310/293012651527 , prodejce se tím živí https://www.quantelectronic.de/Server-und-Workstation/Dell-Precision-T7600-2x-Xeon-8-Core-E5-2665-16x-24GHz-32Th-128GB-RAM-Perc-H310-1300W-i5_46185.htm . Nebo rovnou s 256GB RAM za 34 tis. https://www.ebay.com/itm/Dell-Precision-T7600-Workstation-2x-Xeon-E5-2650-Ram-256GB-HDD-600GB-SAS-2TB/372622076976 , ale to by asi šlo výhodněji od plátce DPH. Tahle stanice pojede ještě spoustu let. Když do ní nastrkáš NVMe disky (má 1 x PCIe3-x4 a 5x PCIe3-x16), bude lítat jako blesk.
IMO není žádný důvod při dnešních cenách HW a mzdových nákladech vývojářů si hardwarem snižovat efektivitu práce.
328
Software / Re:Přehráváni 24bit wav little endian
« kdy: 12. 03. 2019, 16:09:42 »
A co přesně konkrétně děláš? Příkazy, typ zvukovky atd...
329
Software / Re:Přehráváni 24bit wav little endian
« kdy: 10. 03. 2019, 23:36:09 »
S24_LE nebo S24_3LE? Tipuju si, že důvod je tenhle.
330
Hardware / Re:Chytrá elektroinstalace v bytě
« kdy: 03. 03. 2019, 19:36:52 »
Inels bych opravdu nebral. Švagr si to dal do nového baráku a několik let tam měl pořád dokola "certifikované" techniky, kteří vyměňovali jeden spínací modul za druhým, žaluzie i světla pořád blbly. Po vypnutí/výměně to chvíli jelo, technici odjeli a za pár hodit to blblo znovu.
Nikoho z "techniků" nikdy nenapadlo změřit napětí na sběrnici. Místo 27V tam bylo 16V. DIN zdroj inelsu za několik tisíc Kč měl vadný referenční zdroj TL431, po zahřátí mu sjelo napětí skoro na polovinu. Takže po vypnutí zdroj vychladl, chvíli dával napětí OK 27V, pak se zahřál, a když už byli technici v trapu, napětí 16V na spolehlivé spínání opravdu nestačilo. Po náhradě reference z nefunkčního ATX zdroje to šlape už řadu let spolehlivě.
Zdroj byl špatný od začátku, technici k ničemu. Za ty stovky tisíc, co švára za "chytrou" instalaci dal, docela fail. Takže souhlas s otevřeným DIY řešením.
Nikoho z "techniků" nikdy nenapadlo změřit napětí na sběrnici. Místo 27V tam bylo 16V. DIN zdroj inelsu za několik tisíc Kč měl vadný referenční zdroj TL431, po zahřátí mu sjelo napětí skoro na polovinu. Takže po vypnutí zdroj vychladl, chvíli dával napětí OK 27V, pak se zahřál, a když už byli technici v trapu, napětí 16V na spolehlivé spínání opravdu nestačilo. Po náhradě reference z nefunkčního ATX zdroje to šlape už řadu let spolehlivě.
Zdroj byl špatný od začátku, technici k ničemu. Za ty stovky tisíc, co švára za "chytrou" instalaci dal, docela fail. Takže souhlas s otevřeným DIY řešením.
