"Tools sind nicht so wichtig wie die Fähigkeit, über die von ihnen erstellten Systeme nachzudenken." Tolles Interview mit Martin Kleppman



Martin Kleppman ist Forscher an der Universität von Cambridge und beschäftigt sich mit CRDT und der formalen Verifizierung von Algorithmen. Sein 2017 veröffentlichtes Buch Designing Data-Intensive Applications hat sich zu einem Bestseller in der Datenspeicherung und -verarbeitung entwickelt.

Kevin Scott (CTO bei Microsoft) sagte einmal: „Dieses Buch sollte ein Muss für Entwicklungsingenieure sein. "Dies ist eine seltene Ressource, die Theorie und Praxis kombiniert und Entwicklern hilft, tiefer über das Design und die Implementierung von Infrastruktur- und Datenverarbeitungssystemen nachzudenken." Ähnliches sagte Jay Kreps, der Schöpfer von Apache Kafka und CEO Confluent.

Vor Beginn der akademischen Forschung arbeitete Martin in der Branche und war Mitbegründer zweier erfolgreicher Startups: Rapportive (2012 von LinkedIn gekauft) und Go Test It (von RedGate gekauft).

Dieser Habrapost ist ein ausführliches Interview mit Martin. Beispiel für Diskussionsthemen:

  • Übergang von der Wirtschaft zur akademischen Forschung;
  • Voraussetzungen für das Schreiben des Entwurfs datenintensiver Anwendungen;
  • Gesunder Menschenverstand gegen künstlichen Hype und Werbemittel;
  • Unnötigkeit des GAP-Theorems und andere Branchenfehler;
  • Der Nutzen der Dezentralisierung;
  • Blockchains, Dat, IPFS, Filecoin, WebRTC;
  • Neues CRDT. Formale Überprüfung bei Isabelle;
  • Diskussion über Event Sourcing. Low-Level-Ansatz. XA-Transaktionen
  • Apache Kafka, PostgreSQL, Memcached, Redis, Elasticsearch;
  • Alles im wirklichen Leben benutzen;
  • Die Schwelle für die Eingabe von Martins Berichten und der Hydra-Konferenz.

Das Interview wurde von Vadim Tsesko ( @incubos ) geführt - einem führenden Entwickler im Team des Unternehmens Odnoklassniki Platform. Die wissenschaftlichen und technischen Interessen von Vadim beziehen sich auf verteilte Systeme und Data Warehouses sowie auf die Überprüfung von Softwaresystemen.

Von der Wirtschaft zur akademischen Forschung


Vadim : Ich möchte mit einer Frage beginnen, die für mich persönlich sehr wichtig ist. Sie haben Go Test It und Rapportive gegründet und sich lange Zeit mit der Entwicklung großer Systeme auf LinkedIn befasst, sich dann aber entschieden, die kommerzielle Entwicklung zu verlassen und an der Universität zu forschen. Können Sie mir sagen, was Sie dazu gebracht hat? Was sind die Vorteile einer Universitätsarbeit und was haben Sie geopfert?

Martin : Es war ein sehr interessanter Übergang. So wie ich es verstehe, interessieren Sie sich für meine Entscheidung aufgrund der Tatsache, dass einige Leute aus der kommerziellen Entwicklung zur akademischen Forschung abreisen, viel häufiger gibt es eine Bewegung in die entgegengesetzte Richtung. Dies ist verständlich, da die Einnahmen an Universitäten deutlich niedriger sind als in der Wirtschaft. Ich persönlich fühle mich von der Position eines Forschers angezogen, weil ich selbst entscheiden kann, an welchen Themen ich arbeiten möchte, und ich treffe diese Wahl auf der Grundlage dessen, was mir interessant und wichtig erscheint, auch wenn die Arbeit an einem Thema keinen Gewinn in den nächsten 6 Jahren verspricht Monate. Alles, wofür Sie in einem Unternehmen arbeiten, muss in der einen oder anderen Form verkauft werden. Im Moment arbeite ich an Themen, die für die Zukunft des Internets und der Software wichtig sind, aber unser Verständnis ist noch nicht tief genug, um ein fertiges Produkt zu erstellen. Bisher haben wir noch nicht einmal eine allgemeine Vorstellung davon, wie diese Technologien funktionieren sollten. Da diese Studien von grundlegender Bedeutung sind, habe ich beschlossen, dass es besser ist, sie an der Universität und nicht im Unternehmen durchzuführen: Die Universität hat mehr Freiheit, dort können Sie Dinge tun, die für weitere 10 Jahre keinen Gewinn bringen. Der Planungshorizont ist viel weiter.

