Veškerá aktivita

tak nez prepisovat deamx je lepsi si to uz napsat odznovu ne ? :D

dalo mi to 2 dni zaberák aby som tú číštinu rozlúštil :D ale to je asi všetko xD

Tak mi napiš, koupím to od tebe tam to bude alespoň čistější obchod 😃

btw vis ze prodavas moji praci ? :D kde mam podil ? :D

Mas tam emmesku 😃

Mám Jeden gangzonu z rze8 vytiahnutú čo funguje xD ak chceš napíš :D

Ahoj! 👋 zkouším sílu tady! Pracuji na projektu který bych chtěl tento rok spustit akorát mám málo času ⌛️. Proto chci využít někoho z vás, rád bych někoho kdo má bohaté zkušenosti a trošku se ještě věnuje pawnu, může se také podílet na rozvoji tohoto projektu 💪 chci to zkusit v dnešní době, třeba to vyjde třeba ne za to už nic nedám, každopádně k k věci 👇 Potřeboval bych zpracovat dá se říci možna jednoduchý systém Gangů a Gang zón, přebírání a bránění ostatních gangů + nějaké menší funkce např. 1) ukládání zón a že při přebírání musí mít nějakou zbraň s alespoň 1 ammem a kdyžtak na dalších věcech by jsme se domluvili. Za krásně odvedou práci nabízím finanční odměnu na které se domluvíme, můžeme se sejít klidně osobně a nebo to pořešit pouze přes internet a všechno zpracovat přes internet záleží, buďme seriózní 🧐 Děkuji, za každou pomoc. Kontaktujte mě zde do zpráv nebo na discord: dando7878 PS: nepište ze takové systémy jsou vyhotoveny na internetu apod, možná ano, ale chci lepší výrobu 🤟

tyjo, to je docela zajimavy, hlavne jestli to umi automatickou persistenci

