Poslední příspěvky

11

Odkladiště / Re:Zálohování stále se měnících velkých dat

« Poslední příspěvek od Exceptions kdy Dnes v 16:44:58 »

Pokud to je modul, je to pořád součástí té aplikace, ne?

Chceš mít schopnost dělat aktualizace bez výpadků a nasazovat změny průběžně? Prostě zapomeň na to, že do jedné databáze zapisuje více samostatných aplikací. Z cizích databází čti pouze z veřejných schémat, přes api nebo odbírej event log. Jedna databáze = jeden vlastník = jeden zapisovatel a cokoliv jiného řeš replikacemi, migracemi, transformacemi. Samozřejmě to je zjednodušení.

Argumentuješ správně, když více dodavatelů používá stejné schéma a databázi, změny musíš koordinovat napříč dodavateli a nasazovat to najednou. To je pak nepořádek, to nikdy nezautomatizuješ.

Neber to absolutně. Urči si kritickou část systémů, kterou máš pod kontrolou, tam zaveď a vynuť nějaká pravidla, aby se ti žilo lépe. V dalších vrstvách můžeš stavidla uvolnit. Banky mají svůj Core, který udržují takhle náročně a přesně, ono se jim to vyplatí, ale pak mají třeba systém na vykazování práce, což je běžná databáze někde v kubernetu, přistupuje do ní několik dalších aplikací vč. koupených pluginů, udržuje to několik týmů, zálohuje se to celé najednou, aktualizace znamená výpadek a restart, s tím se dá žít, uděláš to mimo pracovní dobu, na konci měsíce z toho uděláš report do účetnictví a ten skončí v Core vrstvě.

Musíš si určit co chceš a co ne. Je na tobě, co pustíš do infrastruktury a jaká pravidla musí co splnit. s NIS2 se nám objeví ve spoustě firem povinnost si zmapovat, který systém je jak důležitý pro chod firmy a jak pro nás je bolestný výpadek, tohle ti přesně udělá ten řez. Pokud bez té aplikace nemůžeš ani otevřít dveře, těžko jí můžeš provozovat stylem, že X aplikací od X dodavatelů zapisuje do stejné databáze a aktualizují si schémata jak se jim zachce. Rozumíš kam s tím mířím?

Pokud někdo chce udělat z např. Pohody (pohoda.cz) kritický systém a řekne mi, že tady má webovou aplikaci, která přímo přistupuje do databáze, další která používá api, má tady několik koupených pluginů a třetí strana to aktualizuje sama každý půl rok. Řeknu mu, že bez rozbití těch integrace a jejich oddělení a normalizování datové vrstvy s tím moc neudělám (viz třeba co vše musel udělat AK system, aby měl pohodu distribuovanou). Pak přesně přichází na řadu diskuze, jestli je levnější to předělat nebo koupit flexibilnější účetní systém.

12

Odkladiště / Re:Zálohování stále se měnících velkých dat

« Poslední příspěvek od jjrsk kdy Dnes v 16:03:17 »

Udělej mezi tím rozhraní, pohledy, marty, jinou databázi.

Tohle ti nebude tak uplne fungovat. Mam bezne pod spravou aplikace do kterych dodavaji moduly ruzni dodavatele. Ten modul ma samozrejme primy pristup k databazi, kde ma typicky nejake sve tabulky, ale zaroven pouziva ty "systemove".

Kazdy API pak ma nejaky svoje omezeni, a ne vzdy lze pres API zrealizovat to, co chces. A naopak, pokud udelas "neomezene" API, narazis na presne stejny problem.

Jakykoli udrzovani kompatability pak vede k presne tomu, co zminil RDa ... neudrzovatelny brajgl.

Priklad. Soudruzi kdysi davno vytvorili policko DIC a pridali ho k zaznamu organizace. Jenze pak se zjistilo, ze jedna oganizace muze mit ruzna DIC v ruznych casovych obdobich ... a tak pridali vazbu. Jenze to puvodni policko uz pouzivalo spoustu dalsich funcionalit, tak ho tam nechali. A voiala, neudrzovatelny bragl je na svete. V zavislosti na tom z kery strany do toho bordelaku vlezes se mozna vyplni jedna nebo druha nebo obe moznosti. A vysledek je ten, ze klildne na ruznych dokladech mas ruzna DIC.

Pokud bys chtel zaridit co pises, tak mas jedine dve varianty. Bud mas 100% pod kontrolou vyvoj vseho co se vsim nejak komunikuje a muzes rozkazem zaridit prislusne zmeny, nebo to proste postavis tak, ze te nejaka kompatabilita nepali, a at se kazdej postara jak umi.

Ono totiz i verzovani API povede k tomu, ze proc by sme to menili, kdyz to funguje. Takze ve vysledku budes mit desitky nebo stovky verzi API ktery budes muset udrzovat, pokud jim to nechces rozbit.

