<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="/feed.rss.xml" type="text/xsl" media="screen"?>
<rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:media="http://search.yahoo.com/mrss/" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>DaveFar</title>
    <description/>
    <link>https://speakerdeck.com/davefar</link>
    <atom:link rel="self" type="application/rss+xml" href="https://speakerdeck.com/davefar.rss"/>
    <lastBuildDate>2020-01-30 02:40:37 -0500</lastBuildDate>
    <item>
      <title>Testen von Microservices -- Erfahrungsbericht und Umfrage</title>
      <description>Keynote zusammen mit Dehla Sokenou  auf der TAV 44 (https://fg-tav.gi.de/veranstaltung/44-tav): Wegen der Art und Häufigkeit der Fehler in Microservice-Architekturen sollten wir mehr Tests auf höherer Teststufe durchführen und diese im Gesamtsystem ausführen, woraus sich das Test-Rechteck ergibt. Dies entspricht der Dev/Prod-Parity. Andererseits entstehen im Microservice-Umfeld gerade viele Testwerkzeuge, die einen anderen Ansatz verfolgen: die Tests leichtgewichtiger auszuführen als im Gesamtsystem, und trotzdem möglichst viele Fehler finden. (Wann) wird es diesen Tools gelingen, den Tool-Gap so stark zu verkleinern, dass der Dev/Prod-Parity obsolet wird? Wenn die Tests technisch sauber in Testtreiber und Orakel aufgeteilt werden, können die Orakel für mehrere Testtreiber wiederverwendet werden, z.B. in leichtgewichtigeren Testwerkzeugen, aber auch für passives Testen wie Observability.</description>
      <media:content url="https://files.speakerdeck.com/presentations/26aed4d2a4f24908937b4fffa9155533/preview_slide_0.jpg?14762153" type="image/jpeg" medium="image"/>
      <content:encoded>Keynote zusammen mit Dehla Sokenou  auf der TAV 44 (https://fg-tav.gi.de/veranstaltung/44-tav): Wegen der Art und Häufigkeit der Fehler in Microservice-Architekturen sollten wir mehr Tests auf höherer Teststufe durchführen und diese im Gesamtsystem ausführen, woraus sich das Test-Rechteck ergibt. Dies entspricht der Dev/Prod-Parity. Andererseits entstehen im Microservice-Umfeld gerade viele Testwerkzeuge, die einen anderen Ansatz verfolgen: die Tests leichtgewichtiger auszuführen als im Gesamtsystem, und trotzdem möglichst viele Fehler finden. (Wann) wird es diesen Tools gelingen, den Tool-Gap so stark zu verkleinern, dass der Dev/Prod-Parity obsolet wird? Wenn die Tests technisch sauber in Testtreiber und Orakel aufgeteilt werden, können die Orakel für mehrere Testtreiber wiederverwendet werden, z.B. in leichtgewichtigeren Testwerkzeugen, aber auch für passives Testen wie Observability.</content:encoded>
      <pubDate>Thu, 14 Nov 2019 00:00:00 -0500</pubDate>
      <link>https://speakerdeck.com/davefar/testen-von-microservices-erfahrungsbericht-und-umfrage</link>
      <guid>https://speakerdeck.com/davefar/testen-von-microservices-erfahrungsbericht-und-umfrage</guid>
    </item>
    <item>
      <title>POLYMORPHIC INPUT ITERATORS</title>
      <description>Polymorphic input iterators in Modern C++ via std::variant.</description>
      <media:content url="https://files.speakerdeck.com/presentations/331890a06be84f08bb2f1f139a1c8101/preview_slide_0.jpg?14762182" type="image/jpeg" medium="image"/>
      <content:encoded>Polymorphic input iterators in Modern C++ via std::variant.</content:encoded>
      <pubDate>Wed, 09 Jan 2019 00:00:00 -0500</pubDate>
      <link>https://speakerdeck.com/davefar/polymorphic-input-iterators</link>
      <guid>https://speakerdeck.com/davefar/polymorphic-input-iterators</guid>
    </item>
  </channel>
</rss>
