Podcasts about cqrs

https://bit.ly/Intro_Event_Sourcing_Podcast Practical Intro to Event Sourcing WorkshopNew Small Talk interview with Oskar Dudycz to present his upcoming remote workshop Practical Introduction to Event Sourcing.We'll talk about Event Sourcing, Domain-Driven Design and how they can help keep track of all the business facts without losing a single piece of business information while answering tomorrow's questions and challenges.Oskar will help us get an overview of how the workshop will actually work and what we are gonna get out of it - our goal is always to provide some tools and ideas you can start implementing in your work from day one after the class.

https://bit.ly/Intro_Event_Sourcing_Podcast Practical Intro to Event Sourcing WorkshopNew Small Talk interview with Oskar Dudycz to present his upcoming remote workshop Practical Introduction to Event Sourcing.We'll talk about Event Sourcing, Domain-Driven Design and how they can help keep track of all the business facts without losing a single piece of business information while answering tomorrow's questions and challenges.Oskar will help us get an overview of how the workshop will actually work and what we are gonna get out of it - our goal is always to provide some tools and ideas you can start implementing in your work from day one after the class.

Chris Patterson, founder and principal architect of MassTransit, joins host Jeff Doolittle to discuss MassTransit, a message bus framework for building distributed systems. The conversation begins with an exploration of message buses, their role in asynchronous and durable application design, and how frameworks like MassTransit simplify event-driven programming in .NET. Chris explains concepts like pub/sub, durable messaging, and the benefits of decoupled architectures for scaling and reliability.  The discussion also delves into advanced topics such as sagas, stateful consumers for orchestrating complex processes, and how MassTransit supports patterns like outbox and routing slips for ensuring transactional consistency. Chris highlights the importance of observability in distributed systems, sharing how MassTransit integrates with tools like OpenTelemetry to provide comprehensive monitoring. The episode includes advice on adopting event-driven approaches, overcoming leadership hesitancy, and ensuring secure and efficient implementations. Chris emphasizes the balance between leveraging cutting-edge tools and addressing real-world challenges in software architecture. Brought to you by IEEE Computer Society and IEEE Software magazine.

