https://media.ccc.de/c/bobkonf2022 This feed contains all events from bobkonf2022 as mp3 see video outro Thu, 23 Jan 2025 18:45:39 -0000 https://static.media.ccc.de/media/unknown.png https://media.ccc.de/c/bobkonf2022 https://media.ccc.de/v/bob2022-rustbelt-securing-the-foundations-dreyer The Rust systems programming language promises to overcome the seemingly fundamental tradeoff in language design between high-level safety guarantees and low-level control over resource management. Unfortunately, none of Rust’s safety claims have been formally proven, and there is good reason to question whether they actually hold. Specifically, Rust employs a strong, ownership-based type system, but then extends the expressive power of this core type system through libraries that internally use unsafe features. In this talk, I will present RustBelt, the first formal (and machine-checked) safety proof for a language representing a realistic subset of Rust. Our proof is extensible in the sense that, for each new Rust library that uses unsafe features, we can say what verification condition it must satisfy in order for it to be deemed a safe extension to the language. We have carried out this verification for some of the most important libraries that are used throughout the Rust ecosystem. The secret weapon that makes RustBelt possible is the Iris framework for higher-order concurrent separation logic in Coq. The talk will not assume any prior familiarity with concurrent separation logic or Rust. about this event: https://bobkonf.de/2022/dreyer.html Fri, 11 Mar 2022 09:00:00 +0100 https://cdn.media.ccc.de/events/bobkonf/2022/mp3/bob2022-999-eng-Keynote_RustBelt_Securing_the_Foundations_of_the_Rust_Programming_Language_mp3.mp3?1662472492 b272476e-c7bb-4350-8371-f67f565a51f6 2022-03-11T09:00:00+01:00 Derek Dreyer No bob2022, 999, 2022, Talk, BOB, BOBKonferenz The Rust systems programming language promises to overcome the seemingly fundamental tradeoff in language design between high-level safety guarantees and low-level control over resource management. Unfortunately, none of Rust’s safety claims have been formally proven, and there is good reason to question whether they actually hold. Specifically, Rust employs a strong, ownership-based type system, but then extends the expressive power of this core type system through libraries that internally use unsafe features. In this talk, I will present RustBelt, the first formal (and machine-checked) safety proof for a language representing a realistic subset of Rust. Our proof is extensible in the sense that, for each new Rust library that uses unsafe features, we can say what verification condition it must satisfy in order for it to be deemed a safe extension to the language. We have carried out this verification for some of the most important libraries that are used throughout the Rust ecosystem. The secret weapon that makes RustBelt possible is the Iris framework for higher-order concurrent separation logic in Coq. The talk will not assume any prior familiarity with concurrent separation logic or Rust. about this event: https://bobkonf.de/2022/dreyer.html 01:00:09 https://media.ccc.de/v/bob2022-event-getriebene-architekturen-junker Der Beitrag diskutiert, ob und wie man event-getriebene Architekturen als eine Form der reaktiven Architekturen in einer Beratungssoftware einsetzen kann. Dabei wird der Bogen von den Geschäftsanforderungen bis hin zur technischen Umsetzung gespannt. Warum wurde für diese Beratungssoftware der event-getriebene Ansatz gewählt? Es werden sowohl die geschäftlichen als auch die technischen Anforderungen diskutiert, die zur Wahl dieses Architekturansatzes geführt haben. Weiterhin wird ein Ansatz diskutiert, wie event-getriebene Architekturen in Übergängen von Legacy-Anwendungen in neue Architekturen unterstützen können. about this event: https://bobkonf.de/2022/junker.html Fri, 11 Mar 2022 12:35:00 +0100 https://cdn.media.ccc.de/events/bobkonf/2022/mp3/bob2022-93-deu-Event-getriebene_Architekturen_Allianz_mp3.mp3?1662403864 742830b2-4e1f-4620-ae2a-8f75f8536dbd 2022-03-11T12:35:00+01:00 Annegret Junker No bob2022, 93, 2022, Talk, BOB, BOBKonferenz Der Beitrag diskutiert, ob und wie man event-getriebene Architekturen als eine Form der reaktiven Architekturen in einer Beratungssoftware einsetzen kann. Dabei wird der Bogen von den Geschäftsanforderungen bis hin zur technischen Umsetzung gespannt. Warum wurde für diese Beratungssoftware der event-getriebene Ansatz gewählt? Es werden sowohl die geschäftlichen als auch die technischen Anforderungen diskutiert, die zur Wahl dieses Architekturansatzes geführt haben. Weiterhin wird ein Ansatz diskutiert, wie event-getriebene Architekturen in Übergängen von Legacy-Anwendungen in neue Architekturen unterstützen können. about this event: https://bobkonf.de/2022/junker.html 00:32:05 https://media.ccc.de/v/bob2022-composable-ui-components-schlegel It has now been a decade since React revolutionized frontend GUI programming with ideas from functional programming. After ten years, however, the promise of simple program logic for complex apps is still not fulfilled. State management remains an unsolved problem. In this talk I propose that we take to functional programming again to escape this misery. We analyze code “in its transient nature not less than its momentary existence” so that at the end of our journey we find lenses and stores and true lossless composability. about this event: https://bobkonf.de/2022/schlegel.html Fri, 11 Mar 2022 10:15:00 +0100 https://cdn.media.ccc.de/events/bobkonf/2022/mp3/bob2022-109-eng-Composable_UI_Components_mp3.mp3?1662403215 48658336-215b-4957-93d5-98bba8684de0 2022-03-11T10:15:00+01:00 Markus Schlegel No bob2022, 109, 2022, Talk, BOB, BOBKonferenz It has now been a decade since React revolutionized frontend GUI programming with ideas from functional programming. After ten years, however, the promise of simple program logic for complex apps is still not fulfilled. State management remains an unsolved problem. In this talk I propose that we take to functional programming again to escape this misery. We analyze code “in its transient nature not less than its momentary existence” so that at the end of our journey we find lenses and stores and true lossless composability. about this event: https://bobkonf.de/2022/schlegel.html 00:32:20 https://media.ccc.de/v/bob2022-tiger-kommt-weglaufen-starke Unser Gehirn wurde von der Evolution über Hunderte Generationen auf “Überleben” optimiert. Dabei haben sich einige Eigenschaften herausgebildet, die uns in Softwareentwicklung und -architektur unbewusst eine Menge Schwierigkeiten bereiten. Wir schauen im Vortrag auf einige dieser komischen Phänomene des Gehirns und betrachten Zusammenhänge zu typischen Situationen in der Softwareentwicklung. Die Erforschung mancher dieser Gehirneigenschaften haben einigen Leuten Nobelpreise eingebracht - und bieten uns in der Softwareentwicklung gute Ansätze, unsere eigene Arbeitsweise und unsere Architekturentscheidungen systematisch zu verbessern. about this event: https://bobkonf.de/2022/starke.html Fri, 11 Mar 2022 15:05:00 +0100 https://cdn.media.ccc.de/events/bobkonf/2022/mp3/bob2022-114-deu-Tiger_kommt_Weglaufen_mp3.mp3?1662403306 e6b315a9-4f29-4ef6-acb8-081b4121fb27 2022-03-11T15:05:00+01:00 Gernot Starke No bob2022, 114, 2022, Talk, BOB, BOBKonferenz Unser Gehirn wurde von der Evolution über Hunderte Generationen auf “Überleben” optimiert. Dabei haben sich einige Eigenschaften herausgebildet, die uns in Softwareentwicklung und -architektur unbewusst eine Menge Schwierigkeiten bereiten. Wir schauen im Vortrag auf einige dieser komischen Phänomene des Gehirns und betrachten Zusammenhänge zu typischen Situationen in der Softwareentwicklung. Die Erforschung mancher dieser Gehirneigenschaften haben einigen Leuten Nobelpreise eingebracht - und bieten uns in der Softwareentwicklung gute Ansätze, unsere eigene Arbeitsweise und unsere Architekturentscheidungen systematisch zu verbessern. about this event: https://bobkonf.de/2022/starke.html 00:44:15 https://media.ccc.de/v/bob2022-local-first-distributed-applications-with-rescala-mogk Local-first software is a new term for interactive end-user applications, which provide data ownership and privacy while still enabling data to be shared, and which allow working offline while ensuring data consistency. Developing such applications is often perceived as hard, because of the use of unsuited general purpose programming models. REScala is a mature research project that addresses these issues and provides a specialized programming model designed to be understandable by developers while still providing the flexibility for efficient implementations that automatically ensure all desired properties. In this talk, we will show how a combination of functional reactive programming (the mostly classical variant) and conflict-free replicated data types (specifically join semilattices) provide abstract reasoning about all points in space and time for local-first applications. Specifically why reasoning in the abstract is actually much easier for developers than reasoning about all the hundreds and thousands of possible special cases their implementation admits. We hope that this talk helps to spread such better suited programming models, thus leading to most software being local-first by default. Then, we may see a future where individuals own their data and not have it stolen by advertisers, and companies keep their sovereignty without being at the mercy of the biggest players. about this event: https://bobkonf.de/2022/mogk.html Fri, 11 Mar 2022 17:10:00 +0100 https://cdn.media.ccc.de/events/bobkonf/2022/mp3/bob2022-113-eng-Local-first_Distributed_Applications_with_REScala_mp3.mp3?1662383295 24a3523a-b9e4-4352-9316-00ccd2a00416 2022-03-11T17:10:00+01:00 Ragnar Mogk No bob2022, 113, 2022, Talk, BOB, BOBKonferenz Local-first software is a new term for interactive end-user applications, which provide data ownership and privacy while still enabling data to be shared, and which allow working offline while ensuring data consistency. Developing such applications is often perceived as hard, because of the use of unsuited general purpose programming models. REScala is a mature research project that addresses these issues and provides a specialized programming model designed to be understandable by developers while still providing the flexibility for efficient implementations that automatically ensure all desired properties. In this talk, we will show how a combination of functional reactive programming (the mostly classical variant) and conflict-free replicated data types (specifically join semilattices) provide abstract reasoning about all points in space and time for local-first applications. Specifically why reasoning in the abstract is actually much easier for developers than reasoning about all the hundreds and thousands of possible special cases their implementation admits. We hope that this talk helps to spread such better suited programming models, thus leading to most software being local-first by default. Then, we may see a future where individuals own their data and not have it stolen by advertisers, and companies keep their sovereignty without being at the mercy of the biggest players. about this event: https://bobkonf.de/2022/mogk.html 00:40:44 https://media.ccc.de/v/bob2022-an-enigma-machine-in-elm-liu The Enigma machine was an encryption device that was used by German forces during WW2 to send secret messages. In this talk, we will explain exactly how the encryption process works and go through an implementation of it in Elm. We will demonstrate how to encrypt and decrypt a message. Then we will go over the weaknesses that made it exploitable by Alan Turing and the other fine folks in Bletchley Park. By the end of the talk, you’ll be able to point out all the inaccuracies in “The Imitation Game”. about this event: https://bobkonf.de/2022/liu.html Fri, 11 Mar 2022 17:10:00 +0100 https://cdn.media.ccc.de/events/bobkonf/2022/mp3/bob2022-107-eng-An_Enigma_Machine_in_Elm_mp3.mp3?1662383097 692fd4a3-0881-47f7-a054-90a14010e125 2022-03-11T17:10:00+01:00 Ju Liu No bob2022, 107, 2022, Talk, BOB, BOBKonferenz The Enigma machine was an encryption device that was used by German forces during WW2 to send secret messages. In this talk, we will explain exactly how the encryption process works and go through an implementation of it in Elm. We will demonstrate how to encrypt and decrypt a message. Then we will go over the weaknesses that made it exploitable by Alan Turing and the other fine folks in Bletchley Park. By the end of the talk, you’ll be able to point out all the inaccuracies in “The Imitation Game”. about this event: https://bobkonf.de/2022/liu.html 00:38:07 https://media.ccc.de/v/bob2022-detecting-oxbow-code-in-erlang-castro-brujo Learn how to clean up your large Erlang projects by detecting and removing code that’s no longer needed with the highest level of confidence using Hank, an open-source plugin for rebar3. The presence of source code that is no longer needed is a handicap to project maintainability. The larger and longer-lived the project, the higher the chances of accumulating dead code in its different forms. Manually detecting unused code is time-consuming, tedious, error-prone, and requires a great level of deep knowledge about the codebase. In this talk, we examine the kinds of dead code (specifically, oxbow code) that can appear in Erlang projects, and formulate rules to identify them with high accuracy. We also present an open-source static analyzer that implements these rules, allowing for the automatic detection and confident removal of oxbow code in Erlang codebases, actively contributing to increasing their quality and maintainability. about this event: https://bobkonf.de/2022/castro-brujo.html Fri, 11 Mar 2022 16:20:00 +0100 https://cdn.media.ccc.de/events/bobkonf/2022/mp3/bob2022-98-eng-Detecting_Oxbow_Code_in_Erlang_Codebases_with_the_Highest_Degree_of_Certainty_mp3.mp3?1662382538 5975f68c-5abd-4c9a-89e0-86d903c8b790 2022-03-11T16:20:00+01:00 Laura M Castro, Brujo No bob2022, 98, 2022, Talk, BOB, BOBKonferenz Learn how to clean up your large Erlang projects by detecting and removing code that’s no longer needed with the highest level of confidence using Hank, an open-source plugin for rebar3. The presence of source code that is no longer needed is a handicap to project maintainability. The larger and longer-lived the project, the higher the chances of accumulating dead code in its different forms. Manually detecting unused code is time-consuming, tedious, error-prone, and requires a great level of deep knowledge about the codebase. In this talk, we examine the kinds of dead code (specifically, oxbow code) that can appear in Erlang projects, and formulate rules to identify them with high accuracy. We also present an open-source static analyzer that implements these rules, allowing for the automatic detection and confident removal of oxbow code in Erlang codebases, actively contributing to increasing their quality and maintainability. about this event: https://bobkonf.de/2022/castro-brujo.html 00:31:23 https://media.ccc.de/v/bob2022-haskell-hearts-lua-krewinkel Haskell and Lua share some similarities, like support for functional programming, but are otherwise very different. Nonetheless, the two complement each other in interesting ways. This is demonstrated by pandoc, the universal document converter, which is written in Haskell and uses Lua as extension language. Pandoc’s behavior can be modified through Lua filters, custom readers, and custom writers, leveraging the power of Haskell and flexibility of Lua. While combining the two languages is made easy by the hslua package, the internals of that package are not always straight-forward and a testament to the powers of Haskell’s Foreign Function Interface. We will take a look at the encountered impedance mismatch and how it was overcome, compare it to efforts in adjacent languages like OCaml, and see how hslua can be used to expose application internals to scripts effectively and conveniently. about this event: https://bobkonf.de/2022/krewinkel.html Fri, 11 Mar 2022 15:05:00 +0100 https://cdn.media.ccc.de/events/bobkonf/2022/mp3/bob2022-104-eng-Haskell_heart_Lua_mp3.mp3?1662381483 367c2883-a31c-4aa2-bc41-2345b71cf9d3 2022-03-11T15:05:00+01:00 Albert Krewinkel No bob2022, 104, 2022, Talk, BOB, BOBKonferenz Haskell and Lua share some similarities, like support for functional programming, but are otherwise very different. Nonetheless, the two complement each other in interesting ways. This is demonstrated by pandoc, the universal document converter, which is written in Haskell and uses Lua as extension language. Pandoc’s behavior can be modified through Lua filters, custom readers, and custom writers, leveraging the power of Haskell and flexibility of Lua. While combining the two languages is made easy by the hslua package, the internals of that package are not always straight-forward and a testament to the powers of Haskell’s Foreign Function Interface. We will take a look at the encountered impedance mismatch and how it was overcome, compare it to efforts in adjacent languages like OCaml, and see how hslua can be used to expose application internals to scripts effectively and conveniently. about this event: https://bobkonf.de/2022/krewinkel.html 00:35:32 https://media.ccc.de/v/bob2022-specification-driven-design-breitner Do you, too, think that “implementation-defined” is a derogary term? Let me describe how I have pushed againt that, and for development model that puts an abstract specification of the system to be built in a central, pivotal position, flanked by a clean-room, decoupled “reference implementation” and a “specification acceptance test”, using functional programming for good effect in both cases. Many developers tend to focus on the “how”, and less on the “what”, of what they are building. This is not bad per se, but if left unchecked, this may lead to systems with an “implementation-defined surface”, with a organically grown interface that leaks abstractions and exposes implementation details. To counter this effect, one can write a proper specification for the system. A document that, in prose and or math, precisely describes the interface of the system, but also its behavior, i.e. its semantics. This decouples the outward-facing aspects of the system from the internals. On top of that one can write a reference implementation of the system, based only on the specification. This checks and clarifies the specification, and by comparing the behavior of the two implementations, one can triangulate bugs and detect when implementations and spec went out of sync. To make things even more rigid, one can add a conformance test suite, again based soley on the specification, and probes an implementation and checks for certain behaviours. This can be integrated into the developent process, e.g. as a CI check, and additionally keep the implementations honest. All in all, this gives you a clear picture of the essence of your system or service, a place to discuss changes between stakeholders on either side of the interface without getting distracted by implementation designs, insulates your users from implementation changes and gives your developers a clearly demarked space to go wild within. about this event: https://bobkonf.de/2022/breitner.html Fri, 11 Mar 2022 14:15:00 +0100 https://cdn.media.ccc.de/events/bobkonf/2022/mp3/bob2022-88-eng-Specification-driven_design_mp3.mp3?1662380096 6b1f42ce-9c34-4662-aa02-8061b6d8e431 2022-03-11T14:15:00+01:00 Joachim Breitner No bob2022, 88, 2022, Talk, BOB, BOBKonferenz Do you, too, think that “implementation-defined” is a derogary term? Let me describe how I have pushed againt that, and for development model that puts an abstract specification of the system to be built in a central, pivotal position, flanked by a clean-room, decoupled “reference implementation” and a “specification acceptance test”, using functional programming for good effect in both cases. Many developers tend to focus on the “how”, and less on the “what”, of what they are building. This is not bad per se, but if left unchecked, this may lead to systems with an “implementation-defined surface”, with a organically grown interface that leaks abstractions and exposes implementation details. To counter this effect, one can write a proper specification for the system. A document that, in prose and or math, precisely describes the interface of the system, but also its behavior, i.e. its semantics. This decouples the outward-facing aspects of the system from the internals. On top of that one can write a reference implementation of the system, based only on the specification. This checks and clarifies the specification, and by comparing the behavior of the two implementations, one can triangulate bugs and detect when implementations and spec went out of sync. To make things even more rigid, one can add a conformance test suite, again based soley on the specification, and probes an implementation and checks for certain behaviours. This can be integrated into the developent process, e.g. as a CI check, and additionally keep the implementations honest. All in all, this gives you a clear picture of the essence of your system or service, a place to discuss changes between stakeholders on either side of the interface without getting distracted by implementation designs, insulates your users from implementation changes and gives your developers a clearly demarked space to go wild within. about this event: https://bobkonf.de/2022/breitner.html 00:34:38 https://media.ccc.de/v/bob2022-concurrent-programs-in-haskell-kant We present applications of the Haskell library io-sim. This library provides type classes with concurrency primitives that can either be run in IO, or executed in simulation. The library has been developed to help with QuickCheck-style property based testing of concurrent code, where the determinism of the simulations is helpful to get minimal failing test cases. Subsequently, it has also turned out to be quite useful for prototyping distributed systems, getting performance estimates and prediction points of congestion before starting a full implementation. about this event: https://bobkonf.de/2022/kant.html Fri, 11 Mar 2022 12:35:00 +0100 https://cdn.media.ccc.de/events/bobkonf/2022/mp3/bob2022-110-eng-io-sim_testing_simulating_and_prototyping_concurrent_programs_in_Haskell_mp3.mp3?1662379324 36f133c3-fe79-453f-a103-d3e28c3551a0 2022-03-11T12:35:00+01:00 Philipp Kant No bob2022, 110, 2022, Talk, BOB, BOBKonferenz We present applications of the Haskell library io-sim. This library provides type classes with concurrency primitives that can either be run in IO, or executed in simulation. The library has been developed to help with QuickCheck-style property based testing of concurrent code, where the determinism of the simulations is helpful to get minimal failing test cases. Subsequently, it has also turned out to be quite useful for prototyping distributed systems, getting performance estimates and prediction points of congestion before starting a full implementation. about this event: https://bobkonf.de/2022/kant.html 00:31:36 https://media.ccc.de/v/bob2022-compiling-anything-to-categories-pfeil Conal Elliott’s Compiling to Categories sparked interest in novel interpretations of Haskell programs that are accessible to a casual user of the language. Conal also created some proofs of concept with very compelling examples. However, many potential users were stymied by some limitation or other in the PoCs. At Kittyhawk, we were also attracted to the approach. Thankfully, we had the resources to commit to it, which allowed us to extend the PoC and even the original paper to make it work for us. And now, hopefully, it can work for you as well. This talk will introduce the approach, our use of it as a code generator for the flight control system of our electric aircraft, the limitations we ran into, and our solutions to them. about this event: https://bobkonf.de/2022/pfeil.html Fri, 11 Mar 2022 11:45:00 +0100 https://cdn.media.ccc.de/events/bobkonf/2022/mp3/bob2022-101-eng-Compiling_Anything_to_Categories_mp3.mp3?1662379192 bd81ac78-466f-482e-a186-345853f4afd2 2022-03-11T11:45:00+01:00 Greg Pfeil No bob2022, 101, 2022, Talk, BOB, BOBKonferenz Conal Elliott’s Compiling to Categories sparked interest in novel interpretations of Haskell programs that are accessible to a casual user of the language. Conal also created some proofs of concept with very compelling examples. However, many potential users were stymied by some limitation or other in the PoCs. At Kittyhawk, we were also attracted to the approach. Thankfully, we had the resources to commit to it, which allowed us to extend the PoC and even the original paper to make it work for us. And now, hopefully, it can work for you as well. This talk will introduce the approach, our use of it as a code generator for the flight control system of our electric aircraft, the limitations we ran into, and our solutions to them. about this event: https://bobkonf.de/2022/pfeil.html 00:36:03 https://media.ccc.de/v/bob2022-keeping-calm-braun-bieniusa Eric Brewers CAP-Theorem besagt, dass im Falle von Netzwerkpartitionen nur eine von zwei Garantien erreicht werden kann: Konsistenz oder Verfügbarkeit. Zehn Jahre später legt Joseph Hellerstein das CALM-Theorem nach, und beweist das, was wir eigentlich schon immer alle schon geahnt haben: Im Falle von Netzwerkpartitionen sind Konsistenz UND Verfügbarkeit unter bestimmten Bedingungen eben doch möglich! Wie das geht, zeigen wir euch in diesem Vortrag, und nehmen euch mit auf eine Journey vom CAP-Theorem hin zum CALM-Theorem. Wir räumen mit gängigen Mythen auf und zeigen euch, wie ihr das CALM-Theorem praktisch anwenden könnt. Basierend auf unseren empirischen Erfahrungen aus verschiedenen Studien (Case Studies und Action Research Studies) und unserer laufenden Forschung entwickeln wir Architektur-Empfehlungen und Entwurfsmuster für das Design von daten-intensiven, verteilten Anwendungen. Der Vortrag gibt konkrete Hilfestellungen für Architekt:innen, demonstriert Entwurfsmuster mit laufendem Code und teilt mit den Teilnehmern unsere frei verfügbaren open access Architektur-Guidelines. about this event: https://bobkonf.de/2022/braun-bieniusa.html Fri, 11 Mar 2022 11:45:00 +0100 https://cdn.media.ccc.de/events/bobkonf/2022/mp3/bob2022-95-deu-Keeping_CALM_-_Konsistenz_in_verteilten_Systemen_leichtgemacht_mp3.mp3?1662378181 5eb135e3-ed8d-4b8d-a6d8-4859f222fb93 2022-03-11T11:45:00+01:00 Annette Bieniusa, Susanne Braun No bob2022, 95, 2022, Talk, BOB, BOBKonferenz Eric Brewers CAP-Theorem besagt, dass im Falle von Netzwerkpartitionen nur eine von zwei Garantien erreicht werden kann: Konsistenz oder Verfügbarkeit. Zehn Jahre später legt Joseph Hellerstein das CALM-Theorem nach, und beweist das, was wir eigentlich schon immer alle schon geahnt haben: Im Falle von Netzwerkpartitionen sind Konsistenz UND Verfügbarkeit unter bestimmten Bedingungen eben doch möglich! Wie das geht, zeigen wir euch in diesem Vortrag, und nehmen euch mit auf eine Journey vom CAP-Theorem hin zum CALM-Theorem. Wir räumen mit gängigen Mythen auf und zeigen euch, wie ihr das CALM-Theorem praktisch anwenden könnt. Basierend auf unseren empirischen Erfahrungen aus verschiedenen Studien (Case Studies und Action Research Studies) und unserer laufenden Forschung entwickeln wir Architektur-Empfehlungen und Entwurfsmuster für das Design von daten-intensiven, verteilten Anwendungen. Der Vortrag gibt konkrete Hilfestellungen für Architekt:innen, demonstriert Entwurfsmuster mit laufendem Code und teilt mit den Teilnehmern unsere frei verfügbaren open access Architektur-Guidelines. about this event: https://bobkonf.de/2022/braun-bieniusa.html 00:46:34 https://media.ccc.de/v/bob2022-python-gradual-typing-clifford Python is well known as a dynamically typed language, but it has an increasingly mature system of type annotations which can be gradually introduced to an existing code base. I’d like to tell you some good stuff, some bad stuff and some terrible stuff - based around my experience adding type annotations to a large Python codebase over the last few years. about this event: https://bobkonf.de/2022/clifford.html Fri, 11 Mar 2022 16:20:00 +0100 https://cdn.media.ccc.de/events/bobkonf/2022/mp3/bob2022-111-eng-Python_Gradual_Typing_The_Good_The_Bad_and_the_Ugly_mp3.mp3?1662381526 e5a1674a-c90d-400e-bed3-b6b7d028e845 2022-03-11T16:20:00+01:00 Ben Clifford No bob2022, 111, 2022, Talk, BOB, BOBKonferenz Python is well known as a dynamically typed language, but it has an increasingly mature system of type annotations which can be gradually introduced to an existing code base. I’d like to tell you some good stuff, some bad stuff and some terrible stuff - based around my experience adding type annotations to a large Python codebase over the last few years. about this event: https://bobkonf.de/2022/clifford.html 00:35:16 https://media.ccc.de/v/bob2022-event-sourcing-without-responsibility-sperber This is a follow-up to Andreas Bernauer’s talk from BOB 2016: The talk examines the implementation of event-sourcing in a highly distributed application for configuration management in a large network of car shops among mobile devices that are only sporadically connected. When building an event-sourced systems, it’s a common reflex to construct projections to answer queries instead of sifting through the event stream, using the CQRS paradigm. However, CQRS might not quite be the best way to organize an event-sourced system: The concept of “responbility” is foggy in many contexts, and the separation between “read models” and “write models” is the wrong axis to use for organizing storage and indexing. Moreover, CQRS may lead to implementing read models prematurely and unnecessarily. We demonstrate how the implementation of event sourcing and CQRS played out in our configuration-management application, and reflect the implications for the architecture of future systems. about this event: https://bobkonf.de/2022/sperber.html Fri, 11 Mar 2022 10:15:00 +0100 https://cdn.media.ccc.de/events/bobkonf/2022/mp3/bob2022-1-eng-Event_Sourcing_without_Responsibility_mp3.mp3?1662377672 d7b66364-d749-4529-9daf-41f8ff76b5e0 2022-03-11T10:15:00+01:00 Michael Sperber No bob2022, 1, 2022, Talk, BOB, BOBKonferenz This is a follow-up to Andreas Bernauer’s talk from BOB 2016: The talk examines the implementation of event-sourcing in a highly distributed application for configuration management in a large network of car shops among mobile devices that are only sporadically connected. When building an event-sourced systems, it’s a common reflex to construct projections to answer queries instead of sifting through the event stream, using the CQRS paradigm. However, CQRS might not quite be the best way to organize an event-sourced system: The concept of “responbility” is foggy in many contexts, and the separation between “read models” and “write models” is the wrong axis to use for organizing storage and indexing. Moreover, CQRS may lead to implementing read models prematurely and unnecessarily. We demonstrate how the implementation of event sourcing and CQRS played out in our configuration-management application, and reflect the implications for the architecture of future systems. about this event: https://bobkonf.de/2022/sperber.html 00:29:59 https://media.ccc.de/v/bob2022-infrastructure-as-code-digel Der Mehrwert jeder Software kann frühstens erlangt werden, wenn sie betrieben wird. In vielen Fällen ist das dann der Fall, wenn sie auf entsprechender Infrastruktur installiert und betriebsbereit ist. Dafür benötigen wir die Infrastruktur, müssen diese mit Betriebssystemen und nötigen Softwarekomponenten versehen und konfigurieren. Dies ist bei kleinen Systemen oft trivial, doch bei zunehmender Komplexität stellt sich schnell heraus, dass der Aufbau und die Wartung einer stabilen Infrastruktur schwierig ist. Daher sollen alle nötigen Schritte automatisiert werden, nachvollziehbar sein und jederzeit reproduzierbar durchgeführt werden können. Dafür kommt Infrastructure as Code zum Einsatz. Alle nötigen Definitionen und nötigen Schritte werden mit Konfigurationsdateien, als Code oder mit Domain Specific Languages (DSL) zum eigentlichen Quellcode der Software festgehalten. Mit Terraform wird die Infrastruktur an sich definiert. Dabei wird z. B. festgelegt, wie viele virtuelle Maschinen mit welchen Ressourcen benötigt werden, wie die Netzwerk- und IP-Konfiguration erfolgen oder in welchem Rechenzentrum die Software betrieben werden soll. Sobald die Infrastruktur vorhanden und zugänglich ist, muss diese konfiguriert werden. Mit Ansible und NixOS gibt es zwei Ansätze jeden Installations- und Konfigurationsschritt zu definieren und automatisch zur Anwendung zu bringen. Im Betrieb stellt man sich dann der nächsten Herausforderung: Software muss häufig und regelmäßig aktualisiert werden. Eine Automatisierung ist nahezu unumgänglich. Mit Continuous Deployment und als Code definierten Schritten in z. B. Github Actions gelangt die Software vollautomatisch auf die Infrastruktur. about this event: Fri, 11 Mar 2022 14:15:00 +0100 https://cdn.media.ccc.de/events/bobkonf/2022/mp3/bob2022-97-deu-Infrastructure_as_Code_-_Betrieb_ohne_Handarbeit_mp3.mp3?1662380223 23da2ed0-c750-4ded-a812-422d3b0907bc 2022-03-11T14:15:00+01:00 Tim Digel No bob2022, 2022, Talk, BOB, BOBKonferenz Der Mehrwert jeder Software kann frühstens erlangt werden, wenn sie betrieben wird. In vielen Fällen ist das dann der Fall, wenn sie auf entsprechender Infrastruktur installiert und betriebsbereit ist. Dafür benötigen wir die Infrastruktur, müssen diese mit Betriebssystemen und nötigen Softwarekomponenten versehen und konfigurieren. Dies ist bei kleinen Systemen oft trivial, doch bei zunehmender Komplexität stellt sich schnell heraus, dass der Aufbau und die Wartung einer stabilen Infrastruktur schwierig ist. Daher sollen alle nötigen Schritte automatisiert werden, nachvollziehbar sein und jederzeit reproduzierbar durchgeführt werden können. Dafür kommt Infrastructure as Code zum Einsatz. Alle nötigen Definitionen und nötigen Schritte werden mit Konfigurationsdateien, als Code oder mit Domain Specific Languages (DSL) zum eigentlichen Quellcode der Software festgehalten. Mit Terraform wird die Infrastruktur an sich definiert. Dabei wird z. B. festgelegt, wie viele virtuelle Maschinen mit welchen Ressourcen benötigt werden, wie die Netzwerk- und IP-Konfiguration erfolgen oder in welchem Rechenzentrum die Software betrieben werden soll. Sobald die Infrastruktur vorhanden und zugänglich ist, muss diese konfiguriert werden. Mit Ansible und NixOS gibt es zwei Ansätze jeden Installations- und Konfigurationsschritt zu definieren und automatisch zur Anwendung zu bringen. Im Betrieb stellt man sich dann der nächsten Herausforderung: Software muss häufig und regelmäßig aktualisiert werden. Eine Automatisierung ist nahezu unumgänglich. Mit Continuous Deployment und als Code definierten Schritten in z. B. Github Actions gelangt die Software vollautomatisch auf die Infrastruktur. about this event: 00:41:45 media.ccc.de / RSS 0.3.1 CCC media team media@c3voc.de CCC media team No CCC Congress Hacking Security Netzpolitik A wide variety of video material distributed by the CCC. All content is taken from cdn.media.ccc.de and media.ccc.de A wide variety of video material distributed by the Chaos Computer Club. This feed contains all events from bobkonf2022 as mp3