Buchgestaltung datenintensiver Anwendungen


Vadim : Wir werden auf jeden Fall auf das Thema Forschung zurückkommen, aber lassen Sie uns zunächst über Ihr Buch " Entwerfen datenintensiver Anwendungen " sprechen. Meiner Meinung nach ist dies einer der besten Leitfäden für moderne verteilte Systeme, fast eine Enzyklopädie: Er listet alle bedeutenden Errungenschaften auf, die es heute gibt.

Martin : Danke, ich bin froh, dass es sich als nützlich erwiesen hat.

Vadim : Es ist unwahrscheinlich, dass unsere Leser noch nicht damit vertraut sind, aber für den Fall, lassen Sie uns die wichtigsten Errungenschaften auf dem Gebiet der verteilten Systeme diskutieren, über die Sie schreiben.

Martin : Eigentlich habe ich mir beim Schreiben dieses Buches kein Ziel gesetzt, bestimmte Technologien zu beschreiben. Ich wollte vielmehr einen Leitfaden für die Welt der Systeme erstellen, die zum Speichern und Verarbeiten von Daten verwendet werden. Mittlerweile gibt es eine große Anzahl von Datenbanken, Stream-Prozessoren, Stapelverarbeitungswerkzeugen, Replikationswerkzeugen aller Art und dergleichen. Daher ist es sehr schwierig, ein Gesamtbild dieses Bereichs zu erstellen. Und wenn Sie eine Datenbank benötigen, um ein bestimmtes Problem zu lösen, ist es schwierig, eine der vielen vorhandenen auszuwählen. Viele Bücher über solche Systeme sind in diesem Fall einfach nutzlos. Zum Beispiel kann in einem Buch über Apache Cassandra geschrieben werden, wie wunderbar Cassandra ist, aber es wird nichts über Aufgaben gesagt, für die es nicht geeignet ist. Daher versuche ich in meinem Buch, die grundlegenden Fragen zu identifizieren, die Sie sich beim Schreiben großer Systeme stellen müssen. Antworten auf diese Fragen helfen festzustellen, welche Technologien zur Lösung des aktuellen Problems gut geeignet sind und welche nicht sehr gut. Die Hauptsache ist, dass es keine Technologie gibt, die alles kann. Ich versuche zu zeigen, welche Vor- und Nachteile unterschiedliche Technologien in unterschiedlichen Kontexten haben.

Vadim : In der Tat haben viele Technologien gemeinsame Merkmale und Funktionen und bieten dasselbe Datenmodell. Gleichzeitig kann man der Werbung nicht vertrauen, und um die interne Struktur des Systems zu verstehen, muss man nicht nur technische Berichte und Dokumentationen, sondern auch Quellcodes lesen.

Gesunder Menschenverstand versus künstlicher Hype und Werkzeugwerbung


Martin : Außerdem muss man oft zwischen den Zeilen lesen, weil die Dokumentation nicht sagt, für welche Aufgaben die Datenbank nicht sehr geeignet ist. Tatsächlich hat jede Datenbank ihre eigenen Einschränkungen, sodass Sie immer wissen sollten, welche. Oft müssen Sie Bereitstellungshandbücher lesen und den internen Betrieb des Systems rekonstruieren.

Vadim : Ja, das ist ein großartiges Beispiel. Glauben Sie nicht, dass es in diesem Bereich nicht genügend gemeinsames Vokabular oder einen einzigen Kriteriensatz gibt, anhand dessen verschiedene Lösungen für eine Aufgabe verglichen werden könnten? Jetzt werden unterschiedliche Namen für die gleichen Dinge verwendet, und viele Aspekte, die klar und deutlich formuliert werden sollten, werden überhaupt nicht erwähnt - zum Beispiel Garantien für Transaktionsfähigkeit.

Martin : Ja, das ist es wirklich. Leider gibt es in unserer Branche sehr oft eine übermäßige Aufregung um verschiedene Instrumente. Das ist verständlich, da diese Tools von Unternehmen entwickelt werden, die an der Werbung für ihre Produkte interessiert sind. Daher schicken diese Unternehmen Leute zu Konferenzen und sprechen im Wesentlichen darüber, was diese Produkte großartig sind. Dies tarnt sich als technischer Bericht, ist aber im Wesentlichen eine Werbung. Es würde uns als Branche nicht schaden, ehrlicher über die Vor- und Nachteile unserer Produkte zu sein. Eine der Voraussetzungen hierfür ist die allgemeine Terminologie, ohne die es unmöglich ist, Dinge zu vergleichen. Darüber hinaus werden Methoden benötigt, um die Vor- und Nachteile verschiedener Technologien zu analysieren.