Dans cet épisde en audio et en vidéo (youtube.com/lescastcodeurs), Guillaume et Emmanuel discutent des 15 ans de Go, d'une nouvelle approche de garbage collecting, de LLMs dans les applications Java, dobservabilité, d'une attaque de chaine d'approvisionnement via javac et d'autres choses. Enregistré le 13 décembre 2024 Téléchargement de l'épisode LesCastCodeurs-Episode-319.mp3 News Langages Go fête son 15ème anniversaire ! https://go.dev/blog/15years discute les 15 ans la corrections de gotchas dans les for loops (notamment les variables étaient loop scoped) le fait que la compile echoue si on attend une version de go superieure seulement depuis go 1.21 en parallele de la gestion de la chaine d'outil (c'est en 2023 seulement!) opt-in telemetrie aussi recent Construire OpenJDK à partir des sources sur macOS https://www.morling.dev/blog/building-openjdk-from-source-on-macos/ de maniere surprenante ce n'est pas tres compliqué Papier sur l'aproche Mark-scavenge pour un ramasse miette https://inside.java/2024/11/22/mark-scavenge-gc/ papier de recherche utiliser l'accessibilité pour preuve de vie n'est pas idéal: un objet peut etre atteignable mais ne sera jamais accedé par le programme les regions les plus pauvres en objets vivant voient leurs objets bouger dans uen autre region et la regio libéré, c'est le comportement classique des GC deux methodes: mark evaguate qui le fait en deux temps et la liveness peut evoluer ; et scavenge qui bouge l'objet vivant des sa decouverte ont fait tourner via ZGC des experience pour voir les objects consideres vivants et bougés inutilement. resultats montrent un gros taux d'objets bougés de maniere inutile proposent un algo different ils marquent les objets vivants mais ne les bougent pas avant le prochain GC pour leur donner une change de devenir unreachable elimine beaucoup de deplacement inutiles vu que les objets deviennent non accessible en un cycle de GC jusquà 91% de reduction ! Particulierement notable dans les machines chargées en CPU. Les tokens d'accès court ou longs https://grayduck.mn/2023/04/17/refresh-vs-long-lived-access-tokens/ pourquoi des long access tokens (gnre refresh token) sont utilises pour des short lived dans oauth 2.0 refresh token simplifient la revocation: vu que seul le auth serveur a a verifier la révocation et les clients vérifient l'expiration et la validité de la signature refresh token ne sont envoyés que entre endpoints alors que les access tokens se baladent pas mal: les frontières de confiance ne sont pas traversées refresh token comme utilise infréquement, et donc peut etre protegee dans une enclave les changements de grants sont plus simple tout en restant distribuable histoire des access refresh token et access token permet de mieux tracer les abus / attaques les inconvenients: c'est plus compliqué en flow, the auth serveur est un SPOF amis mitigeable Java Advent est de retour https://www.javaadvent.com/calendar backstage Java integrite par defaut (et ses consequences sur l'ecosysteme) timefold (sovler) Les extensions JUNit 5 OpenTelemetry via Java Agent vs Micrometer analyse statique de code CQRS et les fonctionalités modernes de Java java simple (sans compilatrion, sans objet fullstack dev with quarkus as backend José Paumard introduit et explique les Gatherers dans Java 24 dans cette vidéo https://inside.java/2024/11/26/jepcafe23/ Librairies Micronaut 4.7, avec l'intégration de LangChain4j https://micronaut.io/2024/11/14/micronaut-framework-4-7-0-released/ Combiner le framework de test Spock et Cucumber https://www.sfeir.dev/back/spock-framework-revolutionnez-vos-tests-unitaires-avec-la-puissance-du-bdd-et-de-cucumber/ les experts peuvent écrire leurs tests au format Gherkin (de Cucumber) et les développeurs peuvent implémenter les assertions correspondantes avec l'intégration dans Spock, pour des tests très lisibles Spring 6.2 https://spring.io/blog/2024/11/14/spring-framework-6-2-0-available-now beans @Fallback améliorations sur SpELet sur le support de tests support de l'echape des property placeholders une initioalisation des beans en tache de fond nouvelle et pleins d'autres choses encore Comment créer une application Java LLM tournant 100% en Java avec Jlama https://quarkus.io/blog/quarkus-jlama/ blog de Mario Fusco, Mr API et Java et Drools utilise jlama + quarkus + langchain Explique les avantage de l'approche pure Java comme le cycle de vie unique, tester les modeles rapidement, securite (tout est in process), monolithe ahahah, observabilité simplifiée, distribution simplifiée (genre appli embarquée) etc Vert.x 5 en seconde incubation https://vertx.io/blog/eclipse-vert-x-5-candidate-2-released/ Support des Java modules (mais beacoup des modules vert.x eux-même ne le supportent pas support io_uring dans vert.x core le load balancing côté client le modele des callbacks n'est plus supporté, vive les Futur beaucoup d'améliorations autour de gRPC et d'autres choses Un article sur Spring AI et la multi modalite audio https://spring.io/blog/2024/12/05/spring-ai-audio-modality permet de voir les evolutions des APIs de Spring AI s'appluie sur les derniers modeles d'open ai des examples comme par exemple un chatbot voix et donc comment enregistrer la voix et la passer a OpenAI Comment activer le support experimental HTTP/3 dans Spring Boot https://spring.io/blog/2024/11/26/http3-in-reactor-2024 c'ets Netty qui fait le boulot puis Spring Netty l'article décrit les etapes pour l'utiliser dans vos applis Spring Boot ou Spring Cloud Gateway l'article explique aussi le cote client (app cliente) ce qui est sympa Infrastructure Un survol des offres d'observabilité http://blog.ippon.fr/2024/11/18/observabilite-informatique-comprendre-les-bases-2eme-partie/ un survol des principales offres d'observabilité Open source ou SaaS et certains outsiders Pas mal pour commencer à défricher ce qui vous conviendrait blog de ippon Web Sortie de Angular 19 https://blog.ninja-squad.com/2024/11/19/what-is-new-angular-19.0/ stabilité des APIs Signal APIs migration automatique vers signals composants standalone par défaut nouvelles APIs linkedSignal et resource de grosses améliorations de SSR et HMR un article également de Sfeir sur Angular 19 https://www.sfeir.dev/front/angular-19-tout-ce-quil-faut-savoir-sur-les-innovations-majeures-du-framework/ Angluar 19 https://www.sfeir.dev/front/angular-19-tout-ce-quil-faut-savoir-sur-les-innovations-majeures-du-framework/ composant standalone par default (limiter les problemes de dependances), peut le mettre en strict pour le l'imposer (ou planter) signalement des imports inutilisés @let pour les variables locales dans les templates linkedSignal (experimental) pour lier des signaux entre eux (cascade de changement suite a un evenement hydratation incrementale (contenu progressivement interactif avec le chargement - sur les parties de la page visible ou necessaires et event replay, routing et modes de rendu en rendy hybride, Hot module replacement etc The State of Frontend — dernière compilation des préférences des développeurs en terme de front https://tsh.io/state-of-frontend/ React en tête, suivi de Vue et Svelte. Angular seulement 4ème Côté rendering framework, Next.js a la majorité absolue, ensuite viennent Nuxt et Astro Zod est la solution de validation préférée Pour la gestion de date, date-fns est en tête, suivi par moment.js Côté state management, React Context API en première place, mais les suivants sont tous aussi pour React ! Grosse utilisation de lodash pour plein d'utilités Pour fetcher des resources distantes, l'API native Fetch et Axios sont les 2 vaincoeurs Pour le déploiement, Vercel est premier Côté CI/CD, beaucoup de Github Actions, suivi par Gitlab CI Package management, malgré de bonnes alternatives, NPM se taille toujours la part du lion Ecrasante utilisation de Node.js comme runtime JavaScript pour faire du développement front Pour ce qui est du typing, beaucoup utilisent TypeScript, et un peu de JSdoc, et la majorité des répondants pensent que TypeScript a dépassé JavaScript en usage Dans les API natives du navigateur, Fetch, Storage et WebSockets sont les APIs les plus utilisées La popularité des PWA devrait suivre son petit bonhomme de chemin En terme de design system, shadcn.ui en tête, suivi par Material, puis Bootstram Pour la gestion des styles, un bon mix de plain old CSS, de Tailwind, et de Sass/CSS Jest est premier comme framework de tests Les 3/4 des développeurs front utilisent Visual Studio Code, quant au quart suivant, c'est JetBrains qui raffle les miettes Pour le build, Vite récolte les 4/5 des voix ESLint et Prettier sont les 2 favoris pour vérifier le code   Parfois, on aimerait pouvoir tester une librairie ou un framework JavaScript, sans pour autant devoir mettre en place tout un projet, avec outil de build et autre. Julia Evans explore les différents cas de figure, suivant la façon dont ces librairies sont bundlées https://jvns.ca/blog/2024/11/18/how-to-import-a-javascript-library/ Certaines librairies permette de ne faire qu'un simple import dans une balise script Certaines frameworks sont distribués sous forme d'Universal Module Definition, sous CommonJS, d'ESmodule franchemet en tant que noob c'est compliqué quand même Data et Intelligence Artificielle L'impact de l'IA en entreprise et des accès aux documents un peu laxistes https://archive.ph/uPyhX l'indexing choppe tout ce qu'il peut et l'IA est tres puissante pour diriger des requetes et extraires les données qui auraient du etre plus restreintes Différentes manières de faire de l'extraction de données et de forcer la main à un LLM pour qu'il génère du JSON https://glaforge.dev/posts/2024/11/18/data-extraction-the-many-ways-to-get-llms-to-spit-json-content/ l'approche “je demande gentiment” au LLM, en faisant du prompt engineering en utilisant du function calling pour les modèles supportant la fonctionnalité, en particulier avant les approches de type “JSON mode” ou “JSON schema” ou effectivement si le modèle le supporte aussi, toujours avec un peu de prompting, mais en utilisant le “JSON mode” qui force le LLM a générer du JSON valide encore mieux avec la possibilité de spécifier un schema JSON (type OpenAPI) pour que le JSON en sortie soit “compliant” avec le schéma proposé Comment masquer les données confidentielles avec ses échanges avec les LLMs https://glaforge.dev/posts/2024/11/25/redacting-sensitive-information-when-using-generative-ai-models/ utilisation de l'API Data Loss Prevention de Google Cloud qui permet d'identifier puis de censurer / masquer (“redacted” en anglais) des informations personnelles identifiables (“PII”, comme un nom, un compte bancaire, un numéro de passeport, etc) pour des raison de sécurité, de privacy, pour éviter les brèche de données comme on en entend trop souvent parler dans les nouvelles On peut utiliser certains modèles d'embedding pour faire de la recherche de code https://glaforge.dev/posts/2024/12/02/semantic-code-search-for-programming-idioms-with-langchain4j-and-vertex-ai-embedding-models/ Guillaume recherche des bouts de code, en entrant une requête en langue naturel Certains embedding models supportent différents types de tâches, comme question/réponse, question en langue naturelle / retour sous forme de code, ou d'autres tâches comme le fact checking, etc Dans cet article, utilisation du modèle de Google Cloud Vertex AI, en Java, avec LangChain4j Google sort la version 2 de Gemini Flash https://blog.google/technology/google-deepmind/google-gemini-ai-update-december-2024/ La nouvelle version Gemini 2.0 Flash dépasse même Gemini 1.5 Pro dans les benchmarks Tout en étant 2 fois plus rapide que Gemini 1.5 Pro, et bien que le prix ne soit pas encore annoncé, on imagine également plus abordable Google présente Gemini 2 comme le LLM idéal pour les “agents” Gemini propose une vraie multimodalité en sortie (premier LLM sur le marché à le proposer) : Gemini 2 peut entrelacer du texte, des images, de l'audio Gemini 2 supporte plus de 100 langues 8 voix de haute qualité, assez naturelles, pour la partie audio Un nouveau mode speech-to-speech en live, où on peut même interrompre le LLM, c'est d'ailleurs ce qui est utilisé dans Project Astra, l'application mobile montrée à Google I/O qui devient un vrai assistant vocale en live sur votre téléphone Google annonce aussi une nouvelle expérimentation autour des assistants de programmation, avec Project Jules, avec lequel on peut discuter en live aussi, partager son code, comme un vrai pair programmeur Google a présenté Project Mariner qui est un agent qui est sous forme d'extension Chrome, qui va permettre de commander votre navigateur comme votre assistant de recherche personnel, qui va être capable de faire des recherches sur le web, de naviguer dans les sites web, pour trouver les infos que vous recherchez Cet autre article montre différentes vidéos de démos de ces fonctionnalités https://developers.googleblog.com/en/the-next-chapter-of-the-gemini-era-for-developers/ Un nouveau projet appelé Deep Research, qui permet de faire des rapports dans Gemini Advanced : on donne un sujet et l'agent va proposer un plan pour un rapport sur ce sujet (qu'on peut valider, retoucher) et ensuite, Deep Research va effectuer des recherches sur le web pour vous, et faire la synthèse de ses recherches dans un rapport final https://blog.google/products/gemini/google-gemini-deep-research/ Enfin, Google AI Studio, en plus de vous permettre d'expérimenter avec Gemini 2, vous pourrez aussi utiliser des “starter apps” qui montrent comment faire de la reconnaissance d'objet dans des images, comment faire des recherches avec un agent connecté à Google Maps, etc. Google AI Studio permet également de partager votre écran avec lui, en mobile ou en desktop, de façon à l'utiliser comme un assistant qui peut voir ce que vous faites, ce que vous coder et peut répondre à vos questions Méthodologies Un article de GitHub sur l'impact de la surutilisation des CPU sur la perf de l'appli https://github.blog/engineering/architecture-optimization/breaking-down-cpu-speed-how-utilization-impacts-performance/ c'est surprenant qu'ils ont des effets des 30% de perf c'est du a la non limit thermique, au boost de frequece qui en suit ils ont donc cherché le golden ratio pour eux autour de 60% ils prennent des morceaux de cluster kube poru faire tourner les workloads et ajoutent des wqorkload CPU artificiels (genre math) Sécurité Attaque de la chaîne d'approvisionnement via javac https://xdev.software/en/news/detail/discovering-the-perfect-java-supply-chain-attack-vector-and-how-it-got-fixed s'appuie sur l'annotation processeur l'annotation processors des dependances est chargé et executé au moment du build du projet et cherche les annotations processor dans le user classpath (via le pattern serviceloader) et donc si la dependance est attaquée et un annotation processor est ajouté ou modifié on a un vecteur d'attaque au moment de la compilation du projet ciblé des qu'on deparre l'IDE en gros workaround, activer -proc:none et activer les annotation processors explicitly dans votre outil de build certaines améliorations dans le JDK: le compilateur note qu'il execute un annotation processor dans java 23+ les annotation processors sont deactivés par defaut Conférences La liste des conférences provenant de Developers Conferences Agenda/List par Aurélie Vache et contributeurs : 19 décembre 2024 : Normandie.ai 2024 - Rouen (France) 20 janvier 2025 : Elastic{ON} - Paris (France) 22-25 janvier 2025 : SnowCamp 2025 - Grenoble (France) 24-25 janvier 2025 : Agile Games Île-de-France 2025 - Paris (France) 30 janvier 2025 : DevOps D-Day #9 - Marseille (France) 6-7 février 2025 : Touraine Tech - Tours (France) 21 février 2025 : LyonJS 100 - Lyon (France) 28 février 2025 : Paris TS La Conf - Paris (France) 20 mars 2025 : PGDay Paris - Paris (France) 20-21 mars 2025 : Agile Niort - Niort (France) 25 mars 2025 : ParisTestConf - Paris (France) 26-29 mars 2025 : JChateau Unconference 2025 - Cour-Cheverny (France) 28 mars 2025 : DataDays - Lille (France) 28-29 mars 2025 : Agile Games France 2025 - Lille (France) 3 avril 2025 : DotJS - Paris (France) 10-11 avril 2025 : Android Makers - Montrouge (France) 10-12 avril 2025 : Devoxx Greece - Athens (Greece) 16-18 avril 2025 : Devoxx France - Paris (France) 29-30 avril 2025 : MixIT - Lyon (France) 7-9 mai 2025 : Devoxx UK - London (UK) 16 mai 2025 : AFUP Day 2025 Lille - Lille (France) 16 mai 2025 : AFUP Day 2025 Lyon - Lyon (France) 16 mai 2025 : AFUP Day 2025 Poitiers - Poitiers (France) 24 mai 2025 : Polycloud - Montpellier (France) 5-6 juin 2025 : AlpesCraft - Grenoble (France) 11-13 juin 2025 : Devoxx Poland - Krakow (Poland) 12-13 juin 2025 : Agile Tour Toulouse - Toulouse (France) 12-13 juin 2025 : DevLille - Lille (France) 24 juin 2025 : WAX 2025 - Aix-en-Provence (France) 26-27 juin 2025 : Sunny Tech - Montpellier (France) 1-4 juillet 2025 : Open edX Conference - 2025 - Palaiseau (France) 18-19 septembre 2025 : API Platform Conference - Lille (France) & Online 2-3 octobre 2025 : Volcamp - Clermont-Ferrand (France) 6-10 octobre 2025 : Devoxx Belgium - Antwerp (Belgium) 16-17 octobre 2025 : DevFest Nantes - Nantes (France) 6 novembre 2025 : dotAI 2025 - Paris (France) 12-14 novembre 2025 : Devoxx Morocco - Marrakech (Morocco) 23-25 avril 2026 : Devoxx Greece - Athens (Greece) 17 juin 2026 : Devoxx Poland - Krakow (Poland) Nous contacter Pour réagir à cet épisode, venez discuter sur le groupe Google https://groups.google.com/group/lescastcodeurs Contactez-nous via twitter https://twitter.com/lescastcodeurs Faire un crowdcast ou une crowdquestion Soutenez Les Cast Codeurs sur Patreon https://www.patreon.com/LesCastCodeurs Tous les épisodes et toutes les infos sur https://lescastcodeurs.com/

Was bedeutet es eigentlich, Domain-driven Design (DDD) umzusetzen? Diese Episode beginnt die Reise durch ein vollständiges Beispiel und zeigt , wie die verschiedenen Techniken wie Event Storming und strategisches Design zusammen wirken, um den Aufbau von Anwendungen zu unterstützen. Das zeigt, wie man mit einem einfachen, aber vollständigen Ansatz mit DDD beginnen können. In dieser Episode geht es um taktisches Design, CQRS, Event Sourcing und hexagonale Architektur. Links Training Domain-driven Design saniert Legacy Folien Taktisches Domain-driven Design (DDD) Taktisches Domain-Driven Design mit Java und jMolecules mit Oliver Drotbohm Folgen zu Architecture Management Events, Event Sourcing und CQRS Video zu Kafka als Datenbank-Monolith Christian Stettler: Domain Events vs. Event Sourcing - Weshalb Domain Events und Event Sourcing nicht vermischt werden sollten Vaughn Vernon about Ports and Adapters and DDD

An airhacks.fm conversation with Gerald Venzl (@geraldvenzl) about: discussion about the evolution of Oracle's annual conference from OpenWorld to CloudWorld, the JavaOne conference, explanation of JDBC driver types and their evolution, Oracle's thin JDBC driver becoming the preferred option, availability of Oracle JDBC drivers on Maven Central, proprietary features of Oracle's JDBC driver including Continuous Query Notification (CQN) and Application Continuity, comparison of CQN to Change Data Capture (CDC) and CQRS patterns, Oracle's Flashback Data Archive for auditing and time travel capabilities, Oracle's Advanced Queuing and Transactional Event Queues, ORDS REST APIs, Oracle product page, Oracle JDBC client libraries, the plug-in mechanism implemented in early Java versions for JDBC drivers using Class.forName and static initializers, Gerald Venzl's online presence and recent blog post about running Oracle database on Raspberry Pi Gerald Venzl on twitter: @geraldvenzl

In dieser Folge widmen wir uns sehr tiefgehend dem Thema Domain-Driven Design. Falls dir das Thema noch neu ist, hör doch vorher in Folge 57 rein, „DDD, Event Sourcing und CQRS mit Golo Roden“.Domain-Driven Design, kurz DDD, ist kein neues Phänomen. In der Literatur existiert es bereits seit über 20 Jahren, aber gerade in der praktischen Anwendung hakt es noch häufig. Oftmals werden verschiedene Definitionen und Vorstellungen vermischt und Methodik mit Implementierung verwechselt.Um mit all diesen Vorurteilen und Missverständnissen aufzuräumen, haben wir uns Stefan Priebsch ins Studio eingeladen. Gemeinsam diskutieren wir nicht nur die Geschichte von DDD, sondern auch den aktuellen Stand und lauschen seinen Erfahrungen aus 20 Jahren Praxis zu diesem Thema.Schreibt uns! Schickt uns eure Themenwünsche und euer Feedback: podcast@programmier.barFolgt uns! Bleibt auf dem Laufenden über zukünftige Folgen und virtuelle Meetups und beteiligt euch an Community-Diskussionen. TwitterInstagramFacebookMeetupYouTubeMusik: Hanimo

Metalama This episode of The Modern .NET Show is supported, in part, by Metalama, reduce your boilerplate code by up to 15% with Metalama's C#-to-C# template engine and reduce your code complexity today! Show Notes "Essentially, when you look at it, what we are doing, we are not building software. We are changing it, we are maintaining it. Because when you look at the typical lifecycle of the application, enterprise one I would say, or any big system where you invest lots of time lots of money building it, you want to exploit this for 5-10-15 years hopefully. So when you look at the percentages, you're building something for one year and then you are using it for nine more years, let's say. It's a 10 year life cycle. So when you think about it, you spend 10 times... er, 10 percent of your time building something and 90 percent of the lifecycle of the application or the system responding to change requests, building new things, changing, adapting, and maintaining. So essentially, our job is not to build out. Our job is to sustain all these request changes. I think that's the first point we need to clear."— Dejan Miličić Welcome friends to The Modern .NET Show; the premier .NET podcast, focussing entirely on the knowledge, tools, and frameworks that all .NET developers should have in their toolbox. We are the go-to podcast for .NET developers worldwide, and I am your host: Jamie "GaProgMan" Taylor. In this episode, Dejan Miličić joined us to talk about the CQRS pattern, how it came from CQS, what CQS is and how it's related to Alan Kay's original ideas for object-oriented programming, being pragmatic as developers and engineers, the importance of system design and system's thinking, and how we all need to realise that our software lives on for years after we've pushed our changes to the repo. "So I, indeed, agree with you that people should pay more attention to system design. Start looking at the whole picture. And the extreme of this thinking would be: okay you will go into job interview, they will ask you about, I don't know, quick sort you, will implement it on the whiteboard, and then six months later on you will go and purchase or maybe download a NuGet package with with a quick sort implementation, because you know it makes sense; you don't want to implement something that have been implemented this many times before."— Dejan Miličić Whilst this episode doesn't focus on .NET per se, I think that the subjects that Dejan and I covered are incredibly important for anyone who wants to seriously level up their game. In fact, Dejan proved this point when he said: "We [are] all, like, containerised into our own small silos and working on our own without being aware of the whole system. When you look at what people go through when they prepare for job interviews at, I don't you know, Google, Facebook, nowadays Meta, Microsoft, you have all these books on the system design. And then they go, instead of, you know, going to the job interview after 20 years of experience and talking about what you do and what you know, people with 20 years of experience still sit down and learn and prepare for the system design interview. I'm not saying they shouldn't be preparing, but some of my colleagues told me that that was the first time in their careers that they started looking at the system design as a discipline."— Dejan Miličić Anyway, without further ado, let's sit back, open up a terminal, type in `dotnet new podcast` and we'll dive into the core of Modern .NET. Supporting the Show If you find this episode useful in any way, please consider supporting the show by either leaving a review (check our review page for ways to do that), sharing the episode with a friend or colleague, buying the host a coffee, or considering becoming a Patron of the show. Full Show Notes The full show notes, including links to some of the things we discussed and a full transcription of this episode, can be found at: https://dotnetcore.show/season-7/cqrs-system-maintainability-and-pragmatic-tech-choices-with-dejan-milicic/ Useful Links Dejan on Twitter: x.com/dejanmilicic Dejjan on LinkedIn: linkedin.com/in/dejanmilicic Music created by Mono Memory Music, licensed to RJJ Software for use in The Modern .NET Show Editing and post-production services for this episode were provided (in part) by MB Podcast Services Supporting the show: Leave a rating or review Buy the show a coffee Become a patron Remember to rate and review the show on Apple Podcasts, Podchaser, or wherever you find your podcasts, this will help the show's audience grow. Or you can just share the show with a friend. And don't forget to reach out via our Contact page. We're very interested in your opinion of the show, so please get in touch. You can support the show by making a monthly donation on the show's Patreon page at: https://www.patreon.com/TheDotNetCorePodcast.

Este conteúdo é um trecho do nosso episódio: “#192 Quando e por que usar CRUD ou CQRS”. Nele, Caio Martinez e Jefferson Fabrício, Desenvolvedores Líderes na dti digital, trazem exemplos práticos do uso do CQRS para divisão de eventos dentro de uma aplicação, oferecendo mais eficiência e segurança. Ficou curioso? Então, dê o play! Quer enviar uma dúvida ou ideia para o Entre Chaves? Mande uma mensagem para o nosso Linkedin ou pelo email entrechaves@dtidigital.com.br. Sua resposta pode aparecer em um dos nossos episódios!

Está em dúvida se usa CRUD ou CQRS no seu próximo projeto? Neste episódio, Caio Martinez e Jefferson Fabrício, Desenvolvedores Líderes na dti digital, desvendam as principais dúvidas por trás dessas duas siglas através das suas experiências. Dê o play e ouça agora! Quer enviar uma dúvida ou ideia para o Entre Chaves? Mande uma mensagem para o nosso Linkedin ou pelo email entrechaves@dtidigital.com.br. Sua resposta pode aparecer em um dos nossos episódios!

This interview was recorded for the GOTO Book Club.http://gotopia.tech/bookclubRead the full transcription of the interview hereUberto Barbini - Author of "From Objects to Functions" & Passionate Polyglot ProgrammerDuncan McGregor - Co-Author of "Java to Kotlin" & Independent ConsultantRESOURCESUbertohttps://twitter.com/ramtophttps://www.linkedin.com/in/ubertohttps://github.com/ubertohttps://medium.com/@ramtopDuncanhttps://twitter.com/duncanmcghttps://www.linkedin.com/in/duncan-mcgregor-a3038b6https://github.com/dmcghttp://www.oneeyedmen.comhttps://java-to-kotlin.devVideosHadi: https://youtu.be/BnTtjywqAX8Alan: https://youtu.be/D43PlUr1x_EAttila: https://youtu.be/14532OnVprwKen: https://youtu.be/M3qQFBGC9tkFelienne: https://youtu.be/ztdxlkmxpIQSam & James: https://youtu.be/_ehD4D7N4ZUDESCRIPTIONBuild applications quicker and with less effort using functional programming and Kotlin. Learn by building a complete application, from gathering requirements to delivering a microservice architecture following functional programming principles. Learn how to implement CQRS and EventSourcing in a functional way to map the domain into code better and to keep the cost of change low for the whole application life cycle.If you're curious about functional programming or you are struggling with how to put it into practice, this guide will help you increase your productivity composing small functions together instead of creating fat objects.* Book description: © Pragmatic ProgrammersRECOMMENDED BOOKSUberto Barbini • From Objects to FunctionsUberto Barbini & Marco Cantù • Mastering Kylix 2Duncan McGregor & Nat Pryce • Java to KotlinVenkat Subramaniam • Programming KotlinVenkat Subramaniam • Functional Programming in JavaTomasz Lelek & Jon Skeet • Software Mistakes & TradeoffsAshley Peacock • Creating Software with Modern Diagramming TechniquesTwitterInstagramLinkedInFacebookLooking for a unique learning experience?Attend the next GOTO conference near you! Get your ticket: gotopia.techSUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted daily!

This is the final part of the JCON interviews. Did I save the best for last? It's up to you to decide. In this episode, you'll hear Simon Martinelli, Nicolas Fränkel, Marcus Hellberg, Rick Ossendrijver, and Abdel Sghiouar. We talked about a bunch of topics, like evolving your APIs, GraphQL, Java versus Kotlin versus Rust, Vaadin, AI and ChatGPT, OpenRewrite, ErrorProne, Infrastructure, and a lot more. Content00:45 Simon Martinelli – Talks about CQRS, REST, APIs, JOOQ, Vaadin https://www.linkedin.com/in/simonmartinelli 09:08 Nicolas Fränkel - Talks about evolving your APIs, versioning an API, GraphQL, CQRS, REST, ProtoBuffers, Java versus Kotlin versus Rust versus …  https://www.linkedin.com/in/nicolasfrankel 19:11 Marcus Hellberg – Talks about Vaadin, Web development with 100% Java, AI and ChatGPT https://www.linkedin.com/in/marcushellberg 31:27 Rick Ossendrijver – Workshop and Talk about OpenRewrite and ErrorProne, Code analysis https://www.linkedin.com/in/rick-ossendrijver 35:48 Abdel Sghiouar – Talks about Infrastructure, Gateways, and Proxies, Java Community in Morocco, Devoxx Morocco  42:15 Conclusion

W tym odcinku "Patoarchitektów" rozmawiamy z Andrzejem Krzywdą, założycielem Arkency i guru Ruby on Rails, o tym, jak technologie ewoluują i stają się "legacy", ale też o tym, jak znaleźć w tym potencjał i odświeżyć starzejący się kod. Andrzej dzieli się z nami swoim doświadczeniem w uładnianiu zastanych projektów, wprowadzaniu refaktoryzacji i wykorzystywaniu nowoczesnych podejść jak DDD, CQRS czy Hotwire do ożywienia "starych kości". Prześwietlamy także, jak Ruby on Rails jest obecnie postrzegane i jak dzięki społeczności i narzędziom typu opensource można wywrzeć realny wpływ na rozwój technologii. Ta rozmowa to prawdziwa gratka nie tylko dla fanów Ruby, ale dla każdego, kto w technologiach webowych szuka czegoś więcej niż tylko kolejnego frameworka. Nasze sociale i linki Materiały do odcinka

Link e riferimenti episodio:Some thoughts on using CQRS without Event Sourcing: https://medium.com/@mbue/some-thoughts-on-using-cqrs-without-event-sourcing-938b878166a2___________________________________________________________________ Discover Learn Agile Practices: https://learnagilepractices.com/Subscribe to the newsletter: https://learnagilepractices.com/subscribeNeed help in developing your career in Software? Discover our coaching and mentorship program: https://learnagilepractices.com/coaching

Czy kilka twoich projektów dla różnych klientów ma dokładnie taką samą strukturę wewnętrzną, stosowane są dokładnie te same wzorce organizacji kodu i architektury? Albo wszędzie widzisz możliwość zastosowania CQRS, rozdziału na komendy i query, czy możliwość zaimplementowania taktycznych wzorców z DDD? W wielu przypadkach będzie to zapewne całkowicie uzasadnione, poza tymi, w których nie ma to większego sensu...Abraham Maslow kiedyś opisał to zjawisko mówiąc: dla człowieka, który dysponuje tylko młotkiem, wszystko, co spotyka zaczyna wyglądać jak gwóźdź. Idąc tym torem, posługiwanie się tylko jednym młotkiem nie jest ani wygodne, ani zdrowe.Po ostatnich odcinkach podcastu poświęconych architekturze, zapraszam na luźniejszą rozmowę z Piotrem Przybyłem o chorobach, które czasami można zauważyć w naszych projektach i zespołach. A rozmawiamy m.in. o ostrej zasadzie Pareto, projektowym "good enough" i kilku chorobach, które warto mieć na swojej developerskiej uwadze.Materiały dodatkowe:Cztery choroby, prezentacja Piotra z konferencji Boiling Frogs 2019Architecture antipatterns and how to beat them, część 1, prezentacja Łukasza Szydło z konferencji 4Developers 2017Architecture antipatterns and how to beat them, część 2, kontynuacja powyższej prezentacji

## SummaryIn questa parte della conversazione, sono stati affrontati diversi argomenti legati alla gestione degli eventi nel contesto del CQRS. Si è parlato della costruzione del Ritm 1 e della gestione degli eventi, con un focus sull'importanza di conservare gli eventi in modo corretto. È stato menzionato l'Event Roll Up come best practice per la gestione degli eventi. Inoltre, si è discusso degli aggregati e delle proiezioni nel contesto del CQRS. Infine, sono state esplorate le sfide nell'implementazione di CQRS e sono state presentate alcune tecnologie per la conservazione degli eventi, come EventStoreDB e Postgres.## TakeawaysLa corretta gestione degli eventi è fondamentale nel contesto del CQRS.L'Event Roll Up è una best practice per la gestione degli eventi.Gli aggregati e le proiezioni sono elementi chiave nel CQRS.La scelta delle tecnologie per la conservazione degli eventi dipende dalle esigenze specifiche del progetto.## Supportaci suhttps://www.gitbar.it/support## Paese dei balocchi- https://amzn.to/47QbhZM- https://hexdocs.pm/commanded/Commanded.html## Link amazon affiliatohttps://amzn.to/3XDznm1## Per favore ascoltaci usando una di queste app:https://podcastindex.org/apps## Contatti@brainrepo su twitter o via mail a https://gitbar.it.## CreditiLe sigle sono state prodotte da MondoComputazionaleLe musiche da Blan Kytt - RSPNSweet Lullaby by Agnese ValmaggiaMonkeys Spinning Monkeys by Kevin MacLeod

Ready to tackle the journey from monolith to microservices? Get some pointers from the pros first! In this episode, Sara is joined by Frédéric Bouvet, a software engineer with 12 years of experience. Frédéric has worked extensively with CQRS (Command Query Responsibility Segregation), DDD (Domain-Driven Design), and event sourcing patterns, particularly in the context of the Axon Framework and Axon Server. The two discuss Frédéric's journey in adopting these patterns, especially in the context of migrating a monolith to a secure microservices architecture at SlimPay, a payment company based in Paris. Frédéric shares insights into his experience with CQRS, emphasizing its benefits for optimizing both reading and writing performance. He explains the challenges of introducing these patterns to a team that was accustomed to CRUD operations, highlighting the importance of knowledge sharing, pair programming, and code reviews in overcoming the learning curve. The conversation delves into the process of migrating from a monolith to microservices, with Frédéric outlining steps such as isolating the domain, breaking external references, and implementing a switch mechanism for data synchronization.  Frédéric also touches upon the challenges of evaluating costs but emphasizes the gains in maintainability and development efficiency.  Overall, the episode provides valuable insights into the practical implementation of CQRS, DDD, and event sourcing in the context of microservices, offering a real-world perspective on the challenges and benefits of such architectural choices. Be sure to tune in!   Connect with Sara on LinkedIn and Twitter.  Connect with Frederic on LinkedIn.  Learn more about Axon at axoniq.io

Genevieve Hayes Consulting Episode 22: Software Engineering for Data Science Data science sits at the intersection of Computer Science and Statistics, so it comes as no surprise that many of the best data scientists have a computer science or software development background. And those that don't? Well, there's a lot they can learn from software developers.In this episode, Ethan Garofolo joins Dr Genevieve Hayes to discuss techniques from software engineering and software development that you can use to become a better data scientist. Guest Bio Ethan Garofolo is a software developer and software architect, specialising in microservice-based projects and using Lean and DevOps principles to make software development teams more effective. He is the author of Practical Microservices: Build Event-Driven Architectures with Event Sourcing and CQRS and runs the Utah Microservices Meetup group. Talking Points What is the difference between a software engineer, software developer and software architect?The impact of team structure and communications on software design.How Lean and DevOps principles can be used to make technical teams run more effectively.The benefits of pair programming and mob programming.What is test-driven development and how can it be used to enhance the quality of data science outputs?Using ChatGPT/AI to enhance developer capabilities. Links Ethan’s WebsiteConnect with Ethan on LinkedInFollow Ethan on TwitterFollow Ethan on Twitch Connect with Genevieve on LinkedInBe among the first to hear about the release of each new podcast episode by signing up HERE The post Episode 22: Software Engineering for Data Science first appeared on Genevieve Hayes Consulting and is written by Dr Genevieve Hayes.

Data science sits at the intersection of Computer Science and Statistics, so it comes as no surprise that many of the best data scientists have a computer science or software development background. And those that don't? Well, there's a lot they can learn from software developers.In this episode, Ethan Garofolo joins Dr Genevieve Hayes to discuss techniques from software engineering and software development that you can use to become a better data scientist.Guest BioEthan Garofolo is a software developer and software architect, specialising in microservice-based projects and using Lean and DevOps principles to make software development teams more effective. He is the author of Practical Microservices: Build Event-Driven Architectures with Event Sourcing and CQRS and runs the Utah Microservices Meetup group.Talking PointsWhat is the difference between a software engineer, software developer and software architect?The impact of team structure and communications on software design.How Lean and DevOps principles can be used to make technical teams run more effectively.The benefits of pair programming and mob programming.What is test-driven development and how can it be used to enhance the quality of data science outputs?Using ChatGPT/AI to enhance developer capabilities.LinksEthan's WebsiteConnect with Ethan on LinkedInFollow Ethan on TwitterFollow Ethan on TwitchConnect with Genevieve on LinkedInBe among the first to hear about the release of each new podcast episode by signing up HERE

An airhacks.fm conversation with Roni Dover (@doppleware) about: enjoying Sword of Aragon game, writing text games then graphics games, learning .net then Java, managing complexity, the problem solving skills over programming language, learning Ruby and python, writing J2ME applications, writing purpose driven and simple code, Domain Driven, CQRS and Event Sourcing, the challenges of polyglot programming, BDD Bug Driven Development and continuous feedback, the wrong focus on unit tests, pretty, but not useful dashboards, EMF the Embedded Metric Format, The Director of Enterprise Architecture, there was no google analytics for code, improving your code with observability, the impact of code changes to traces, starting digma.ai and “Java First”, the airhacks discord server, OpenTelemetry instrumentation, automatic analysis of opentelemetry data, "#49 KISS Java EE, MicroProfile, AI, (Deep) Machine Learning" with Pavel Pscheidl, Digma Beta Program, Continuous Feedback Slack Group, Continuous Feedback In Java Roni Dover on twitter: @doppleware

- beware fast talkers, as Ray Dalio says in Principles https://www.principles.com/ (as a tweet: https://twitter.com/RayDalio/status/1599056902637248514 )- beware pattern obsessives (any pattern, architecture, SOLID, CQRS, Event Sourcing, Outside-in testing, you name it, someone wears it as a badge)- evolve your architecture - YAGNI, but do think ahead- currently available for c# contracts- building rustworkshop.co

Sara spoke with Spring developer advocate Josh long. Josh talked about his days pre-Spring and why he decided to join the team at Spring.io. He also talked about the reasons why he has stayed with the team and what excites him about the community. Sara asked Josh how he learned about Axon, what that relationship has been, and why he and Allard Buijze wrote the Spring Autoconfiguration for Axon Framework. They then discussed Domain-Driven Architecture, CQRS, Event-Driven Architecture, and how these patterns can help developers.  Josh Long will be our keynote speaker at our September 28th, 2023, conference in Amsterdam. We hope to see you all there.    Connect with Josh on Twitter and LinkedIn.  Connect with Sara on LinkedIn.    Learn more about Axon at axoniq.io

CQRS, czyli Command Query Responsibility Segregation, jest wzorcem wyjątkowo popularnym i powszechnie stosowanym w wielu systemach. Mało kto jednak sięgnął po oryginalny dokument autorstwa Grega Younga, który opisuje założenia tego konceptu architektonicznego i z czasem obrósł on kilkoma mitami.Dziś w podkaście ponownie gości Oskar Dudycz, z którym na tapet weźmiemy zarówno mity jak i fakty dotyczące wzorca CQRS. A gdy przy drugim mikrofonie pojawia się Oskar, to wiadomo, że będzie do bólu pragmatycznie...W tym odcinku rozmawiamy m.in. na temat:czym jest wzorzec CQRS i jaki ma związek z językiem Eiffel i ideą CQS Bertranda Meyera,związku z wzorcem Command & Command Handler,xszeregu mitów, którymi CQRS obrósł na przestrzeni lat, np. koniecznością stosowania asynchroniczności,różnych możliwych sposobach, w jaki CQRS może zostać zaimplementowany w systemie.Materiały dodatkowe:CQRS, oryginalny dokument Grega Younga, opisujący koncept CQRSCQRS Bliki, artykuł na bliki Martina Fowlera o omawianym wzorcuCQRS facts and myths explained, artykuł na blogu Oskara na poruszony w rozmowie tematOd CRUD do CQRS w praktyce, prezentacja Oskara z konferencji bITconf 2022Zapraszam Cię także do odwiedzenia moich innych miejsc w internecie:https://twitter.com/mariuszgilhttps://instagram.com/mariuszgil_dev/https://youtube.com/c/MariuszGil

Andrew Stone of Oxide Engineering joined Bryan, Adam, and the Oxide Friends to talk about his purpose-built, replay debugger for the Oxide setup textual UI. Andrew borrowed a technique from his extensive work with distributed systems to built a UI that was well-structured... and highly amenable to debuggability. He built a custom debugger "in a weekend"!Some of the topics we hit on, in the order that we hit them: tui-rs Crossterm The reedline crate Episode about the "Sidecar" switch Elm time-travel debugging Replay.io Devtools.fm episode on Replay.io AADEBUG conference California horse meat law The (lightly) edited live chat from the show: MattCampbell: I'm gathering that this is more like the fancy pseudo-GUI style of TUI, which is possibly bad for accessibility ahl: we are also building with accessibility in mind, stripping away some of the non-textual elements optionally MattCampbell: oh, cool ahl: Episode about the "Sidecar" switch: https://github.com/oxidecomputer/oxide-and-friends/blob/master/2021_11_29.md MattCampbell: ooh! That kind of recording is definitely better for accessibility than a video. uwaces: Were you inspired by Elm? (The programming language for web browsers?) bcantrill: Here's Andrew's PR for this, FWIW: oxidecomputer/omicron#2682 uwaces: Elm has a very similar model. They have even had a debugger that let you run events in reverse: https://elm-lang.org/news/time-travel-made-easy bch: I'm joining late - 1) does this state-machine replay model have a name 2) expand on (describe ) the I/o logic separation distinction? ahl: http://dtrace.org/blogs/ahl/2015/06/22/first-rust-program-pain/ zk: RE: logic separation in consensus protocols: the benefit of seperating out the state machine into a side-effect free function allows you to write a formally verified implementation in a pure FP lang or theorem prover, and then extract a reference program from the proof. we're going to the zoo: lol i'm a web dev && we do UI tests via StorybookJS + snapshots of each story + snapshots of the end state of an interaction ig: At that point you could turn the recording into an “expect test”. https://blog.janestreet.com/the-joy-of-expect-tests/ we're going to the zoo: TOFU but for tests