Microsoft Orleans: Framework pre Distribuované Aplikácie Čo je Microsoft Orleans? Microsoft Orleans je framework na tvorbu distribuovaných, vysoko škálovateľných a spoľahlivých aplikácií v .NETe. Bol vyvinutý v Microsoft Research a je založený na virtual actor pattern, čo uľahčuje prácu s objektami v distribuovanom prostredí. Orleans je navrhnutý tak, aby minimalizoval potrebu manuálnej správy stavových objektov a synchronizácie, čo z neho robí ideálne riešenie pre aplikácie, ktoré vyžadujú vysokú dostupnosť a horizontálnu škálovateľnosť, ako napríklad herné servery, IoT systémy, finančné aplikácie či analytické platformy. Hlavné Vlastnosti Orleans Virtual Actors: Objekty (aktéri), ktoré automaticky „ožívajú“ a „zanikajú“ podľa potreby, bez manuálneho riadenia ich životného cyklu. Distribuovaná správa stavov: Aktéri uchovávajú svoj stav v perzistentnom úložisku a obnovujú ho pri reaktivácii. Automatické škálovanie: Orleans dynamicky prerozdeľuje zaťaž v klustri. Jednoduchosť: Používa sa podobne ako klasický objektový model v C#. Podpora cloudových riešení: Nativne podporuje Azure, ale je použiteľný aj v iných prostrediach ako napriklad Kubernetes. Virtual Actor Pattern Orleans je postavený na Virtual Actor Model, ktorý eliminuje manuálnu správu aktérov. Tento model rieši niektoré nevýhody klasického Actor Model (ako v Akka.NET) nasledujúcim spôsobom: Nie je potrebné manažovať životný cyklus aktérov – aktéri existujú virtuálne a sú aktivovaní, keď sú potrební. Automatická persistencia – stav aktéra môže byť uložený v perzistentnom úložisku (napr. SQL, Azure Table Storage, DynamoDB). Transparentné spracovanie správ – odosielanie správ nevyžaduje vedieť, kde aktér beží, systém ho nájde automaticky. Príklad definície aktéra v Orleans: public interface IPlayer : IGrainWithStringKey { Task<int> GetScore(); Task SetScore(int score); } public class PlayerGrain : Grain, IPlayer { private int _score; public Task<int> GetScore() => Task.FromResult(_score); public Task SetScore(int score) { _score = score; return Task.CompletedTask; } } Príklad volania PlayerGrain: IGrainFactory grainFactory = ...; // Inicializácia Orleans Grain Factory var player = grainFactory.GetGrain<IPlayer>("player1"); await player.SetScore(100); int score = await player.GetScore(); Console.WriteLine($"Hodnotenie hráča: {score}"); Ako Orleans Funguje? Orleans beží na klustri serverov a riadi aktérov v rámci uzlov (silo). Každý uzol je schopný hostovať aktérov a spracovávať ich požiadavky. Základné komponenty: Grain (aktér) - Logická jednotka, ktorá uchováva stav a vykonáva operácie. Silo - Serverový proces, ktorý hostuje aktérov. Client - Externý proces, ktorý volá aktérov cez API. Storage Providers - Mechanizmus pre perzistenciu stavu. Komunikácia medzi aktérmi Aktéri v Orleans komunikujú asynchrónne pomocou správ odosielaných cez framework. Každý aktér je identifikovaný unikátnym kľúčom a môže byť vyhľadaný prostredníctvom IGrainFactory. Komunikácia medzi aktérmi prebieha cez proxy objekty generované Orleans runtime, ktoré zabezpečujú správne smerovanie správ. Príklad volania iného aktéra z aktuálneho aktéra: public class PlayerGrain : Grain, IPlayer { public async Task SendChallenge(string opponentId) { var opponent = GrainFactory.GetGrain<IPlayer>(opponentId); await opponent.ReceiveChallenge(this.GetPrimaryKeyString()); } public Task ReceiveChallenge(string challengerId) { Console.WriteLine($"Hráč {challengerId} vás vyzval na súboj!"); return Task.CompletedTask; } } V tomto prípade aktér PlayerGrain posiela výzvu inému aktérovi PlayerGrain prostredníctvom jeho identifikátora. Orleans runtime zabezpečí, že správa sa doručí správnemu aktérovi, aj keď momentálne nie je aktívny. Kde sa Orleans Používa? Microsoft Orleans je široko používaný v rôznych odvetviach: Herný priemysel: Používa ho napr. Bungie pre Destiny 2. IoT a telemetria: Zber a spracovanie veľkého množstva udalostí. Finančné systémy: Distribuované spracovanie obchodných transakcií. Analytika a AI: Pracuje s distribuovanými modelmi strojového učenia. Záver Microsoft Orleans je silný framework pre tvorbu distribuovaných aplikácií v .NET ekosystéme. Jeho virtual actor pattern robí prácu s distribuovanými objektmi jednoduchšou a menej náročnou na správu. Ak hľadáte riešenie pre vysokoškálovateľné systémy s automatickou distribúciou a perzistenciou, Orleans je skvelou voľbou.

Ty to mas tak slozity, ze v tom dockeru to jeste buildis... Ten muj docker file je maly v tom, ze pouzivam uz vybuildenou appku a jen se v dockeru spousti. Samozrejme ze pokud chces v dockeru buildit tu appku tak se musi nastavit komplet cely vyvojovy prostredi v dockeru.

Neříkám, že jsem nějaký profík na Docker, ale Astro SSR v dokumentaci: FROM node:lts AS base WORKDIR /app # By copying only the package.json and package-lock.json here, we ensure that the following `-deps` steps are independent of the source code. # Therefore, the `-deps` steps will be skipped if only the source code changes. COPY package.json package-lock.json ./ FROM base AS prod-deps RUN npm install --omit=dev FROM base AS build-deps RUN npm install FROM build-deps AS build COPY . . RUN npm run build FROM base AS runtime COPY --from=prod-deps /app/node_modules ./node_modules COPY --from=build /app/dist ./dist ENV HOST=0.0.0.0 ENV PORT=4321 EXPOSE 4321 CMD node ./dist/server/entry.mjs A to je bez databáze a dalších service. Pokud bych chtěl databázi a další věci, tak ještě vedle musí být docker-compose atp. Ale ano, kdo to používá denně, tak je to pro něj easy, já se přiznám, že jsem to přes docker zkoušel jenom párkrát a už jen byl oser s tím, že místo npm používám bun. Ale jak to popisuješ ty, tak to zní lehce :D