Unnötige GAP-Theoreme und andere Branchenfehler


Vadim : Meine nächste Frage ist sehr heikel. Können Sie uns etwas über häufige Fehler in unserer Branche erzählen, auf die Sie während Ihrer Karriere gestoßen sind? Zum Beispiel über eine überbewertete Technologie oder eine weit verbreitete Lösung, die Sie längst hätten loswerden sollen? Dies ist vielleicht nicht das beste Beispiel, aber ich denke, JSON über HTTP / 1.1 anstelle von gRPC über HTTP / 2 zu verwenden. Oder teilen Sie diesen Standpunkt nicht?

Martin : Wenn man Systeme erstellt, muss man meistens etwas anderes opfern, um eines zu erreichen, und hier möchte ich lieber nicht über Fehler sprechen. Bei der Wahl zwischen JSON über HTTP / 1.1 und beispielsweise Protokollpuffern über HTTP / 2 haben beide Optionen ein Existenzrecht. Wenn Sie sich für die Verwendung von Protokollpuffern entscheiden, müssen Sie ein Schema definieren. Dies kann sehr nützlich sein, da es dabei hilft, das Verhalten des Systems genau zu bestimmen. In einigen Situationen verursacht ein solches Schema jedoch nur Ärger, insbesondere in den frühen Entwicklungsstadien, in denen sich die Datenformate häufig ändern. Auch hier muss man etwas opfern, um ein bestimmtes Ziel zu erreichen, und in einigen Situationen ist dies gerechtfertigt, in anderen jedoch nicht. Es gibt nicht so viele Lösungen, die wirklich als falsch bezeichnet werden können. Aber da wir darüber sprechen, lassen Sie uns über den CAP-Satz sprechen - meiner Meinung nach gibt es absolut keinen Nutzen daraus. Wenn es beim Entwurf von Systemen verwendet wird, liegt entweder ein Missverständnis der Bedeutung des GAP-Theorems vor oder es werden selbstverständliche Aussagen mit dessen Hilfe begründet. Es wird ein sehr eng definiertes Konsistenzmodell verwendet - Linearisierbarkeit und ein sehr eng definiertes Eingabehilfenmodell -. Jedes Replikat muss vollständig zugänglich sein, auch wenn keine Verbindung mit einem anderen Replikat hergestellt werden kann. Einerseits sind diese Definitionen ganz richtig, andererseits sind sie zu eng: Viele Anwendungen benötigen einfach keine solche Definition von Konsistenz oder Zugänglichkeit. Und wenn die Anwendung eine andere Definition dieser Wörter verwendet, ist der CAP-Satz für ihn nutzlos. Ich sehe also nicht viel Sinn darin, es anzuwenden. Übrigens, seit wir über Fehler in unserer Branche gesprochen haben, geben wir ehrlich zu, dass Cryptocurrency Mining eine völlige Verschwendung von Elektrizität ist. Ich verstehe nicht, wie Sie das ernsthaft tun können.

Vadim : Außerdem können die meisten Speichertechnologien jetzt für eine bestimmte Aufgabe angepasst werden, d. H. Bei Fehlern können Sie die entsprechende Betriebsart auswählen.

Martin : Richtig. Darüber hinaus fällt ein wesentlicher Teil der Technologien nicht unter die strikte Definition der Konsistenz und Zugänglichkeit des CAP-Theorems, dh es handelt sich nicht um CP, nicht um AP und nicht um CA, sondern nur um P. Niemand wird direkt über diese Software schreiben, aber in Wirklichkeit kann dies Seien Sie eine vollkommen rationale Entwicklungsstrategie. Dies ist einer der Gründe, warum ich glaube, dass CAP bei der Analyse von Software eher schädlich als gut ist: Ein wesentlicher Teil der Entwurfsentscheidungen wird in keiner Weise dargestellt, und es kann sich um recht rationale Lösungen handeln, aber CAP lässt keine Beschreibung zu.

Die Vorteile der Dezentralisierung


Vadim : Was sind derzeit die akutesten Probleme bei der Entwicklung datenintensiver Anwendungen? Welche Themen werden am aktivsten untersucht? Soweit ich weiß, unterstützen Sie dezentrales Computing und dezentrales Data Warehousing.