13

Bazar / Prodám Lenovo X230, 16GB RAM, coreboot

« Poslední příspěvek od okias kdy Dnes v 14:40:31 »

Prodám X230, procesor i5, 16 GB RAM, SSD ~ 256G, má místo klasické nabíječky USB-C a naflashovaný coreboot místo běžného BIOSu (možné vrátit). Žádný krasavec to není, jsou k němu dvě baterky, ale asi KO.

Občas si s ním hraju, ale někdo ho ocení víc než já.

Cenu navrhněte, osobní předání Praha preferováno.

Díky

14

Odkladiště / Re:Zkušenosti s internetovým bankovnictvím

« Poslední příspěvek od L.. kdy Dnes v 14:16:50 »

Já si myslím, že jednoho člověka v rámci procesů na pobočce řeší. Jen musí být ten člověk zajímvý. Mě tam holt pouze chodila výplata a žádné produkty jsem nevyužíval. Že by třeba jednou u nichy bylo hypo, rozpoznat nedokázali nebo jim to nepřišlo zajímavé.

Takže jsi byl nezajímavý (moc z tebe nemají) a bylo u tebe zvýšené riziko nákladů na řešení vykradeného účtu, protože trváš na používání méně bezpečné autentizace. Jinak náklady na SMS ve velkém (pro banku) jsou cca 1,- za kus bez DPH.

Že si MOŽNÁ budeš chtít vzít hypotéku a MOŽNÁ si ji vezmeš v téhle bance není moc argument.

15

Odkladiště / Re:Zálohování stále se měnících velkých dat

« Poslední příspěvek od Exceptions kdy Dnes v 12:29:55 »

Tak zajima me to prave z architektonickeho hlediska, protoze pripravuji prepsani sveho erp/ucetnictvi (inhouse reseni). At to je cely vlastne primarne insert-only (writeonly, append), a modify se dela jen nad pomocnymi tabulkami pro aktualni stav (primarne z toho duvodu aby to bylo zivy a synchronni ve dvou lokacich). Nejvetsi hruza je ale ze zmen schematu - doposud na te "primitivni" db bylo vse jenom rozsirovano a pridavano, s tim ze to je pak zpetne kompatibilni (tj. nic nezmizi a ani nic nebude jinak), ale pak to casem vytvori neudrzovatelny moloch (asi hodne SAPoidni).

Tak se pidim po tom, jak resit tyhle veci (tj. nejake procesni pristupy, at je schema synchronni s okolnimi "skripty"). Napada me takovej tick-tock pristup, kdy se prvne zmigruje okoli na pouziti obojiho a pak az data. A to jeste bych rad bezvypadkove (treba aukro me neskutecne vytaci hlaskou o odstavce.. tohle v roce 2025 by uz nemelo byt bezne/caste). Z popisu jak hodnotis sektor by me byl blizsi asi pristup vice mensich zmen, ve smyslu mala zmena = mensi sance to podelat, castejsi zmena = stane se z toho rutina, nez ten druhy obcasny s vetsimi upravami.

Udělej mezi tím rozhraní, pohledy, marty, jinou databázi.

Přistup k schématu a databázi jako k vlastnictví. Každé scéma vlastní konkrétní aplikace a nikdo jiný než daná aplikace dané schéma nepoužívá. Pokud potřebuješ data sdílet mezi aplikacemi, exportuj data jako veřejný, stabilní, zaručený interface (ať už formou materializovaných pohledů nebo replikaci do jiné databáze nebo použití nějaké rpc nebo fronty), pak máš prostor, kde můžeš ošetřovat zpětnou kompatilibitu, verzovat či řídit změny bez ohledu na to, jak s schématy zachází její vlastník.

To, jestli jedna aplikace bude celý ERP nebo tam budeš mít jednotlivé služby je na tobě, vždy se při určité velikosti vyplatí to logicky rozdělit.

A pokud jde o řízení změn u konzumentů dat, tak hodně záleží na tom, co konzument dělá. Pokud to je třeba posílač emailů, tak starého omezím pouze na původní verzi schématu a spustím nového nad novým schématem. Stará data doběhnou a nové se začnou posílat jinak.

Nebo udělám nějaký bridge, který bude nové schéma zpětně migrovat do starého, aby původní aplikace plně fungovala beze změn. Tohle je třeba v případě bank častý způsob. Navenek nic není vidět. Až aplikace se upraví, změní se jí link na nové schéma a bude ho konzumovat přímo.

Základem je ale pořád mít nějakou vrstvu, která bude fungovat jako mezičlánek, výstup z té vrstvy je verzovaný interface a o vstup se právě stará majitel schématu a udržuje migrace při změnách. Na začátku třeba začínáš tím, že máš pohledy typu select *, protože nepotřebuješ nic jiného dělat.