Jeste lehce odbocim od tematu, ale jak je docker hrozne slozity a neprehledny? Tady priklad docker nastaveni pro java aplikaci: # Use an official Java runtime as a parent image FROM openjdk:21-jdk-slim # Set the working directory in the container WORKDIR /app # Copy the jar file from the local machine to the container COPY build/libs/myApp-0.0.1-ALPHA-all.jar /app/app.jar EXPOSE 5000 # Run the Java application CMD ["java", "-jar", "app.jar"] pouzije to image s java 21 nastavi slozku na /app zkopiruje jar souboru do slozky otevre port 5000 na kterem bezi aplikace spusti command pro zapnuti aplikace diky tomuhle souboru se vytvori jeden file (image), ktery se da spustit v jakymkoliv prostredi kde bezi docker. Da se to hodit na docker hub a da se to spustit kdekoliv. Kdy je to local host tak docker run . kdyz je to z remote repa tak docker pull mujucet/mujimage docker run mujucet/mujimage a kdyz jsme u instalace dockeru tak yum install docker apt install docker je to fakt easy, slozitost v tom hledam fakt marne :D EDIT: gg @Jiu predbehl jsi me s prispevkem asi o 10 sekund haha

all key shop - 4 eura. Ja by som povedal, ze to je skor naopak. Docker image vybuildis z Dockerfile co je zoznam commandov, ktore sa maju vykonat a nasledny image je read only; takze ak fungoval vcera, bude fungovat aj dnes. U standalone instalacii je najvacsi problem, ze po par mesiacoch si nepamatam, co je kde nainstalovane, ake su tam dependencies a nahodou updatnem nejake systemove libky, javu, .net, ... a polka veci sa zosype. Najvacsiu vyhodu vidim v tom, ze mozem deployovat docker image do kubernetes clusteru cez argocd. commitnem do git repa YAML specifikacie toho co chcem deploynut a ArgoCD mi to deployne/updatne, takze moj kubernetes cluster je syncnuty z git repom a update/deployment je jednoduchy commit ktory sa da v pripade potreby lahko rollbacknut.

Jsem si vzpomněl na Teorii velkého třesku, jak všichni 4 chtějí něco vymyslet převratného, ale stále se odklání a diskutují o něčem jiném :D Tady se pomalu strhla diskuze na téma Linux vs Windows :D S Windows mám zkušenosti jen s Vietcong a SA:MP servery přes LAN, ale není potřeba na Windows serveru licence? Jak říkám, nemám s Windows servery zkušenost. Docker mi přijde hrozně nepřehledný a zbytečně složitý (ale chápu, je některé projekty můžou být tak komplexní, že tam se to vyplatí), alespoň u projektů co dělám. Ale mám za sebou dost herních serverů na linuxu (Lineage 2, Minecraft, SA:MP, WoW, Rust, CS 1.6 atd.) a vždy největší pain bylo ten server rozchodit/nainstalovat, ale pak vše ostatní už bylo easy. Takže spíše jen otázka na zamyšlení, zda se tu nad tím nepřemýšlí zbytečně moc složitě. Zda by nestačilo prostě jen nainstalovat herní server a spustit :D Pak na nějaké složitější/větší aktualizace stačí přeci napsat jednoduchý deploy script (tak to řeším já, deploy script, který nahraje změny na server a vše buildne a spustí/restartuje).