Martin : Ja. Einer der Punkte, die ich in meiner Forschung beweise, ist, dass wir uns derzeit zu stark auf Server und Zentralisierung verlassen. In den frühen Tagen des Internets, als es sich aus ARPANET entwickelte, wurde es als hochstabiles Netzwerk konzipiert, in dem Pakete auf verschiedenen Routen gesendet werden können und dennoch ihr Ziel erreichen. Im Falle einer nuklearen Explosion in einer Stadt in Amerika würde der überlebende Teil des Netzwerks weiter funktionieren, alternative Routen würden einfach verwendet, um die ausgefallenen Abschnitte zu umgehen. Es war ein Schema des Kalten Krieges. Aber dann haben wir beschlossen, alles in der Cloud zu platzieren, und jetzt passiert fast alles irgendwie eines der AWS-Zentren irgendwo in Virginia im Osten der USA. Irgendwann haben wir das Ideal der dezentralen Nutzung verschiedener Teile des Netzwerks aufgegeben und die Dienste identifiziert, von denen jetzt alles abhängt. Ich halte es für wichtig, zu einem dezentralen Ansatz zurückzukehren, bei dem mehr Kontrolle über die Daten nicht den Diensten, sondern den Endbenutzern gehört.

Wenn es um Dezentralisierung geht, meinen sie sehr oft Dinge wie Kryptowährungen, weil sie Netzwerke interagierender Agenten haben, über die es keine einzige zentralisierte Behörde wie eine Bank gibt. Dies ist jedoch nicht die Dezentralisierung, von der ich spreche, da Kryptowährungen meiner Meinung nach auch extrem zentralisiert sind: Wenn Sie einen Deal mit Bitcoin abschließen müssen, muss dies über das Bitcoin-Netzwerk erfolgen, sodass alles um dieses Netzwerk herum zentralisiert ist. Die Netzwerkstruktur ist in dem Sinne dezentralisiert, dass sie kein einziges Organisationszentrum hat, sondern das gesamte Netzwerk extrem zentralisiert ist, da jede Transaktion über dieses Netzwerk und nichts anderes erfolgen muss. Ich glaube, dass dies auch eine Form der Zentralisierung ist. Bei Kryptowährungen ist dies unvermeidlich, da sichergestellt werden muss, dass keine doppelten Kosten anfallen, und dies ist ohne ein Netzwerk, das einen Konsens darüber liefert, welche Transaktionen abgeschlossen wurden, und dergleichen, nur schwer zu erreichen. Es gibt jedoch viele Anwendungen, für die kein System wie eine Blockchain erforderlich ist. Sie können mit einem viel flexibleren Datenmodell arbeiten. Es sind diese dezentralen Systeme, die mich am meisten interessieren.

Vadim : Können Sie uns, seit Sie die Blockchain erwähnt haben, über vielversprechende oder nicht bekannte Technologien im Bereich dezentraler Systeme berichten? Ich selbst habe mit IPFS gespielt, aber Sie haben viel mehr Erfahrung in diesem Bereich.

Martin : Tatsächlich verfolge ich solche Technologien nicht aktiv. Ich habe ein wenig über IPFS gelesen, es aber selbst nicht verwendet. Wir haben ein bisschen mit Dat gearbeitet , das wie IPFS eine dezentrale Speichertechnologie ist. Der Unterschied besteht darin, dass die Filecoin-Kryptowährung an IPFS gebunden ist und zur Bezahlung der Datenspeicherung verwendet wird und keine Blockchain an Dat gebunden ist. Mit Dat können Sie nur Daten auf P2P-Basis auf mehrere Computer replizieren. Für das Projekt, an dem wir gearbeitet haben, ist Dat großartig. Wir haben eine Software geschrieben, mit der Benutzer an einem Dokument, Daten oder einer Datenbank zusammenarbeiten können. Jede Änderung dieser Daten wird an alle Personen gesendet, die über eine Kopie der Daten verfügen. In einem solchen System kann Dat nach dem P2P-Prinzip verwendet werden, so dass der Betrieb auf Netzwerkebene, dh NAT Traversal, und das Durchlaufen von Firewalls sichergestellt wird, was eine ziemlich schwierige Aufgabe ist. Darüber hinaus haben wir eine CRDT-Ebene geschrieben, mit deren Hilfe mehrere Personen ein Dokument oder einen Datensatz bearbeiten konnten und die es ermöglichte, Änderungen schnell und bequem gemeinsam zu nutzen. Ich denke, ein ähnliches System könnte über IPFS geschrieben werden, während Filecoin ignoriert und nur die P2P-Replikation verwendet wird.