Pokud jde o zápis, platí pravidlo výše, pouze jedna aplikace jako vlastník může do schématu zapisovat, ostatní nikoliv, takže na vše mít RPC nebo frontu změn a ty si bude sama aplikace odbavovat, jen ta ví, jaké je správné schéma. Varianta, kdy všichni zapisují do jedné společné databáze, jak je běžně vidět u webových aplikací vede pouze a jen k celkovým odstávkách při aktualizaci.

Pokud jde o bezvýpadkovou aktualizaci a migraci schémat. Buď máš potřebnou obslužnou logiku implementovanou v aplikaci a v jednu dobu zapisuje a čte z dvou různých verzí schémat, což je někdy dost komplikované nebo používáš materializované pohledy a migrace na úrovni databáze, aplikace pak má najednou k dispozici obě verze schémat, nové i staré a může postupně přejít na nové.

Občas se dostaneš do situace, kdy změnu potřebuješ udělat daleko rozsáhlejší, použij verzování route a směruj staré požadavky na starou aplikaci a nové požadavky na novou a v jednu dobu budeš provozovat dvě verze backendu, data z nich sdružovat právě v nějakých martech, veřejných interfaces.

Cest je ale hodně, tohle je jen takové postrčení jak to můžeš řešit. Vše zmíněné zvládne pg, s mariadb nepočítej. Pokud se vzhlédneš v moderních nosql databázích, budeš si to muset nějak implementovat sám.

16

Hardware / Re:Kde koupit 10m HDMI kabel?

« Poslední příspěvek od Michal Šmucr kdy Dnes v 12:01:01 »

15/DDC mi přijde zapojené přes ten R13 (?), zatímco 13/CEC mi přijde volný (stejně jako v adaptérech DVI/HDMI, co jsem našel na netu).

Jo, je to tak. A CEC narozdíl od toho DDC, které se používá během hand shake, není tak zásadní.
Jak jsem psal předtím, v noci jsem se na fotku špatně podíval a z nějakého důvodu si myslel, že je to HDMI female a počítal ty piny z druhé strany. Brain fart

17

Hardware / Re:Kde koupit 10m HDMI kabel?

« Poslední příspěvek od redustin kdy Dnes v 11:43:10 »

15/DDC mi přijde zapojené přes ten R13 (?), zatímco 13/CEC mi přijde volný (stejně jako v adaptérech DVI/HDMI, co jsem našel na netu).

18

Windows a jiné systémy / Re:Aktivace Win 7 Pro OEM

« Poslední příspěvek od kyssling02 kdy Dnes v 10:54:50 »

Děkuji všem, jen ještě dodám, že ani nová instalace Win7 64bit licenci na desce nenalezla (takže to 32/64 bit nehrálo roli). Ale už je to chválabohu za mnou. Mějte fajn den !

19

Hardware / Re:Kde koupit 10m HDMI kabel?

« Poslední příspěvek od Michal Šmucr kdy Dnes v 10:54:47 »

Pokud ty signály jedou každý na dostatečně vzdálených základních kmitočtech, tak to klidně můžeš poskládat na společné vodiče a na konci pásmovou propustí zase rozpajtlovat.
Analogie: nevšiml jsem si, že by VKV rozhlas využíval nějakou formu časového multiplexu jednotlivých stanic; ty snad jo?

Ideově tě chápu.. a jasně můžeš mít časový nebo frekvenční multiplex. DDC (v podstatě I2C) je mnohem níž než TMDS. Hlavně mě ten pin 15, když jsem na to v noci koukal, prvně přišel nezapojený. Teď jsem si uvědomil, že je to stranově obráceně, protože je to male konektor. Jak je to PCB na fotce vyndané z té plastové krabičky na TX části, tak je to jen posunuté - mea culpa
No jestli to opravdu komunikuje přes DDC a je to čistě pasivní, tak si nedovedu představit, že je to udělané jinak, než říkáš.
Každopádně ať už je to jakkoliv, tak mi nepřijde, že by tohle pasivní slučování, propusti, hrabání do těch diferenciálních páru mělo mít pozitivní dopad na kvalitu přenosu nebo pomohlo délce vedení (když už je to extender). Ale samozřejmě, jestli to ostatním v konkrétním zapojení funguje nebo dokonce pomohlo, tak to může znít jako vcelku zbytečná debata
Možná si to ze zvědavosti někdy taky koupím, třeba místo jednoho piva

20

Software / Re:FreeCAD: vybraný objekt nelze použít

« Poslední příspěvek od AlesSt kdy Dnes v 10:54:43 »

Dobrý den,
tělo je aktivní, pokud ve Part Workbench vyberu Pad a v druhém Pad001 (vždy nabídne jen jednu možnost výběru ve sloupci) , zústanou mi jen kružnice z posledního Sketch.