Today on Elixir Wizards, Marcelo Dominguez, co-founder at Mimiquate, joins us to parse the particulars of command query responsibility segregation (CQRS). Mimiquate is a specialized team of developers providing solutions for their clients with Elixir, Ruby on Rails, and Ember. Tune in to learn the benefits and potential applications of CQRS. *Please remember to take our LISTENER SURVEY (https://smr.tl/survey2022) so we can come back bigger and better for Season 10 – Coming in early 2023!! * The Wizards catch up with Marcelo and hear about ElixirConf Uruguay and Advent of Code 2022 Marcelo and the hosts run through their experience with CQRS and event sourcing The definition of CQRS What is the elevator pitch for CQRS Marcelo distinguishes between database writes and reads What are some limitations of the CRUD pattern How to know whether your application will benefit from the CQRS pattern What tools are in the Elixir ecosystem for implementing CQRS How to quickly recover from outages within a mature CQRS application How multi-node distribution impact CQRS architecture Links Mentioned in Today's Episode: Eventsourcing and CQRS in Elixir (https://www.youtube.com/watch?v=NTzP_5CHqKk) CQRS Pattern (Microsoft) (https://learn.microsoft.com/en-us/azure/architecture/patterns/cqrs) Commanded (Hex Docs) (https://hexdocs.pm/commanded/Commanded.html) Advent of Code (https://adventofcode.com/) Marcelo's Advent of Code Gist for Day 1 (https://gist.github.com/marpo60/bcf7dd45003adfe01b5581d03157a5de) Marcelo Dominguez on LinkedIn — https://uy.linkedin.com/in/marpo60 Marcelo Dominguez on Twitter — https://twitter.com/marpo60 Marcelo Dominguez on GitHub – https://github.com/marpo60 Mimiquate – https://www.mimiquate.com/ SmartLogic — https://smartlogic.io/ SmartLogic Twitter — https://twitter.com/smartlogic

Adam Dymitruk, CEO and founder of Adaptech Group, joins host Jeff Doolittle for an exploration of the event modeling approach to discovering requirements and designing software systems. Adam explains how the structured approach eliminates the specifics of implementation details and technology decisions, enabling clearer communication for all stakeholders while keeping conversations focused on the business opportunity. Using concrete examples of event modeling in practice, they examine event modeling in the context of other related approaches and methodologies, including event sourcing, event storming, CQRS, and domain-driven design.  

An airhacks.fm conversation with Goran Opacic (@goranopacic) about: what is a database, everything is a database, S3 queries with Athena, glue crawler on S3, Cloudflare Quiche, Kafka vs. Kinesis, proprietary managed AWS services, different writing and reading paths, openJDK CRaC (Coordinated Restore at Checkpoint), Oracle's Aurora JVM, Amazon Aurora Serverless, the cloud is slower than your local machine, scaling is about limits, AQUA (Advanced Query Accelerator), CQRS is a cloud-native pattern, CDC on premise and in the cloud Goran Opacic on twitter: @goranopacic

In this episode of season 2, we're talking about CQRS (Command and Query Responsibility Segregation) pattern

In today's all-panelist episode, we take a shot at demystify domain-driven design.  We discuss several books and some concepts that stand out in those texts.  How easy or hard do Elixir and Phoenix make it to apply DDD principles?  We give our experience with taking these concepts and putting them into practice, and give some tips and resources for getting started. Some of the topics covered: Tactical vs. strategic domain-driven design  Event Storming Bounded Contexts Accidental vs Intentional complexity Connect with Adi aditya7iyengar@gmail.com Sponsors Top End Devs Coaching | Top End Devs Links Domain-Driven Design: Tackling Complexity in the Heart of Software Domain-Driven Design Distilled Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F# EventStorming DDD, Hexagonal, Onion, Clean, CQRS, ... How I put it all together Picks Adi- GitHub - sasa1977/boundary Adi- Mix: Using Xref to Enforce better Design Adi- Macro - Elixir v1.13.4 Adi- digraph Adi - Three people looking for jobs - reach out to me to connect with them (sr. Elixir engineer, two Jr. Elixir engineers, and others too) Adi- Assassin's Creed Valhalla for Xbox One, PS4, PC & More | Ubisoft (US) Sascha- Virtual Domain-Driven Design Sascha- KanDDDinsky - The art of business software Sascha- Citizen Sleeper on Steam

В 31 выпуске подкаста Javaswag поговорили с Антоном Батяевым о финтехе, MBA и переходе в продукт оунера 00:01:42 В чем специфика Финтеха? Что отличает от других проектов? 00:05:15 Финансовая математика на Java 00:08:17 Терминология в финтехе - деривативы, фьючерсы, опционы, свопы, риск менеджмент 00:20:46 Типовая архитектура финтех проекта 00:31:20 Почему остался в финтехе? 00:37:33 Чем отличается инвест банкинг от трейдинговой системы 00:46:01 Для чего нужен MBA? 00:51:00 Java Oracle Certificate, Java Teacher at GeekBrains 00:57:02 Revolut. Риск менеджмент с нуля. Переход в продукт оунера 01:04:23 Метрики продукт оунера 01:09:33 Технический/Бизнес бэкграунд продукт оунера 01:20:29 Бест практисы финтеха: CI/CD/QA 01:27:12 Onboarding 01:31:09 Архитектура CQRS Ссылки от гостя: Сайт: batiaev.com/ Финансовая математика для финтеха - https://www.youtube.com/playlist?list=PLwjJEuRWaJcIetm_s-qvqIy2_6l3YF7Qa Современный валютный рынок - https://habr.com/ru/company/dbtc/blog/467415/ Матчинг ордеров на Java - https://github.com/fintecy/exchange-core Маркет дата коннекторы - https://github.com/fintecy/connectors Миллион котировок в секунду на Java - https://www.youtube.com/watch?v=j3wFOmRmSeg CQRS и Event Sourcing от Мартина Томпсона - https://www.youtube.com/watch?v=RlwO6CJbJjQ Event streaming Revolut Way - https://medium.com/revolut/event-streaming-the-revolut-way-9d928005ddf7 Вакансии https://jobs.lever.co/revolut/530d3bfd-bdca-4390-8f8a-bc88ddc1eb51 Гость - https://github.com/batiaev Кип сейф! 🖖

Remember: you can also always follow the show on Twitter @dotnetcoreshow, and the shows host on Twitter @podcasterJay or visit our Contact page. Welcome to season 4 of the award-winning .NET Core Podcast! Check that link for proof. Hello everyone and welcome to The .NET Core Podcast is a podcast where we reach into the core of the .NET technology stack and, with the help of the .NET community, present you with the information that you need in order to grok the many moving parts of one of the biggest cross-platform, multi-application frameworks on the planet. I am your host, Jamie "GaProgMan" Taylor. In this episode, I talked with Paul Michaels about Software Architecture and how important it is to get the architecture right before writing code. Paul has recently published a new book on the subject called "Software Architecture by Example: Using C# and .NET" which covers CQRS, event sourcing, distributed systems, and distributed transactions, to name just a few. Along the way we covered ubiquitous language, living documentation, and keeping a log of the rationale behind why you made the decisions that you did when building your applications and how this can help other devs when they have the "wtf" moment while reading your code. After we had finished recording, Paul passed along a discount code for his book. You can only get the discount code by heading to the show notes for this episode and scrolling to the bottom of the transcription. It will be listed in the "useful links" section. The full show notes, including links to some of the things we discussed and a full transcription of this episode, can be found at https://dotnetcore.show/episode-103-software-architecture-with-paul-michaels   Useful Links from the episode: Paul's blog Paul on Twitter Software Architecture by Example: Using C# and .NET Remember to rate and review the show on Apple Podcasts, Podchaser, or wherever you find your podcasts, this will help the show's audience grow. Or you can just share the show with a friend. And don't forget to reach out via our Contact page. We're very interested in your opinions of the show, so please do get in touch. You can support the show by making a monthly donation on the show's Patreon page at: https://www.patreon.com/TheDotNetCorePodcast

In this episode Adi and Sascha dig deeper into what it means to consume and build APIs in Elixir and how a RESTful approach compares to choosing GraphQL as your weapon of choice. Along the way they discuss common pitfalls when building APIs (spoiler: one is caching), how to test all of this, and what their personal preferences and experiences are in creating APIs in Elixir. Sponsors Top End Devs Coaching | Top End Devs Links Finch - Finch v0.12.0  HTTPoison - HTTPoison v1.8.1 GitHub - elixir-plug/plug_cowboy: Plug adapter for the Cowboy web server Instant GraphQL APIs on your data | Built-in Authz & Caching JWT.IO DDD, Hexagonal, Onion, Clean, CQRS, ... How I put it all together Protocol Buffers | Google Developers GitHub - parroty/exvcr: HTTP request/response recording library for elixir, inspired by VCR. Boston Elixir June 2021 - Adi Iyengar - Levels of testing API calls How I deal with behaviours and boilerplate - Sascha Wolf A guide to fuzz testing Picks Adi- Reach out if you're hiring Elixir devs! (aditya7iyengar@gmail.com) Adi- Buy a punching bag for both workout/releasing frustration Adi- Testing Elixir Sascha- Deep Rock Galactic

Greg Young is an independent consultant and serial entrepreneur. He has 10-plus years of varied experience in computer science from embedded operating systems to business systems and he brings a pragmatic and often unusual viewpoint to discussions. Greg coined the term “CQRS” (Command Query Responsibility Segregation) and it was instantly picked up by the community who have elaborated upon it ever since. He's a frequent contributor to InfoQ, a speaker/trainer at Skills Matter, and also a well-known speaker at international conferences.   Topics of Discussion: [3:24] Greg talks about being poached from university and his path to computer science, starting in the lottery and horse racing systems. [7:25] Greg defines CQRS at the base level. [9:24] What is event sourcing? [11:25] How does it look in database technology? [19:19] How does asynchronous processing work with event sourcing? [22:44] Greg talks about causation ID and correlation ID. [26:49] If someone is running on Azure, what technology would be associated with the stream of event sourcing? [27:27] When you're event sourcing, your events are your concept of truth. [28:15] What's the relationship between event sourcing and CQRS? [31:16] How has Greg's method of explaining these concepts changed over time? [31:36] When you teach something, you both get a better understanding of the thing that you're teaching, and you get a better understanding of how to teach it to somebody.   Mentioned in this Episode: Architect Tips — New video podcast! Azure DevOps Clear Measure (Sponsor) .NET DevOps for Azure: A Developer's Guide to DevOps Architecture the Right Way, by Jeffrey Palermo — Available on Amazon! Jeffrey Palermo's YouTube Jeffrey Palermo's Twitter — Follow to stay informed about future events! Greg Young Twitter Greg Young GitHub Event Store Greg Young YouTube   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.

Believe it or not, software development is not an easy job. Each business domain is different, you are constantly learning something new and it takes work to stay on top of the right patterns and practices. How do you learn the right patterns and practices though? Maybe you read a lot of books, watch a lot of videos, or you go to meetups and conferences. The thing is those resources only take you so far and you will find that there are things you still don't know. Hamed Shirbandi created TaskoMask to help him understand .NET patterns and practices and to show examples of real world challenges. In this episode we discuss how he architected the open-source project and some of the different technologies that he used. What have you had to learn by doing? Let us know on Twitter at @dotnet_Podcast. Sponsors Top End Devs Coaching | Top End Devs Links Real-world open-source project based on .NET 6 with DDD, ES, CQRS, Testing concepts GitHub: hamed-shirbandi/TaskoMask Twitter: @hamed_shirbandi * Contact Hamed at hamed.shirbandi@gmail.com Picks Caleb- Watch Banshee - Season 1 | Prime Video Hamed- Software Engineer vs. Developer: What's the Difference? | Indeed.com Wai- Watch The Boys - Season 3 | Prime Video

Talentgrid'in katkılarıyla sezonun onikinci ve son bölümü yayında!Domain Driven Design mimarisinin temel yapı taşlarından olan event sourcing konusunu ele alıyoruz.      Event Sourcing'in varoluş amacı nedir?Event Sourcing ne gibi ölçeklerde etkilidir? Eventlerimi tasarlarken nasıl bir yöntem izlemeliyim? Event Sourcing yaparken kaydedilen veriyi nasıl yönetebilirim? https://talentgrid.io/codefiction

This interview was recorded for GOTO Unscripted at CodeNode in London.gotopia.techRead the full transcription of this interview hereAudun Fauchald Strand - Principal Engineer at NAVKevlin Henney - Consultant, Programmer, Keynote Speaker, Technologist, Trainer & WriterDESCRIPTIONAudun Fauchald Strand, principal engineer at NAV (Norwegian Labour and Welfare Administration), shares the story of how they modernized their long-running open source platform NAIS.In their conversation, Audun and Kevlin Henney touch on topics such as how to organize massive amounts of data and if legacy code can be considered as something good. You'll also find out how open source fits in a large governmental software team that focuses on transparency.RECOMMENDED BOOKSKevlin Henney & Trisha Gee • 97 Things Every Java Programmer Should KnowKevlin Henney • 97 Things Every Programmer Should KnowHenney & Monson-Haefel • 97 Things Every Software Architect Should KnowHenney, Buschmann & Schmidt • Pattern-Oriented Software Architecture Volume 5Eric Evans • Domain-Driven DesignZhamak Dehghani • Data MeshSam Newman • Monolith to MicroservicesSam Newman • Building MicroservicesRonnie Mitra & Irakli Nadareishvili • Microservices: Up and RunningMitra, Nadareishvili, McLarty & Amundsen • Microservice ArchitectureRishu Mehra • What is Data ObservabilityTwitterLinkedInFacebookLooking for a unique learning experience?Attend the next GOTO conference near you! Get your ticket at gotopia.techSUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted almost daily.Discovery MattersA collection of stories and insights on matters of discovery that advance life...Listen on: Apple Podcasts Spotify Health, Wellness & Performance Catalyst w/ Dr. Brad CooperLooking for a catalyst to optimize your health, wellness & performance? You've found it!!Listen on: Apple Podcasts Spotify

Talentgrid'in katkılarıyla sezonun onbirinci bölümü yayında!DDD mimarisinin en önemli örüntülerinden olan CQRS (Command Query Responsibility Segregation) kavramını detaylandırıyoruz. CQRS ne gibi durumlarda kullanılmalıdır?CQRS hangi problemleri çözüyor?Fat events vs. Thin eventsCQRS yerine kullanılabilecek alternatifler nelerdir? https://talentgrid.io/codefiction

If you are familiar with the Event Sourcing and CQRS patterns, then you know that they are extremely powerful, but can be quite complex to implement correctly. Davide Mauri joins Lara Rubbelke to show temporal tables give you the same benefits without the related challenges. Chapters 00:00 - Introduction 01:28 - Demo using temporal tables 06:11 - Demo using 'as of' 07:36 - Demo for a range of time 08:32 - Wrap-up Recommended resources Getting started with temporal tables Configure temporal retention policy Azure SQL Database Create a Pay-as-You-Go account (Azure) Create a free account (Azure) Connect Twitter: Lara Rubbelke | @SQLGal Twitter: Davide Mauri | @MauriDB Twitter: Azure Friday | @AzureFriday

If you are familiar with the Event Sourcing and CQRS patterns, then you know that they are extremely powerful, but can be quite complex to implement correctly. Davide Mauri joins Lara Rubbelke to show temporal tables give you the same benefits without the related challenges. Chapters 00:00 - Introduction 01:28 - Demo using temporal tables 06:11 - Demo using 'as of' 07:36 - Demo for a range of time 08:32 - Wrap-up Recommended resources Getting started with temporal tables Configure temporal retention policy Azure SQL Database Create a Pay-as-You-Go account (Azure) Create a free account (Azure) Connect Twitter: Lara Rubbelke | @SQLGal Twitter: Davide Mauri | @MauriDB Twitter: Azure Friday | @AzureFriday

About VenkatVenkat Venkataramani is CEO and co-founder of Rockset. In his role, Venkat helps organizations build, grow and compete with data by making real-time analytics accessible to developers and data teams everywhere. Prior to founding Rockset in 2016, he was an Engineering Director for the Facebook infrastructure team that managed online data services for 1.5 billion users. These systems scaled 1000x during Venkat's eight years at Facebook, serving five billion queries per second at single-digit millisecond latency and five 9's of reliability. Venkat and his team also created and contributed to many noted data technologies and open-source projects, including Facebook's TAO distributed data store, RocksDB, Memcached, MySQL, MongoRocks, and others. Prior to Facebook, Venkat worked on tools to make the Oracle database easier to manage. He has a master's in computer science from the University of Wisconsin-Madison, and bachelor's in computer science from the National Institute of Technology, Tiruchirappalli.Links Referenced: Company website: https://rockset.com Company blog: https://rockset.com/blog TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: This episode is sponsored by our friends at Revelo. Revelo is the Spanish word of the day, and its spelled R-E-V-E-L-O. It means “I reveal.” Now, have you tried to hire an engineer lately? I assure you it is significantly harder than it sounds. One of the things that Revelo has recognized is something I've been talking about for a while, specifically that while talent is evenly distributed, opportunity is absolutely not. They're exposing a new talent pool to, basically, those of us without a presence in Latin America via their platform. It's the largest tech talent marketplace in Latin America with over a million engineers in their network, which includes—but isn't limited to—talent in Mexico, Costa Rica, Brazil, and Argentina. Now, not only do they wind up spreading all of their talent on English ability, as well as you know, their engineering skills, but they go significantly beyond that. Some of the folks on their platform are hands down the most talented engineers that I've ever spoken to. Let's also not forget that Latin America has high time zone overlap with what we have here in the United States, so you can hire full-time remote engineers who share most of the workday as your team. It's an end-to-end talent service, so you can find and hire engineers in Central and South America without having to worry about, frankly, the colossal pain of cross-border payroll and benefits and compliance because Revelo handles all of it. If you're hiring engineers, check out revelo.io/screaming to get 20% off your first three months. That's R-E-V-E-L-O dot I-O slash screaming.Corey: This episode is sponsored in part by LaunchDarkly. Take a look at what it takes to get your code into production. I'm going to just guess that it's awful because it's always awful. No one loves their deployment process. What if launching new features didn't require you to do a full-on code and possibly infrastructure deploy? What if you could test on a small subset of users and then roll it back immediately if results aren't what you expect? LaunchDarkly does exactly this. To learn more, visit launchdarkly.com and tell them Corey sent you, and watch for the wince.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. Today's promoted guest episode is one of those questions I really like to ask because it can often come across as incredibly, well, direct, which is one of the things I love doing. In this case, the question that I am asking is, when you look around at the list of colossal blunders that people make in the course of careers in technology and the rest, it's one of the most common is, “Oh, yeah. I don't like the way that this thing works, so I'm going to build my own database.” That is the siren call to engineers, and it is often the prelude to horrifying disasters. Today, my guest is Venkat Venkataramani, co-founder and CEO at Rockset. Venkat, thank you for joining me.Venkat: Thanks for having me, Corey. It's a pleasure to be here.Corey: So, it is easy for me to sit here in my beautiful ivory tower that is crumbling down around me and use my favorite slash the best database imaginable, which is TXT records shoved into Route 53. Now, there are certainly better databases than that for most use cases. Almost anything really, to be honest with you, because that is a terrifying pattern; good joke, terrible practice. What is Rockset as we look at the broad landscape of things that store data?Venkat: Rockset is a real-time analytics platform built for the cloud. Let me break that down a little bit, right? I think it's a very good question when you say does the world really need another database? Don't we have enough already? SQL databases, NoSQL databases, warehouses, and lake houses now.So, if you really break it down, the first digital transformation that happened in the '80s was when people actually retired pen and paper records and started using a relational database to actually manage their business records and what have you instead of ledgers and books and what have you. And that was the first digital transformation. That was—and Oracle called the rows in a table ‘records' for a reason. They're called records to this date. And then, you know, 20 years later, when all businesses were doing system of record and transactions and transactional databases, then analytics was born, right?This was, like, the whole reason why I wanted to make better data-driven business decisions, and BI was born, warehouses and data lakes started becoming more and more mainstream. And there was really a second category of database management systems because the first category it was very good at to be a system of record, but not really good at complex analytics that businesses are asking to be able to guide their decisions. Fast-forward 20 years from then, the nature of applications are changing. The world is going from batch to real-time, your data never stops coming, advent of Apache Kafka and technologies like that, 5G, IoTs, data is coming from all sorts of nooks and corners within an enterprise, and now customers in enterprises are acquiring the data in real-time at a scale that the world has never seen before.Now, how do you get analytics out of that? And then if you look at the database market—entire market—there are still only two large categories of databases: OLTP databases for transaction processing, and warehouses and data lakes for batch analytics. Now suddenly, you need the speed of OLTP at the scale of batch, right, in terms of, like, complexity of compute, complexity of storage. So, that is really why we thought the data management space needs that third leg, and we call it real-time analytics platform or real-time analytics processing. And this is where the data never stops coming; the queries never stopped coming.You need the speed and the scale, and it's about time we innovate and solve the problem well because in 2015, 2016, when I was researching for this, every company that was looking to solve build applications that were real-time applications was building a custom Rube Goldberg machine of sorts. And it was insanely complex, it was insanely expensive. Fast-forward now, you can build a real-time application in a matter of hours with the simplicity of the cloud using Rockset.Corey: There's a lot to be said that the way we used to do things after the first transformation and we got into the world of batch processing, where—in the days of punch cards, which was a bit before my time and I believe yours as well—where they would drop them off and then the next day, or two days, they would come back later after the run, they would get the results only to figure out syntax error because you put the wrong card first or something like that. And it was maddening. In time, that got better, but still, nightly runs have become a thing to the point where even now, by default, if you wind up looking at the typical timing of a default Linux install, for example, you see that in the middle of the night is when a bunch of things will rotate when various cleanup jobs get done, et cetera, et cetera. And that seemed like a weird direction to go in. One of the most famous Google April Fools Day jokes was when they put out their white paper on MapReduce.And then Yahoo fell for it hook, line, and sinker, built out Hadoop, and we've been stuck with this idea of performing these big query jobs on top of existing giant piles of data, where ideally, you can measure it with a wall clock; in practice, you often measure the calendar in some cases. And as the world continues to evolve, being able to do streaming processing and understand in real-time what is going on, is unlocking different approaches, at least by all accounts. Do you have an example you can give me of a problem that real-time analytics solves for a customer? Because I can sit here and talk all day about how things might theoretically work, but I have to get out of my Route 53-based ivory tower over here, what are customers seeing?Venkat: That's a great question. And I want one hundred percent agree. I think Google did build MapReduce, and I think it's a very nice continuation of what happened there and what is happening in the world now. And built MapReduce and they quickly realized re-indexing the whole world [laugh] every night, as the size of the internet is exploding is a bad idea. And you know how Google index is now? They do real-time indexing.That is how they index the wor—you know, web. And they look for the changes that are happening in the internet, and they only index the changes. And that is exactly the same principle behind—one of the core principles behind Rockset's real-time analytics platform. So, what is the customer story? So, let me give you one of my favorite ones.So, the world's number one or number two buy now, pay later company, they have hundreds of millions of users, they have 300,000-plus merchants, they operate in, like, maybe 100-plus countries, so many different payment methods, you can imagine the complexity. At any given point in time, some part of the product is broken, well, Apple Pay stopped working in Switzerland for this e-commerce merchant. Oh God, like, we got to first detect that. Forget even debugging and figuring out what happened and having an incident response team. So, what did they do as they scale the number of payments processed in the system across the world—it's, like, in millions; first, it was millions in the day, and there was millions in an hour—so like everybody else, they built a batch-based system.So, they would accumulate all these payment records, and every six hours—so initially, it was a day, and then afterwards, you know, you try to see how far I can push it, and they couldn't push it beyond every six hours. Every six hours, some batch job would come and process through all the payments that happened, have some statistical models to detect, hey, here are some of the things that you might want to double-click and follow up on. And as they were scaling, the batch job that they will kick off every six hours was starting to take more than six hours. So, you can see how the story goes. Now, fast-forward, they came to us and say—it's almost like Rockset has, like, a big red button that says, “Real-time this.”And then they kind of like, “Can you make this real-time? Because not only that we are losing millions of potential revenue dollars in a year because something stops working and we're not processing payments, and we don't find out about that up to, like, three hours later, five hours later, six hours later, but our merchants are also very unhappy. We are also not able to protect our customers' business because that is all we are about.” And so fast-forward, they use Rockset, and simply using SQL now they have all the metrics and statistical computation that they want to do, happens in real-time, that are accurate up to the second. All of their anomaly detectors run every minute and the anomaly detectors take, like, hundreds of milliseconds to run.And so, now they've cut down the business observability, I would say. It's not metrics and machine observability is actually the—you know, they have now business observability in real-time. And that not only actually saves them a lot of potential revenue loss from downtimes, that's also allowing them to build a better product and give their customers a better experience because they are now telling their merchants and their customers that something is not working in some part of your e-commerce footprint before even the customers notice that something is wrong. And that allows them to build a better product and a better customer experience than their competitors. So, this is a very real-world example of why companies and enterprises are moving from batch to real-time.Corey: With the stories that you, and frankly, a lot of other data analytics companies tend to fall back on all the time has been stories of the ones you're telling, where you're talking about the largest buy now, pay later lender, for example. These are companies operating at massive scale who have tremendous existing transaction volume, and they're built out already. That's great, but then I wanted to try to cut to the truth of some of these things. And when I visit your pricing page at Rockset, it doesn't have what I would expect if that were the only use case. And what that would be is, “Great. Call here to conta—open up a sales quote, and we'll talk to you et cetera, et cetera, et cetera.”And the answer then is, “Okay, I know it's going to have at least two commas in it, ideally, not three, but okay, great.” Instead, you have a free tier where it's, “Hey, we'll give you a pile of credits, here's some limits on our free account, et cetera, et cetera.” Great. That is awesome. So, it tells me that there is a use case here for folks who have not already, on some level, made a good show of starting the process of conquering the world.Rather, someone with an idea some evening at two in the morning can wind up diving in and getting started. What is the Twitter for Pets, in my garage, spare-time side project story for using something like Rockset? What problem will I have as I wind up building those things out, when I don't have any user traffic or data yet, but I want to, you know for once in my life, do the smart thing in advance rather than building an impressive tower of technical debt?Venkat: That is the first thing we built, by the way. When we finish our product, the first thing we built was self-service. The first thing we built was a free forever tier, which has certain limits because somebody has to pay the bill, right? And then we also have compute instances that are very, very affordable that cost you, like, approximately $1 a day. And so, we built all of that because real-time analytics is not a need that only, like, the large-scale companies have. And I'll give you a very, very simple example.Let's say you're building a game, it's a mobile game. You can use Amazon DynamoDB and use AWS Lambdas and have a serverless stack and, like, you're really only paying… you're kind of keeping your footprint very, very small, and you're able to build a very lively game and see if it gets [wider 00:12:16], and it's growing. And once it grows, you can have all the big company scaling problems. But in the early days, you're just getting started. Now, if you think about DynamoDB and Lambdas and whatnot, you can build almost every part of the game except probably the leaderboard.So, how do I build a leaderboard when thousands of people are playing and all of their individual gameplays and scores and everything is just another simple record in DynamoDB. It's all serverless. But DynamoDB doesn't give me a SQL SELECT *, order by score, limit 100, distinct by the same player. No, this is a analytical question, and it has to be updated in real-time, otherwise, you really don't have this thing where I just finished playing. I go to the leaderboard, and within a second or two, if it doesn't update, you kind of lose people along the way. So, this is one of actually a very popular use case, when the scale is much smaller, which is, like, Rockset augments NoSQL database like a Dynamo or a Mongo where you can continue to use that for—or even a Postgres or MySQL for that case where you can use that as your system of record and keep it small, but cover all of your compute-heavy and analytical parts of your application with Rockset.So, it's almost like kind of a CQRS pattern where you use your OLTP database as your system of record, you connect Rockset to it, and so—Rockset comes in with built-in connectors, by the way, so you don't have to write a single line of code for your inserts and updates and deletes in your transactional database to get reflected in Rockset within one to two seconds. And so now, all of a sudden you have a fully indexed, fast SQL replica of your transactional database that on which you can do all sorts of analytical queries and that's fully isolated with your transactional database. So, this is the pattern that I'm talking about. The mobile leaderboard is an example of that pattern where it comes in very handy. But you can imagine almost everybody building some kind of an application has certain parts of it that is very analytical in nature. And by augmenting your transactional database with Rockset, you can have your cake and eat it too.Corey: One of the challenges I think that at least I've run into when it comes to working with data—and let's be clear, I tend to deal with data in relatively small volumes, mostly. The stuff that's significantly large, like, oh, I don't know, AWS bills from large organizations, the format of those is mostly predefined. When I'm building something out, we're using, I don't know, DynamoDB or being dangerous with SQLite or whatnot, invariably I find that even at small-scale, I paint myself into a corner by data model design or how I wind up structuring access or the rest, and the thing that I'm doing that makes perfect sense today winds up being incredibly challenging to change later. And I still, in production and have a DynamoDB table that has the word ‘test' in its name because of course I do.It's not a great place to find yourself in some cases. And I'm curious as to what you've seen, as you've been building this out and watching customers, especially ones who already had significant datasets as they move to you. Do you have any guidance around how to avoid falling down that particular well?Venkat: I will say a lot of the complexity in this world is by solving the right problems using the wrong tool, or by solving the right problem on the wrong part of the stack. I'll unpack this a little bit, right? So, when your patterns change, your application is getting more complex, it is demanding more things, that doesn't necessarily mean the first part of the application you build—and let's say DynamoDB was your solution for that—was the wrong choice. That is the right choice, but now you're expanded the scope of your application and the demand that you have on your backend transactional database. And now you have to ask the question, now in the expanded scope, which ones are still more of the same category of things on why I chose Dynamo and which ones are actually not at all?And so, instead of going and abusing the GSIs and other really complex and expensive indexing options and whatnot, that Dynamo, you know, has built, and has all sorts of limitations, instead of that, what do I really need and what is the best tool for the job, right? What is the best system for that? And how do I augment? And how do I manage these things? And this goes to the first thing I said, which is, like, this tremendous complexity when you start to build a Rube Goldberg machine of sorts.Okay, now, I'm going to start making changes to Dynamo. Oh, God, like, how do I pick up all of those things and not miss a single record? Now, replicate that to another second system that is going to be search-centric or reporting-centric, and do I have to rethink this once in a while? Do I have to build and manage these pipelines? And suddenly, instead of going from one system to two system, you actually end up going from one system to, like, four different things that with all the pipes and tubes going into the middle.And so, this is what we really observed. And so, when you come in to Rockset and you point us at your DynamoDB table, you don't write a single line of code, and Rockset will automatically scan your Dynamo tables, move that into Rockset, and in real-time, your changes, insert, updates, deletes to Dynamo will be reflected in Rockset. And this is all using Dynamo Streams API, Dynamo Scan API, and whatnot, behind the scenes. And this just gives you an example of if you use the right tool for the job here, when suddenly your application is demanding analytical queries on Dynamo, and you do the right research and find the right tool, your complexity doesn't explode at all, and you can still, again, continue to use Dynamo for what it is very, very good at while augmenting that with a system built for analytics with full-featured SQL and other capabilities that I can talk about, for the parts of your application for which Dynamo is not a good fit. And so, if you use the right tool for the job, you should be in very good place.The other thing is part about this wrong part of the stack. I'll give a very kind of naive example, and then maybe you can extrapolate that to, like, other patterns on how people could—you know, accidental complexities the worst. So, let's just say you need to implement access control on your data. Let's say the best place to implement access control is at the database level, just happens to be that is the right thing. But this database that I picked, doesn't really have role-based access control or what have you, it doesn't really give me all the security features to be able to protect the data the way I want it.So, then what I'm going to do is, I'm going to go look at all the places that is actually having business logic and querying the database and I'm going to put a whole bunch of permission management and roles and privileges, and you can just see how that will be so error-prone, so hard to maintain, and it will be impossible to scale. And this is what is the worst form of accidental complexity because if you had just looked at it that one week or two weeks, how do I get something out, or the database I picked doesn't have it, and then the two weeks, you feel like you made some progress by, kind of like, putting some duct tape if conditions on all the access paths. But now, [laugh] you've just painted yourself into a really, really bad corner.And so, this is another variation of the same problem where you end up solving the right problems in the wrong part of the stack, and that just introduces tremendous amount of accidental complexity. And so, I think yeah, both of these are the common pitfalls that I think people make. I think it's easy to avoid them. I would say there's so much research, there's so much content, and if you know how to search for these things, they're available in the internet. It's a beautiful place. [laugh]. But I guess you have to know how to search for these things. But in my experience, these are the two common pitfalls a lot of people fall into and paint themselves in a corner.Corey: Couchbase Capella Database-as-a-Service is flexible, full-featured and fully managed with built in access via key-value, SQL, and full-text search. Flexible JSON documents aligned to your applications and workloads. Build faster with blazing fast in-memory performance and automated replication and scaling while reducing cost. Capella has the best price performance of any fully managed document database. Visit couchbase.com/screaminginthecloud to try Capella today for free and be up and running in three minutes with no credit card required. Couchbase Capella: make your data sing.Corey: A question I have, though, that is an extension is this—and I want to give some flavor to it—but why is there a market for real-time analytics? And what I mean by that is, early on in my tenure of fixing horrifying AWS bills, I saw a giant pile of money being hurled over at effectively a MapReduce cluster for Elastic MapReduce. Great. Okay, well, stream-processing is kind of a thing; what about migrating to that? Well, that was a complete non-starter because it wasn't just the job running on those things; there were downstream jobs, and with their own downstream jobs. There were thousands of business processes tied to that thing.And similarly, the idea of real-time analytics, we don't have any use for that because of, oh I don't know, I only wind up pulling these reports on a once-a-week basis, and that's fine, so what do I need that updated for in real-time if I'm looking at them once a week? In practice, the answer is often something aligned with the, “Well, yeah, but you had a real-time updating dashboard, you would find that more useful than those reports.” But people's expectations and business processes have shaped themselves around constraints that now can be removed, but how do you get them to see that? How do you get them to buy in on that? And then how do you untangle that enormous pile of previous constraint into something that leverages the technology that's now available for a brighter future?Venkat: I think [unintelligible 00:21:40] a really good question, who are the people moving to real-time analytics? What do they see? And why can they do it with other tech? Like, you know, as you say… EMR, you know, it's just MapReduce; can't I just run it in sort of every twenty-four hours, every six hours, every hour? How about every five minutes? It doesn't work that way.Corey: How about I spin up a whole bunch of parallel clusters on different timescales so I constantly—Venkat: [laugh].Corey: Have a new report coming in. It's real-time, except—Venkat: Exactly.Corey: You're constantly putting out new ones, but they're just six hours delayed every time.Venkat: Exactly. So, you don't really want to do this. And so, let me unpack it one at a time, right? I mean, we talked about a very good example of a business team which is building business observability at the buy now, pay later company. That's a very clear value-prop on why they want to go from batch to real-time because it saves their company tremendous losses—potential losses—and also allows them to build a better product.So, it could be a marketing operations team looking to get more real-time observability to see what campaigns are working well today and how do I double down and make sure my ad budget for the day is put to good use? I don't have to mention security operations, you know, needing real-time. Don't tell me I got owned three days ago. Tell me—[laugh] somebody is, you know, breaking glass and might be, you know, entering into your house right now. And tell me then and not three days later, you know—Corey: “Yeah, what alert system do you have for security intrusion?” “So, I read the front page of_The New York Times_ every morning and waiting to see my company's name.” Yeah, there probably are better ways to reduce that cycle time.Venkat: Exactly, right. And so, that is really the need, right? Like, I think more and more business teams are saying, “I need operational intelligence and not business intelligence.” Don't make me play Monday morning quarterback.My favorite analogy is it's the middle of the third quarter. I'm six points down. A couple of people, star players in my team and my opponent's team are injured, but there's some in offense, some in defense. What plays do I do and how do I play the game slightly differently to change the outcome of the game and win this game as opposed to losing by six points. So, that I think is kind of really what is driving businesses.You know, I want to be more agile, I want to be more nimble, and take, kind of, being data-driven decision-making to another level. So that, I think, is the real force in play. So, now the real question is, why can they do it already? Because if you go ask a hundred people, “Do you want fast analytics on real-time data or slow analytics on stale data?” How many people are going to say give me slow and stale? Zero, right? Exactly zero people.So, but then why hasn't it happened yet? I think it goes back to the world only has seen two kinds of databases: Transaction processing systems, built for system of record, don't lose my data kind of systems; and then batch analytics, you know, all these warehouses and data lakes. And so, in real-time analytics use cases, the data never stops coming, so you have to actually need a system that is running 24/7. And then what happens is, as soon as you build a real-time dashboard, like this example that you gave, which is, like, I just want all of these dashboards to automatically update all the time, immediately people respond, says, “But I'm not going to be like Clockwork Orange, you know, toothpicks in my eyelids and be staring at this 24/7. Can you do something to alert or detect some anomalies and tap on my shoulder when something off is going on?”And so, now what happens is somebody's actually—a program more than a person—is actually actively monitoring all of these metrics and graphs and doing some analysis, and only bringing this to your attention when you really need to because something is off, right? So, then suddenly what happens is you went from, accumulate all the data and run a batch report to [unintelligible 00:25:16], like, the data never stops coming, the queries never stopped coming, I never stop asking questions; it's just a programmatic way of asking those things. And at that point, you have a data app. This is not a analytics dashboard report anymore. You have a full-fledged application.In fact, that application is harder to build and scale than any application you've ever built before [laugh] because in those situations, again, you don't have this torrent of data coming in all the time and complex analytical questions you're asking on the data 24/7, you know? And so, that I think is really why real-time analytics platform has to be built as almost a third leg. So, this is what we call data apps, which is when your data never stops coming and your queries never stop coming. So, this is really, I think, what is pushing all the expensive EMR clusters or misusing your warehouse, misusing your data lakes. At the end of the day, is what is I think blowing up your Snowflake bills, is what blowing up your warehouse builds because you somehow accidentally use the wrong tool for the job [laugh] going back to the one that we just talked about.You accidentally say, “Oh, God, like, I just need some real-time.” With enough thrust, pigs can fly. Is that a good idea? Probably not, right? And so, I don't want to be building a data app on my warehouse just because I can. You should probably use the best tool for the job, and really use something that was built ground up for it.And I'll give you one technical insight about how real-time analytics platforms are different than warehouses.Corey: Please. I'm here for this.Venkat: Yes. So really, if you think about warehouses and data lakes, I call them storage-optimized systems. I've been building databases all my life, so if I have to really build a database that is for batch analytics, you just break down all of your expenses in terms of let's say, compute and storage. What I'm burning 24/7 is storage. Compute comes and goes when I'm doing a batch data load, or I'm running—an analyst who logs in and tries to run some queries.But what I'm actually burning 24/7 is storage, so I want to compress the heck out of the data, and I want to store it in very cheap media. I want to store it—and I want to make the storage as cheap as possible, so I want to optimize the heck out of the storage use. And I want to make computation on that possible but not efficient. I can shuffle things around and make the analysis possible, but I'm not trying to be compute-efficient. And we just talked about how, as soon as you get into real-time analytics, you very quickly get into the data app business. You're not building a real-time dashboard anymore, you're actually building your application.So, as soon as you get into that, what happens is you start burning both storage and compute 24/7. And we all know, relatively, [laugh] compute and RAM is about a hundred to a thousand times more expensive than storage in the grand scheme of things. And so, if you actually go and look at your Snowflake bill, if you go look at your warehouse bill—BigQuery, no matter what—I bet the computational part of it is about 90 to 95% of the bill and not the storage. And then, if you again, break down, okay, who's spending all the compute, and you'll very quickly narrow down all these real-time-y and data app-y use cases where you can never turn off the compute on your warehouse or your BigQuery, and those are the ones that are blowing up your costs and complexity. And on the Rockset side, we are actually not storage-optimized; we're compute-optimized.So, we index all the data as it comes in. And so, the storage actually goes slightly higher because the, you know, we stored the data and also the indexes of those data automatically, but we usually fold the computational cost to a quarter of what a typical warehouse needs. So, the TCO for our customers goes down by two to four folds, you know? It goes down by half or even to a quarter of what they used to spend. Even though their storage cost goes up in net, that is a very, very small fraction of their spend.And so really, I think, good real-time analytics platforms are all compute-optimized and not storage-optimized, and that is what allows them to be a lot more efficient at being the backend for these data applications.Corey: As someone who spends a lot of time staring into the depths of AWS bills, I think that people also lose sight of the reality that it doesn't matter what you're spending on AWS; it invariably pales in comparison to what you're spending on people to work with these things. The reason to go to cloud is not because it is the cheapest possible way to get computers to do things; it's because it's a capability story. It's about unlocking capacity and capabilities you do not have otherwise. And that dramatically increases your feature velocity and it lets you to achieve things faster, sooner, with better results. And unlocking a capability is always going to be more interesting to a company than saving money on it. When a company cares first, last, and always about just save money, make the bill lower, the end, it's usually a company in decline. Or alternately, something very strange is going on over there.Venkat: I agree with that. One of our favorite customers told us that Rockset took their six-month roadmap and shrunk it to a single afternoon. And their supply chain SaaS backend for heavy construction, 80% of concrete that are being delivered and tracked in North America follows through their platform, and Rockset powers all of their real-time analytics and reporting. And before Rockset, what did they have? They had built a beautiful serverless stack using DynamoDB, even have AWS Lambdas and what-have-you.And why did they have to do all serverless? Because the entire team was two people. [laugh]. And maybe a third person once in a while, they'll get, so 2.5. Brilliant people, like, you know, really pioneers of building an entire data stack on AWS in a serverless fashion; no pipes, no ETL.And then they were like, oh God, finally, I have to do something because my business demands and my customers are demanding real-time reporting on all of these concrete trucks and aggregate trucks delivering stuff. And real-time reporting is the name of the game for them, and so how do I power this? So, I have to build a whole bunch of pipes, deliver it to, like, some Elasticsearch or some kind of like a cluster that I had to keep up in real-time. And this will take me a couple of months, that will take me a couple of months. They came into Rockset on a Thursday, built their MVP over the weekend, and they had the first working version of their product the following Tuesday.So—and then, you know, there was no turning back at that point, not a single line of code was written. You know, you just go and create an account with Rockset, point us at your Dynamo, and then off you go. You know, you can use start using SQL and go start building your real-time application. So again, I think the tremendous value, I think a lot of customers like us, and a lot of customers love us. And if you really ask them what is one thing about Rockset that you really like, I think it'll come back to the same thing, which is, you gave me a lot of time back.What I thought would take six months is now a week. What I thought would be three weeks, we got that in a day. And that allows me to focus on my business. I want to spend more time with my stakeholders, you know, my CPO, my sales teams, and see what they need to grow our business and succeed, and not build yet another data pipeline and have data pipelines and other things coming out of my nose, you know? So, at the end of the day, the simplicity aspects of it is very, very important for real-time analytics because, you know, we can't really realize our vision for real-time being the new default in every enterprise for whenever analytics concern without making it very, very simple and accessible to everybody.And so, that continues to be one of our core thing. And I think you're absolutely right when you say the biggest expense is actually the people and the time and the energy they have to spend. And not having to stand up a huge data ops team that is building and managing all of these things, is probably the number one reason why customers really, really like working with our product.Corey: I want to thank you for taking so much time to talk me through what you're working on these days. If people want to learn more, where's the best place to find you?Venkat: We are Rockset, I'll spell it out for your listeners ROCKSET—rock set—rockset.com. You can go there, you can start a free trial. There is a blog, rockset.com/blog has a prolific blog that is very active. We have all sorts of stories there, and you know engineers talking about how they implemented certain things, to customer case studies.So, if you're really interested in this space, that's one on space to follow and watch. If you're interested in giving this a spin, you know, you can go to rockset.com and start a free trial. If you want to talk to someone, there is, like, a ‘Request Demo' button there; you click it and one of our solutions people or somebody that is more familiar with Rockset would get in touch with you and you can have a conversation with them.Corey: Excellent. And links to that will of course go in the [show notes 00:34:20]. Thank you so much for your time today. I appreciate it.Venkat: Thanks, Corey. It was great.Corey: Venkat Venkataramani, co-founder and CEO at Rockset. I'm Cloud Economist Corey Quinn and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice along with an insulting crappy comment that I will immediately see show up on my real-time dashboard.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

We chat with the Kafka Duchess, Anna McDonald, about Apache Kafka, CQRS, Event Sourcing, and of-course Functional Programming. Note: There was a bit of echo for a few minutes but we did resolve it around 8 minutes in. Discuss this episode: https://discord.gg/nPa76qF

Provided as a free resource by DataStax https://www.datastax.com/products/datastax-astra?utm_source=DataMeshRadio (AstraDB) In this episode, Scott interviews Kurt Gardiner, Engineering Manager of Data Engineering at Australian Insurance company nib Group. Kurt shared some insights into nib's journey so far, including the search for something like data mesh before Zhamak published, tool choices (Snowflake, dbt, Fivetran, EventBridge, Kinesis), the slow-role approach to replacing legacy implementation (the "application strangler" pattern mentioned), how they got started, and much more. Much of nib's approach is the small-scale tactical while building incrementally for the bigger strategic focus. E.g. helping teams to design their data products somewhat manually while building the reusable tooling to be far less manual going forward. Along their journey, there was some internal pushback from data consumers, especially those used to consuming from the data warehouse. To do data mesh right, Kurt and Scott both emphasized the need to set things up so they can evolve. That will frustrate or scare some people and it's important to work with them to see why that matters. There also needs to be a high tolerance for failure - you will NOT get everything right on your first go. Kurt also waxed poetic (said nice things) about event streaming patterns, especially CQRS - see link below for more info -, for a useful and scalable pattern that is good for both application development and creating a scalable and useful domain data model. But it requires a complete redesign so it is probably something to slowly introduce where it makes sense, if at all. Some pithy nuggets of wisdom from Kurt that are highly applicable to data mesh: "The single biggest problem in communication is the illusion that it has taken place" "Nobody cares what you know until they know that you care" Application Strangler pattern (recently renamed Strangler Fig Application pattern): https://martinfowler.com/bliki/StranglerFigApplication.html (https://martinfowler.com/bliki/StranglerFigApplication.html) CQRS: https://www.martinfowler.com/bliki/CQRS.html (https://www.martinfowler.com/bliki/CQRS.html) Kurt's LinkedIn: https://www.linkedin.com/in/kugardiner/ (https://www.linkedin.com/in/kugardiner/) nib Group careers page: https://nib.wd3.myworkdayjobs.com/careers (https://nib.wd3.myworkdayjobs.com/careers) Data Mesh Radio is hosted by Scott Hirleman. If you want to connect with Scott, reach out to him at community at datameshlearning.com or on LinkedIn: https://www.linkedin.com/in/scotthirleman/ (https://www.linkedin.com/in/scotthirleman/) If you want to learn more and/or join the Data Mesh Learning Community, see here: https://datameshlearning.com/community/ (https://datameshlearning.com/community/) If you want to be a guest or give feedback (suggestions for topics, comments, etc.), please see https://docs.google.com/document/d/1WkXLhSH7mnbjfTChD0uuYeIF5Tj0UBLUP4Jvl20Ym10/edit?usp=sharing (here) All music used this episode created by Lesfm (intro includes slight edits by Scott Hirleman): https://pixabay.com/users/lesfm-22579021/ (https://pixabay.com/users/lesfm-22579021/) Data Mesh Radio is brought to you as a community resource by DataStax. Check out their high-scale, multi-region database offering (w/ lots of great APIs) and use code DAAP500 for a free $500 credit (apply under "add payment"): https://www.datastax.com/products/datastax-astra?utm_source=DataMeshRadio (AstraDB)

Bu bölümde Ali Özgür, Barış Akın ve Ertan Tike'ye konuğumuz Suat Köse eşlik ediyor. Suat Köse ile Command Query Responsibility Segregation (CQRS), Event Sourcing ve Event Driven yaklaşımları ele aldık. Keyifli dinlemeler...

In this episode, I was joined by Callum Linington to chat about Event Sourcing! Events over time are how the world works - so shouldn't we be leveraging that in our architectures? As quite often happens, we also went on one or two tangents, and covered a ton of other related including MediatR, CQRS, F#, DDD, Rx, Redux, and more!For a full list of show links, see the website here

In our best episode yet, Adam Dymitruk (@adymitruk), Author of Event Modeling, Original Contributor of #CQRS and #EventSourcing, and founder of Adaptech Group shows us how to map out event modeling for information systems. We talk about his life as a self-taught immigrant coder whose first code was written on paper notes, his love of open source and the open source tools he recommends for every workflow and task, and the business of event modeling in development. If you care about how efficient systems work, you'll love this episode. > Never miss a video // SUBSCRIBE: https://bit.ly/2PzTqAI // About The Ops Show // #TheOpsShow is a weekly YouTube show and podcast hosted by Tristan Pollock and Kyle Campbell covering the wide world of #workflows in #DevOps and the greater developer experience. Watch ALL EPISODES: https://bit.ly/2WgD1F5 + https://w.cto.ai/theopsshow > Join the community // SHIP TOGETHER: https://bit.ly/3fTPKpe // About CTO.ai // CTO.ai provides end-to-end serverless infrastructure designed for the needs of fast-moving development teams who want to optimize what the business cares about. Easy to use like Heroku, and powerful like Kubernetes, CTO.ai gives you the tools you need to workflow smarter, not harder. > Try out the platform: https://cto.ai/platform > Or come say hello: https://github.com/cto-ai https://twitter.com/CTO_ai https://www.linkedin.com/company/cto-ai/ https://www.instagram.com/cto.ai/ https://www.facebook.com/CTOdotAI/ https://www.twitch.tv/cto_ai