Vadim : Aber wäre ein solches System nicht weniger reaktionsschnell geworden, weil WebRTC Knoten direkt miteinander verbindet und IPFS eher eine verteilte Hash-Tabelle ist.

Martin : Die Sache ist, WebRTC ist eine etwas andere Stack-Ebene. Es ist hauptsächlich für Videoanrufe gedacht - mit hoher Wahrscheinlichkeit wird es in der Software verwendet, über die wir jetzt kommunizieren. Darüber hinaus bietet WebRTC einen Kanal, über den Sie beliebige Binärdaten senden können. Es kann jedoch schwierig sein, ein Replikationssystem darüber zu erstellen. In Dat und IPFS müssen Sie jedoch nichts dafür tun.

Sie haben die Reaktionsfähigkeit erwähnt, und dies ist ein wirklich wichtiger Faktor, den Sie berücksichtigen sollten. Angenommen, wir möchten die nächsten Google Text & Tabellen dezentralisieren. In Google Text & Tabellen ist die Änderungseinheit ein einzelner Tastendruck, und jedes neue Zeichen kann in Echtzeit an andere Personen gesendet werden, die mit demselben Dokument arbeiten. Dies gewährleistet einerseits eine schnelle Zusammenarbeit, andererseits bedeutet dies, dass Sie beim Schreiben eines großen Dokuments Hunderttausende von Änderungen mit einem Zeichen senden müssen und viele vorhandene Technologien diese Art der Datenkomprimierung nur schlecht bewältigen können. Selbst wenn wir davon ausgehen, dass für jeden Tastendruck nur hundert Bytes gesendet werden müssen, müssen für ein Dokument mit 100.000 Zeichen 10 MB Daten gesendet werden, obwohl ein solches Dokument normalerweise nicht mehr als einige zehn Kilobyte benötigt. Bis ein ausgeklügeltes Komprimierungsverfahren erfunden wurde, erfordert eine solche Datensynchronisation enorme zusätzliche Ressourcenkosten. Viele P2P-Systeme verfügen noch nicht über eine effektive Möglichkeit, Snapshots des Status zu erstellen, mit denen sie für ein System wie Google Text & Tabellen verwendet werden können. An diesem Problem arbeite ich gerade und versuche, einen Algorithmus für eine effizientere Dokumentensynchronisierung für mehrere Benutzer zu erstellen. Dies sollte ein Algorithmus sein, der nicht jeden einzelnen Tastendruck speichert, da dies zu viele Ressourcen erfordert und eine effizientere Nutzung des Netzwerks ermöglichen sollte.

Neues CRDT, formale Überprüfung bei Isabelle


Vadim : Können Sie uns mehr darüber erzählen? Haben Sie es geschafft, mehr als 100-fache Datenkomprimierung zu erreichen? Sprechen Sie über neue Komprimierungstechniken oder spezielle CRDTs?

Martin : Ja. Bisher haben wir nur einen Prototyp, der noch nicht vollständig implementiert wurde. Zusätzliche Experimente müssen durchgeführt werden, um herauszufinden, wie effektiv es in der Praxis ist. Einige unserer Methoden sind jedoch vielversprechend. In meinem Prototyp konnte ich die Größe einer einzelnen Bearbeitung von 100 auf 1,7 Byte reduzieren. Aber ich wiederhole, dies ist bisher nur eine experimentelle Version, dieser Indikator kann sich geringfügig ändern. Auf die eine oder andere Weise gibt es in diesem Bereich große Optimierungsmöglichkeiten.

Vadim : In Ihrem Bericht auf der Hydra-Konferenz geht es also darum?

Martin : Ja. Ich werde eine kurze Einführung in CRDT, Collaboration-Software und einige Probleme geben, die in diesem Zusammenhang auftreten. Dann werde ich über die Forschung sprechen, die wir in diesem Bereich betreiben - sie befassen sich mit vielen verschiedenen Problemen. Auf der Anwendungsseite haben wir eine Implementierung dieser Algorithmen in JavaScript. Darauf aufbauend erstellen wir funktionierende Programme, um das Verhalten der Algorithmen besser zu verstehen. Gleichzeitig arbeiten wir an formalen Methoden, um die Richtigkeit dieser Algorithmen zu beweisen, da einige von ihnen eher nicht offensichtlich sind und wir sicherstellen möchten, dass sie immer einen konsistenten Zustand erreichen. Viele zuvor entwickelte Algorithmen bieten in einigen Grenzfällen keine Konsistenz. Um dies zu vermeiden, haben wir uns formalen Methoden zum Nachweis der Korrektheit zugewandt.