tak ja se celou dobu bavil o serverech pro "verejnost" proste server kdy bezi aplikace jako custom, cokoliv. Na interni servery je AD a podobny nesmysly docela dobry tbh. Ale at to neserou vyvojarum do produkcniho prostredi, lidi jako ja pak musi chodil k psychiatrovi po praci s tim....

S tímto s tebou souhlasím a v praxi to tak běžně je Díky tomu jak je docker (či specifická linuxová distra) lightweight, jsou využívaná v koprodukci s Windows servery já tu nehaním linux jako takový, jen haním porovnání Linux > Windows, protože oba systémy mají odlišná pozitiva a negativa a jsou navrženy na support úplně jiných druhů aplikací

Intranet korporatu je jedna vec, deployment aplikacii pre customerov zas druha. Na pohodu moze korporat pouzivat AD, Office a Win Server na spravu internych veci a deployovat docker image do kubernetes cluster beziacom na linuxe. Cely cas som predpokladal, ze sa tu bavime iba o tej "live" casti ktora je vystavena customerom.

linuxova cerna skrinka je opensource a vsetky appky, libky, kernel moduly vcetne kernelu si mozes customizovat Linux moze bezat rok lebo to dokaze, co sa o windowse povedat neda :D

Korporáty jedou na Active Directory, Office 365 a defakto mají celé firemní IT zázemí postavené na Microsoftu z jednoho prostého důvodu - neexistuje žádná adekvátní alternativa.. Respektive, pro každý jednotlivý komponent zcela jistě najdeš adekvátní alternativní, či open-source řešení, ale dokážeš z toho poskládat ucelený environment, který prostě funguje a nebudeš kvůli tomu muset platit IT tým specialistů za nekřesťanský prachy? Nehledě na to, že Microsoftí corporate support také funguje na trochu jiné úrovni, než jsou malí hráči zvyklí a Microsoft se nebojí ohýbat jeho produkty dle požadavků jeho největší klientely

To smrdí amatérským adminem, než teda problém serveru :D Nám se všechny instance aktualizují 1x měsíčně za pochodu a restart necháváme na noc o víkendu.. Avšak v nových WS 2025 nás již čeká hotpatching, který zvládne aktualizovat celý OS bez restartů Vzhledem k tomu, co out-of-the-box WS nabízí, si stále troufám tvrdit, že jeden malý restart jednou za měsíc (updaty vycházejí každou druhou středu v měsíci) je menší zlo, než nechat linuxovou černou skříňku běžet s ročním uptimem :D

hele nemam problem s c#, mam problem s tou firmou celkove. Verim ze c# je skvelej, ale odmitam se koukat na cokoliv co je od microsoftu, protoze me proste okradli o 25 euro a vsechno ostatni co bylo super tak stoji ted za picu.

Osobne s Minecraftom ani LinkedInom nemam problem. Novy MC content je trochu disappointing, ale v porovnani s inymi hrami (a.k.a. Ubisoft) je to stale v norme. LI mi pride stale lepsi ako FB alebo Shitter. Skype upadal rovnako ako napr. ICQ, TS2, Ventrilo a pod. Osobne pouzivam C#/.NET, Office, Azure DevOps, Azure Portal, Entra, Exchange, GitHub, TypeScript, NPM a nemam s nimi problem. Napr. Azure DevOps ti poskytuje free LFS o velkosti 256GB kdezto GH iba 1GB. U Unity based projektoch je GH Free nepouzitelny. Robil som backendy v C#, Jave, Node a C++ a nejako nevidim miesto kde by C# zaostaval. Napr. Source Generator (moznost pisania kodu ktory sa sputi pri kompilacii ineho kodu a dokaze generovat dynamicky content; eg. automaticke binarne serializatory) mi pride ako fantasticka featura v porovnani s Compile-Time Function Execution ktory ma D lang.

