1
Bazar / Re:Prodám mITX ASUS AT5IONT-I DELUXE
« Poslední příspěvek od 𝑾𝑰𝑭𝑻 kdy Dnes v 19:31:20 »Jaká je vlastně vaše představa o ceně, abych měl představu, jestli má smysl vás ukecávat 
.
.
Poslední příspěvky
2
Studium a uplatnění / Re:Kde ako ajťák žiť?
« Poslední příspěvek od r223 kdy Dnes v 18:17:03 »Je tu někdo, kdoi by se chystal na vystěhování do USA?
Já už tam měl být, projekt, v rámci kterého jsem mělo mít E1 visa nevyšel....
Možná bý mohlo být zajímavé spojit síly a kontakty.
Já už tam měl být, projekt, v rámci kterého jsem mělo mít E1 visa nevyšel....
Možná bý mohlo být zajímavé spojit síly a kontakty.
3
Odkladiště / Re:Zálohování stále se měnících velkých dat
« Poslední příspěvek od RDa kdy Dnes v 18:14:36 »Diky za hodnotou inspiraci, tohle je presne co jsem potreboval v teto chvili, aby me to dalo hlavu a patu!
Fakt jsem uvazoval o API/RPC, bez primeho pristupu vyssich aplikaci do DB, ale nevedel jsem jak/k cemu to vyuzit presne, ted chapu ze to budou proste ostruvky a musim pridat dependencies, at te ktere komponente neodriznu vetev ktera ji drzi. Tohle pujde hezky i reportovat a hlidat pri vyvoji a migracich. S rozdrobenim nemam problem, uz nyni je to hodne KISS metoda tady - individualni jednoucelove nastroje/skripty.
Tohle jsem resil ja asi lepe - uz od pocatku jsem to musel brat ze DIC ma platnost od-do, a taky ze existuje vice DIC k jednomu subjektu (klidne v kazdem eu state jedna) a na konkretnim dokladu se nachazi jedno z nich. Pak vznikla "sluzba" (spis volani/metoda), na zjistovani DIC k subjektu X, s kontextem - povinnym parametrem data, ke kteremu se dotaz vaze (vzdy tam muzete poslat dnesek, jestli jde o obecny dotaz). Podobne kontextualni queries mam napr. na dotaz na smenarensky kurz - vaze se ke dni, nebo mesici.
Tak zas asi zalezi jak ty repliky delate. Pokud je bude delat backend vrstva nad tupejsi databazi (mysql), mimo jine z duvodu, aby se resila mj i moznost behu v rozpojene/degradovane siti (pro ty mene kriticka volani, ktere to snesou, viz napr. vytvoreni objednavky v degradovanem rezimu, potvrzeni objednavky pouze v plne synchronnim, at se nemusi resit dvoji prodej polozek ze skladu a pak omlouvani se), tak je mala sance, ze by utocnik ktery ovlada jen stroje s vyssi logikou, dokazal znicit data na backendu na ktery muze sahat jen skrze API pod RPC. Takoveho pocinu by si hned mela vsimnout logika ktera bude hlidat typicke vyuzivani sluzeb, resp. melo by byt mozne revertnout dane zasahy pokud to jadro bude append-only.
Fakt jsem uvazoval o API/RPC, bez primeho pristupu vyssich aplikaci do DB, ale nevedel jsem jak/k cemu to vyuzit presne, ted chapu ze to budou proste ostruvky a musim pridat dependencies, at te ktere komponente neodriznu vetev ktera ji drzi. Tohle pujde hezky i reportovat a hlidat pri vyvoji a migracich. S rozdrobenim nemam problem, uz nyni je to hodne KISS metoda tady - individualni jednoucelove nastroje/skripty.
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.
Tohle jsem resil ja asi lepe - uz od pocatku jsem to musel brat ze DIC ma platnost od-do, a taky ze existuje vice DIC k jednomu subjektu (klidne v kazdem eu state jedna) a na konkretnim dokladu se nachazi jedno z nich. Pak vznikla "sluzba" (spis volani/metoda), na zjistovani DIC k subjektu X, s kontextem - povinnym parametrem data, ke kteremu se dotaz vaze (vzdy tam muzete poslat dnesek, jestli jde o obecny dotaz). Podobne kontextualni queries mam napr. na dotaz na smenarensky kurz - vaze se ke dni, nebo mesici.
Jinak dela se to jak tu bylo zmineno tak, ze mas treba dve primarni storage, ktery se mezi sebou replikujou. To ti resi ten prvni level (vcetne pripadne umreni storage).
Budu zcela kategoricky nesouhlasit. Replikace ti vůbec neřeší ransomwarový útok, protože napadená data se ti okamžitě replikují do sekundáru, protože samotným smyslem a účelem sekundární repliky je v reálném čase reflektovat změny v primární replice.
Replika NENÍ záloha, replika je opatření pro zajišětění vysoké dostupnosti při TECHNICKÉ ZÁVADĚ.
Tak zas asi zalezi jak ty repliky delate. Pokud je bude delat backend vrstva nad tupejsi databazi (mysql), mimo jine z duvodu, aby se resila mj i moznost behu v rozpojene/degradovane siti (pro ty mene kriticka volani, ktere to snesou, viz napr. vytvoreni objednavky v degradovanem rezimu, potvrzeni objednavky pouze v plne synchronnim, at se nemusi resit dvoji prodej polozek ze skladu a pak omlouvani se), tak je mala sance, ze by utocnik ktery ovlada jen stroje s vyssi logikou, dokazal znicit data na backendu na ktery muze sahat jen skrze API pod RPC. Takoveho pocinu by si hned mela vsimnout logika ktera bude hlidat typicke vyuzivani sluzeb, resp. melo by byt mozne revertnout dane zasahy pokud to jadro bude append-only.
4
Studium a uplatnění / Re:Kde ako ajťák žiť?
« Poslední příspěvek od BoneFlute kdy Dnes v 17:51:50 »Je vidět, že jsem tě pochopll dobře. Prostě další ancap blázen.
To, že stát vybírá peníze silou je fakt, a normální člověk s tím nemá problém. Ono je totiž spoustu hlupáků, kteří si řeknou, že se jim nelíbí, na co ten stát ty peníze utrácí a že nic platit nebudou.
Normální člověk, který má pocit (jistě opodstatněný), že stát je špatný hospodář, a že se mu nelíbí, na co a jak jsou peníze z daní vynakládány, tak půjde a použije inteligentní instrumenty, který stát jako například ČR má. Nějaké ty volby, hlasování, politická angažovanost, etc.
Normální člověk totiž chápe, že může být mnohem, mnohem hůř.
Podle toho co pises bych snad byl i normalni... Dovedu si predstavit ze jsou mist kde je mnohem hur... Dokonce se mi nedari prijit na misto kde by bylo momentlne lip...
Nicmene... mam pocit ze zdaneni je prilis vysoke a dal roste a mam strach ze to povede k tomu ze tu driv nebo pozdeji tak dobre nebude...
Volby jsou fajn, ale koho mam volit kdyz mi pravicak zvysuje dane? A ten co o sobe tvrdi ze je jeste vetsi pravicak tak je jenom xenofobni populista.
Momentalne nic bourat nechci, ale bojim se toho ze prjide cas a budem potrebovat vyplach jako v Argentine...
Jenže tohle je normální uvažování. To je cajk.
Omlouvám se, když narazím na ankap, tak vidím rudě. Nesnáším hlupáky.
5
Studium a uplatnění / Re:Kde ako ajťák žiť?
« Poslední příspěvek od listoper kdy Dnes v 17:43:28 »Je vidět, že jsem tě pochopll dobře. Prostě další ancap blázen.
To, že stát vybírá peníze silou je fakt, a normální člověk s tím nemá problém. Ono je totiž spoustu hlupáků, kteří si řeknou, že se jim nelíbí, na co ten stát ty peníze utrácí a že nic platit nebudou.
Normální člověk, který má pocit (jistě opodstatněný), že stát je špatný hospodář, a že se mu nelíbí, na co a jak jsou peníze z daní vynakládány, tak půjde a použije inteligentní instrumenty, který stát jako například ČR má. Nějaké ty volby, hlasování, politická angažovanost, etc.
Normální člověk totiž chápe, že může být mnohem, mnohem hůř.
Podle toho co pises bych snad byl i normalni... Dovedu si predstavit ze jsou mist kde je mnohem hur... Dokonce se mi nedari prijit na misto kde by bylo momentlne lip...
Nicmene... mam pocit ze zdaneni je prilis vysoke a dal roste a mam strach ze to povede k tomu ze tu driv nebo pozdeji tak dobre nebude...
Volby jsou fajn, ale koho mam volit kdyz mi pravicak zvysuje dane? A ten co o sobe tvrdi ze je jeste vetsi pravicak tak je jenom xenofobni populista.
Momentalne nic bourat nechci, ale bojim se toho ze prjide cas a budem potrebovat vyplach jako v Argentine...
6
Odkladiště / Re:Zkušenosti s internetovým bankovnictvím
« Poslední příspěvek od hmmmw kdy Dnes v 17:33:59 »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.
Mě je jejich risk management ukradený, hypo brát budu, u nich ani za nejlepších podmínek. Nemají zájem, já taky ne, bank jsou mraky, ČSOB je jedna z těch špatných.
Naše firma posílá SMSek méně a jsou levnější. Přesto, na tvé kalkulaci vydělají na každé SMS kačku padesát, to mi nepřipadá jako špatné, když jich denně nejspíše posílají desetitisíce, to je za měsíc půl mega...
7
Studium a uplatnění / Re:Kde ako ajťák žiť?
« Poslední příspěvek od Martin Poljak kdy Dnes v 17:09:38 »Zhusta protiprávně za ignorování nejen stavebních, ale i požárních předpisů platných už tehdy, z nakradeného materiálu, nezřídka v pracovní době kdy měli dělat něco produktivního pro svého zaměstnavatele, za využití "institutu" nelegálního podnikání a zaměstnávání a krácení daní (melouchy).Tak když v té době člověk nemohl vykonávat práci, kterou chtěl, nebo studovat vysoké školy, které chtěl, a dokonce ani říkat věci, které chtěl, tak se mu fakt nedivím, že okrádal stát, dělal melouchy a pracoval všude jinde než v práci...
Ono to ostatně platí tak trochu jinak i dnes: dokud se bude stát chovat jako loupežník, mám nulové zábrany vytáhnout z něj všechny peníze, na které mám zákonný nárok do posledního haléře.
8
Software / Re:FreeCAD: vybraný objekt nelze použít
« Poslední příspěvek od Mendoza kdy Dnes v 16:57:15 »Má to vypadat nějak takhle (plus/minus)?
Můj postup - vytvořím sketch - z něj desku - na plochu desky další sketch - vytáhnout sketch - pomocí transformace rozkopírovat, kam chci - vytvořím sketch na plose sloupku - vytvořím desku
Ani jsem nepoužil nějaké slučování objektů.
Můj postup - vytvořím sketch - z něj desku - na plochu desky další sketch - vytáhnout sketch - pomocí transformace rozkopírovat, kam chci - vytvořím sketch na plose sloupku - vytvořím desku
Ani jsem nepoužil nějaké slučování objektů.
9
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.
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.
10
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.