Vadim : Verwenden Sie für dieses System Theorembeweise wie Coq oder Isabelle?

Martin : Ja, Isabelle .

Anmerkung der Redaktion: Martin wird im The Strange Loop einen Vortrag über Isabelle lesen .

Vadim : Planen Sie diese Beweise zu veröffentlichen?

Martin : Ja, die ersten Beweise, die wir vor anderthalb Jahren zusammen mit dem CRDT-Überprüfungsrahmen veröffentlicht haben. Wir haben drei CRDTs mit diesem Framework getestet. Das wichtigste davon war RGA ( Replicated Growable Array ), CRDT für die gemeinsame Bearbeitung von Text. Dieser Algorithmus ist nicht zu kompliziert, sondern nicht offensichtlich, da nicht sofort klar ist, ob er korrekt ist, weshalb ein formaler Beweis erforderlich war. Wir haben auch daran gearbeitet, die Richtigkeit mehrerer vorhandener CRDTs zu beweisen, und das letzte, was wir in diesem Bereich getan haben, war die Erstellung eigener CRDTs für neue Datenmodelle.

Vadim : Wie viel größer ist das Volumen des formalen Beweises als die Codegröße des Algorithmus selbst? Es gibt manchmal Schwierigkeiten damit.

Martin : Wirklich genug Schwierigkeiten, wir müssen viel mit Beweisen arbeiten. : 60 , , 800 . , 12 . , . , . , . . , .

: , ? ?

: , . , . : TCP, Git . , , . , . . , .

Event sourcing, , XA-


: , . , event sourcing. , - . event sourcing ? - , .

: . Event sourcing , , . , event sourcing . , , , . , event sourcing () .

event sourcing . Apache Kafka. Event sourcing Apache Kafka, , . event sourcing Apache Kafka , , , event sourcing. , , , . Apache Kafka , , , , , . Apache Kafka . Apache Kafka , . , Elasticsearch, Memcached Redis.

, , event sourcing. , . , , . — , . , event sourcing. : PostgreSQL , . , Kafka. , , .

: . , , , , .

: , , JSON (, PostgreSQL ) . , . . , .

: event sourcing. , . , (, ), : Elasticsearch, ; , key-value Memcached; , . .

: , , , — ?

: . , , , , , 404, .

: . (causal consitency) . , . , : , , . , , - . . , , , Elasticsearch Memcached. , , , . , snapshot isolation: , , . . , , . Memcached Elasticsearch . , , Memcached, Redis, Elasticsearch , . , , . , . . , . , , — , . . , . , - , .

: , Multiversion Concurrency Control .

: , . XA-, , , . , , . , , . XA . , , . .

: , - .

: , . , , , . , . - , . , . - , : , , , . . , .

: , . , . - , , , - .

: . . , , . , .

: , . event sourcing. , , , . , . , , , . , , , , , . ?

: , . , , . , , , , . . , . , , .

: , , , .

: . , . , . , , , . (, - ), . . - , . — , . , , , , 100%, .

: . .

: .

: , , . , — , . .

Hydra 2019,


: , Hydra? , , , .

: , , , , « » « ». . . , , - ; , , , , .

: , , , ? . , , ?

: , . , . , . - . , - , - . , . : , . — , — . , , , .

: . ? , - , , ?

: . . , . , , , . - — . , , . : . , , Slack , . , , . , , , .

: .

: , .

: , !

Ich erinnere Sie daran, dass dies ein aufgezeichnetes Interview ist. Denken Sie beim Schreiben von Kommentaren daran, dass Martin sie nicht liest. Wir können nur etwas sehr Interessantes vermitteln. Wenn Sie wirklich mit dem Autor sprechen möchten, wird er auf der Hydra 2019-Konferenz, die vom 11. bis 12. Juli 2019 in St. Petersburg stattfindet , einen Vortrag zum Thema „Synchronisieren von Daten zwischen Benutzergeräten für die verteilte Zusammenarbeit“ halten . Tickets können auf der offiziellen Website gekauft werden .

Source: https://habr.com/ru/post/de457736/


All Articles