Mám úplně stejný názor na Microšrot a nepoužívám věci od něj. I když třeba takové Clarity používám. Ale nepoužívám operační systéma na Co microsfot šáhn to posere. Chtěl jsem to téma rozebrat do hloubky, co to vlastně je to kvantování a je to těžké i pro mě abych to pochopil. Zkusím příště více do hloubky probrat toto téma. A děkuji za komentáře.

joo to uz je zajimavejsi priklad, ale stejne z mi z toho jebe hlava do stolu. Kazdopadne ad microsoft, pred 10 lety jsem s microsoftem nemel jedinej problem. Mam s nim problem jen posledni treba 3 roky, zejmena kvuli tomu, ze vsechno od nich je nepouzitelny a jen vykorustujou. Viz treba naposledy kradez minecraft licence. Na vsechno na co sahnout tak stoji nasledne za picu. Jmenovite skype, minecraft, linkedin apod...

Priklady z chemie: Simulacia molekuly vodiku H2 namespace QuantumSimulations { open Microsoft.Quantum.Chemistry; open Microsoft.Quantum.Intrinsic; open Microsoft.Quantum.Canon; open Microsoft.Quantum.Measurement; operation RunH2Simulation() : Unit { // Definujeme molekulu vodíka (H₂) s geometriou v bohr let h2Molecule = FermionHamiltonian([ Term(([], [1.0, 0.0]), 2.0, [(0, 0), (1, 1)]), Term(([], [-1.0, 0.0]), 1.0, [(0, 1), (1, 0)]) ]); // Prevod Hamiltoniánu na kvantové brány let jordanWignerEncoding = JordanWignerEncoding(h2Molecule, 2); // Simulácia najnižšej energie molekuly H₂ let energyEstimation = EstimateEnergy(jordanWignerEncoding, 2); Message($"Odhadovaná energia molekuly H₂: {energyEstimation} Ha"); } } 🔹 FermionHamiltonian – Definuje Hamiltonián systému na základe kvantovej mechaniky. 🔹 Jordan-Wigner Encoding – Konvertuje fermiónový Hamiltonián na kvantové brány. 🔹 EstimateEnergy – Používa kvantovú simuláciu na odhad energie molekuly. Simulacia molekuly vody H20: data v YAML: # Definícia molekuly vody (H₂O) s jej kvantovo-chemickou reprezentáciou geometry: - { atom: O, coords: [0.000000, 0.000000, 0.000000] } - { atom: H, coords: [0.757000, 0.586000, 0.000000] } - { atom: H, coords: [-0.757000, 0.586000, 0.000000] } basis_set: STO-3G multiplicity: 1 charge: 0 Q# simulacia: namespace QuantumSimulations { open Microsoft.Quantum.Chemistry; open Microsoft.Quantum.Intrinsic; open Microsoft.Quantum.Canon; open Microsoft.Quantum.Measurement; operation RunH2OSimulation() : Unit { // Definujeme geometriu molekuly vody (H₂O) let h2oMolecule = LoadMoleculeFromFile("h2o.yaml"); // Transformácia Hamiltoniánu na kvantové brány pomocou Jordan-Wigner mappingu let jordanWignerEncoding = JordanWignerEncoding(h2oMolecule, 4); // Použitie kvantového algoritmu na odhad základnej energie molekuly H₂O let energyEstimation = EstimateEnergy(jordanWignerEncoding, 4); Message($"Odhadovaná energia molekuly H₂O: {energyEstimation} Ha"); } } 🔹 Definujeme polohu atómov kyslíka (O) a vodíka (H) v 3D priestore. 🔹 Používame STO-3G ako bázový set (jednoduchý model pre orbitály elektrónov). 🔹 Molekula má nulový náboj a multiplicitu 1 (uzavretý singletový stav). Takto vieme simulovat napr. skladanie proteinov ktore maju sta tisice atomov, v realnom case, co je aktualne nemozne simulovat klasickymi pocitacmi. Nedavny prelom bol ked jedna spolocnost spravila AI s uspesnostou cez 90%.