Unter Android-Entwicklern ist
Artyom Zinnatullin so angesehen, dass Sie ein Analogon von „Fakten über Chuck Norris“ über ihn verfassen können - so etwas wie das:
- Artyom ist so hart, dass der Github selbst grün wird, wenn er ihn sieht (wer von uns kann sich eines solchen Beitragsplans rühmen?)
- Artyom ist so hart, dass Git für ihn ein Bote ist .
- Artyom ist so hart, dass es sich bei seinem Anwendungskontext um einen Podcast handelt .
Als wir ihn auf unserer Mobius-Konferenz interviewten, war sie für eine Online-Sendung vorgesehen. Nachdem wir im Android-Chat gesehen haben, wie sie darauf verweisen, haben wir beschlossen, dass es auch für viele auf Habré von Interesse sein könnte, und eine Textversion für Sie erstellt (wir fügen auch die Videoaufzeichnung bei).
Wie lebe ich mit einem Projekt in einer Million Codezeilen? Was ist der Nachteil von Corotin Kotlin? Was ist los mit Google? Wie unterscheidet sich die Entwicklung in San Francisco von der russischen? Worüber sprach der Mobius? Unter dem Schnitt - über all das.
Evgeny Trifonov : Bei diesem Mobius habe ich Ihren Vortrag „Android Builds at Lyft“ verpasst, aber danach habe ich eine Menge Leute gesehen, die im Diskussionsbereich eine Frage stellen wollten. Und ich wollte klarstellen: Aber schließlich arbeiten die meisten Zuschauer nicht in einem riesigen Projekt wie Lyft. War diese Erfahrung für sie überhaupt relevant?
Artyom : Das ist eine interessante Sache. Die ursprüngliche Gliederung des Berichts in meinem Kopf und die Art und Weise, wie ich ihn letztendlich umgesetzt habe, sind dank Ihres noblen Programmkomitees sehr unterschiedlich.
Anfangs wollte ich Ihnen erzählen, wie alles bei Lyft begann und warum wir zu bestimmten technischen Lösungen kamen. Er sprach zwei Stunden lang mit Sergey Boishtyan vom Programmkomitee, hörte zu und sagte: "Cool, natürlich, aber Sie haben eine Keynote gehalten." Und am Ende wurde mir klar, dass ein solcher Bericht natürlich interessant zu hören ist, aber für niemanden wirklich relevant.
Und dann habe ich es überarbeitet und den Schwerpunkt auf grundlegende technische Ansätze für die Auswahl von Montagesystemen und anderen Systemen verlagert. Ich hatte nicht das Ziel zu sagen, welche Tools wir speziell verwenden. Ich möchte nicht, dass jemand sie nimmt und blindlings benutzt und mir dann beeindruckende Briefe schreibt, in denen nicht alles so funktioniert, wie ich es Ihnen gesagt habe. Ich wollte genau die technischen Praktiken vermitteln, wie man eine Wahl trifft und was meiner (natürlich subjektiven) Meinung nach wichtig ist. Daher hoffe ich, dass die Erfahrung am Ende für mehr Menschen relevant ist und nicht nur "der Typ aus Lyft kam heraus und sagte etwas".
Oleg olegchir Chirukhin : Gibt es ungewöhnliche Lyft-Entscheidungen, die für andere schwer zu treffen sind?
Artyom : Ja natürlich. Wir haben zwei Build-Systeme gleichzeitig im Projekt, ich empfehle absolut niemanden
(lacht) .
Es ist sehr schmerzhaft zu behaupten: Sie jagen ständig zwei Fliegen mit einer Klappe nach, in beiden funktioniert etwas nicht bis zum Ende. Aber dies ist unser aktueller Zustand. Historisch gesehen mussten wir ein zweites System starten, da ein Build-System für einen Teil der Aufgaben zum Stillstand kam. Ich habe darüber gesprochen, wie man dies vermeidet und korrekt zu einem von ihnen migriert.
Oleg : Und welche Art von Build-Systemen?
Artyom : Wir verwenden Gradle und Buck, und ich habe darüber gesprochen, wie ich von Google zu Bazel komme.
Oleg : Dies ist eine Art Bewegung in Richtung des Bösen: vom hübschen Gradle bis zum Bazel, in dem es nicht einmal normale Abhängigkeiten gibt.
Artyom : Jetzt gibt es mehr oder weniger. Ja, natürlich gibt es Kompromisse, und natürlich hat Gradle seine Vorzüge. Es hängt alles von der Art des Projekts ab. Einige Gradle sind besser geeignet als Buck und Bazel, da sie einige grundlegende Punkte haben, die sie nicht schrittweise innerhalb desselben Moduls sammeln, Gradle jedoch, und für viele ist dies sehr wichtig. Und es ist cool, dass Gradle das kann.
Eine andere Sache ist, dass Gradle beim Hinzufügen von Modulen - mehr, mehr Module, achthundert, tausend - so neu gestaltet wird, dass die Baugruppe an einigen Stellen linear verlangsamt wird. Aber es scheint mir, dass Gradle all dies beheben kann, wenn die Community Druck auf sie ausübt - was ich vielleicht tue. Mal sehen.
(Anmerkung: Einige Tage nach diesem Interview schrieb Artyom einen langen Beitrag über Gradle-Probleme.)Oleg: Das heißt, Bazel nur, weil ich eine große Anzahl von Modulen unterstützen möchte?
Artyom : Sagen wir einfach, dass wir in unserem Fall keine Lust dazu haben, aber die Aufteilung des Projekts in Module ermöglicht es unserem Unternehmen, schneller voranzukommen. Grundsätzlich ist dies nach meinem Verständnis eine Isolation, damit keine Spaghetti entstehen, die dann schwer zu pflegen sind. Module geben mehr Kontrolle darüber, welche Teile des Codes mit welchen interagieren. Wir haben fast eine Million Codezeilen. Wenn es in einem Modul wäre, müsste ich Spaghetti. Denn zusätzlich zu der Sprache - Java, Kotlin - muss etwas abgewickelt werden, um Anrufe zwischen Paketen zu verbieten, zwischen denen niemand sie erwartet hat. Außerdem stellt sich die Frage, dass Gradle nicht so viel Code in einem Modul herausnimmt. Es wird nicht parallel gesammelt, sondern schrittweise im Modul zusammengebaut.
Jede Lösung hat Kompromisse. In unserem Fall scheint mir dies die richtige Lösung zu sein, aber es gibt ein Problem: Wir unterstützen derzeit zwei Build-Systeme.
Oleg : Und was ist besser für Hunderte von Modulen: Monorepo oder viele Repositories?
Artyom : Das ist ein sehr wunder Punkt. Wahrscheinlich ist ein Repository unter dem Gesichtspunkt besser, dass Sie nicht über die Versionierung nachdenken müssen, und es gibt diese Abhängigkeitshölle nicht, wenn Sie ein Dutzend Repositorys klonen, um eine Änderung vorzunehmen, und anschließend eine Pull-Anforderung und danach zehn weitere öffnen. "Reibung" wird aus dem System entfernt, und die Leute haben keine Angst, den Code zu ändern. Für sie ergibt sich eine Atomizität von Änderungen: Alles wird in einem Projekt zusammengefasst, und Änderungen von einem Modul werden ohne ihre ausdrückliche Zustimmung automatisch auf andere übertragen. Gleichzeitig werden alle Überprüfungen ausgeführt, die Sie automatisch in CI geschrieben haben, und es wird überprüft, ob der Code kompiliert, getestet und all dies ist.
Oleg : Und wenn Sie nicht zu der Tatsache kommen, dass Sie, wie in einigen Chrome, die Zweige für zwei Minuten wechseln, während Sie Tee trinken?
Artyom : Ja, natürlich gibt es eine Möglichkeit. Aber hier liegt die Frage wahrscheinlich schon in der Größe des Produkts: Muss Chrome so viel Code enthalten? Vielleicht lohnt es sich, einige Teile in separaten Instrumenten hervorzuheben, die sie regelmäßig festziehen, wenn größere Änderungen an ihnen auftreten? Dies ist wahrscheinlich eine Frage für die Organisation des Projekts. Cooles Beispiel übrigens. Ich habe eine ähnliche: Korrespondenz mit Jungs von Yandex.Browser, wo sie auch große Stecker haben.
Chrome kann in mehrere Komponenten unterteilt werden, und wenn Sie sich für V8 entscheiden, bin ich kein großer Spezialist, aber soweit ich weiß, könnte es sich im Allgemeinen um ein separates Projekt handeln, oder? Und warum sollte die GUI dann über die Engine Bescheid wissen, sie jedes Mal neu zusammenbauen und über den Quellcode nachdenken, der irgendwo in der Nähe liegt? Bazel unterstützt dies übrigens auch.
Im Allgemeinen unterstützen jetzt alle großen Build-Systeme - Gradle, Buck, Bazel - so etwas wie Composite-Builds, wenn Sie beispielsweise auf eine andere Bazel-Baugruppe verweisen. Dies ist eine schwierige Situation, aber es funktioniert trotzdem. Sie können einen Teil der Dateien aus dem Repository entfernen und die Größe reduzieren. Die IDE zum Beispiel wird verrückt werden, um all diese Dateien zu indizieren, deshalb möchte ich sie irgendwie von der allgemeinen Komponente des Projekts trennen.
Aber davon sind wir weit entfernt. Es scheint mir, dass wir ruhig weitere fünf Jahre rechnen können. Es ist unwahrscheinlich, dass wir noch eine zweiminütige Kasse haben. Wir haben nicht viele Leute.
Eugene : Hat Lyft neben zwei Build-Systemen noch eigene Besonderheiten?
Artyom : Ja, da gibt es ein paar atypische Geschichten. Es kam vor, dass Leute, die zum Unternehmen kamen (von Google, Facebook, überall), Mono-Repositories hassen. Aus diesem Grund haben wir bei Lyft drei Mono-Repositories: Android, iOS und L5 (dies sind unsere
autonomen Autos ).
Und alles andere sind mehr als 1.500 Git-Repositories: für alle Microservices, für alle Bibliotheken separat. Dies ist historisch gesehen der Fall. Dies hat seinen eigenen enormen Preis, den wir zahlen: Es ist wirklich schwierig, Änderungen durchzusetzen. Auf der anderen Seite, wenn Sie mit jedem von ihnen arbeiten, haben Sie sofortigen Git-Klon, sofortigen Git-Push, alles ist sehr schnell, die IDE-Indizes pro Sekunde. Ich kann sagen, dass dies wirklich ein interessanter Teil ist. Von den Jungs aus San Francisco würde ich ein einziges Repository erwarten.
Oleg : Und wenn eines dieser separaten Repositorys aktualisiert wird - beispielsweise die API-Änderungen - wie wirkt sich diese Änderung auf den Rest des Unternehmens aus?
Artyom: Es tut weh.
(lacht) Nun, ich bin kein Backend-Entwickler, da ich keine Feature-Backends schreibe, sondern Infrastruktur-Backends - sie sind in dieser Hinsicht normalerweise ziemlich autonom.
In der Regel handelt es sich hierbei nur um eine Reihe von Kundgebungen, gegenseitige Interaktion und anschließende Planung.
Oleg: Rallyes sind also Teil des Montagesystems? (lacht)
Artyom : Ja, zuerst müssen wir eine Rallye zusammenstellen, dann ein Repository. Außerdem haben wir historisch gesehen leider viele dieser Mikrodienste - dies ist Python, das auch seine eigenen Witze hat.
Oleg : Einige Abneigungen gegen Python sind ausgerutscht.
Artyom : Eher Abneigung gegen dynamisches Tippen. Python, nicht Python - es macht keinen Unterschied, aber dynamisches Tippen ist eine schmerzhafte Sache.
Eugene : Und es ist "für ein Unternehmen aus San Francisco" ausgerutscht, und es ist merkwürdig, dies zu fragen: Aber in Bezug auf die Entwicklung unterscheiden sich Unternehmen aus San Francisco von Unternehmen aus Russland. Gibt es einen spürbaren Unterschied?
Artyom : Ein sehr großer Unterschied. Ich bin kein großer Fan davon, es so zu klassifizieren, aber es scheint mir, dass hier eine korrektere Ingenieurschule ist.
Oleg : Hier - wo ist es?
Artyom : In Russland, in den Ländern der ehemaligen UdSSR. Die Menschen achten mehr auf die technischen Aspekte der Funktionsweise ihrer Systemkomponenten. In den USA kommt es häufig vor, dass eine Bibliothek ein Problem löst und die Leute nicht einmal sehen, wie es implementiert wird. Sie kümmern sich in der Regel überhaupt nicht darum, dass es langsamer wird oder dass sie es falsch verwenden.
Ich werde dort viele Leute interviewen, weil dies Teil der Arbeit ist und der allgemeine Wissensstand vielleicht noch niedriger ist. Es gibt etwas zu ändern. Jedes Mal, wenn eine Person aus Osteuropa kommt, wird es während der Interviews interessanter, weil die Menschen keine Angst haben, Widerstand zu leisten oder irgendwo zu streiten. Während US-Kandidaten sehr oft überhaupt keine Fragen beantworten oder antworten: "Ich erinnere mich nicht, wann ich es das letzte Mal benutzt habe." Bei Fragen wie "Wie funktioniert eine HTTP-Anfrage?" oder "Welches Datenformat wählen Sie?" Sie können keine normalen technischen Antworten geben, sondern sagen: "Nun, ich habe dies in den letzten fünf Jahren verwendet." Cool natürlich, aber der Lord zieht nicht.
Auf der anderen Seite gibt es Projekte, deren Vergleich mit dem, was wir hier machen, Jahre gedauert hat. Die Menschen stellen mehr Massenprodukte her und es gibt einfach mehr Skalierbarkeit. Zum Beispiel Chrome oder Uber - dort gibt es bereits mehr als tausend Module. Dies ist nur das Ausmaß der Probleme. Sagen wir in Uber unter dreihundert Android-Entwicklern. Es stellt sich die Frage: Warum?
(lacht) Trotzdem gelang es ihnen, diesen Koloss zum Laufen zu bringen und ihn ständig freizugeben. Ich würde sagen, dass solche Probleme hier weniger häufig gelöst werden.
Hier ist Yandex ein gutes Beispiel. Ich habe einen Freund auf Yandex.Maps: Zehn Leute machen eine Android-Anwendung. In Google sitzen höchstwahrscheinlich hundert. Gleichzeitig bietet Yandex.Mart mehr Funktionen. Das ist meiner Meinung nach der Unterschied.
Eugene : Darüber hinaus ist das Tal auch mit Start-ups verbunden, und sie verfolgen einen Ansatz, bei dem sie sich schnell bewegen und Dinge brechen, und es scheint, dass dies auch die Entwicklung beeinflussen sollte: Leben Sie auf dem neuesten Stand, verwenden Sie die neuesten. Es stimmt?
Artyom : Ich habe nicht in Startups gearbeitet, Lyft ist schwer zu nennen: Es gibt bereits dreitausenddrei Leute, irgendwo mehr als tausend von ihnen sind Ingenieure. Das heißt, es ist eine bereits gegründete Firma.
Es ist Spitzentechnologie, die selten eingesetzt wird. Wenn die Technologie hochgespielt ist, dann ja. Wenn die Technologie Nische ist, aber cool, sehr oft nicht. Bis alle Konferenzen darüber sprechen, werden nur sehr wenige Leute davon Gebrauch machen.
Aber zur gleichen Zeit, die ich wirklich liebe (in San Francisco und teilweise im Tal), werden viele Probleme gelöst, weil die Unternehmen physisch nahe beieinander liegen. Sehr oft schreiben Sie jemandem in einem Chatroom: „Lassen Sie uns gemeinsam bei uns oder in Ihrem Büro zu Mittag essen und entscheiden, dass wir eine Frage stellen“, und dann erscheint einmal - ein Open-Source-Projekt oder eine Pull-Anfrage in einem anderen Projekt, etwas behoben.
Was interessant ist: Menschen diskutieren oft Dinge, die eigentlich nicht in der NDA besprochen werden sollten. Aber so bewegt sich das ganze Tal, am Ende versteht jeder, wohin sich der Rest bewegt, und die ganze Branche gehört zusammen. Sagen wir, Lyft- und Uber-Mobilisten reden ständig über technische Dinge, weil wir Open Source von Uber verwenden. Und natürlich gibt es in einigen Technologien direkt Hardcore-Experten. Das ist auch cool: man kann einfach mit ihnen kreuzen.
Ich liebe das und das war mir in einigen Städten, in denen ich lebte, nicht genug. Hier in St. Petersburg gab es eine sehr coole Java-Benutzergruppe (ich weiß noch nicht, wie es jetzt ist): Sie kommen nach der Arbeit, und Shipilev nimmt Ihr Gehirn heraus, und etwas ist gut!
Und da erscheint es wieder: Zum Beispiel hat es auch eine eigene Java-Benutzergruppe, und es kommen oft Leute, zum Beispiel von Oracle, die einige neue Reactive JDBC gedreht haben. Und Sie sitzen, argumentieren, weil ein Projektreaktorleiter oder ein reaktiver Leiter im Frühjahr am selben Ort sitzt, eine hitzige Diskussion stattfindet, und das ist cool.
Oleg : Ich werde nach etwas anderem fragen: Ich habe mir
das Mainframer-
Repository angesehen und dort wird Rust verwendet. Warum steht das alles nicht auf dem gesegneten Javka, sondern auf einer Art Rost?
Artyom : Vor kurzem bin ich auf die Seite gegangen, dass das Programm eine minimale Menge an Ressourcen haben sollte. Das heißt, ich möchte sehr nahe daran sein, wie Eisen Bytes verdaut. Und in Java passieren viele Dinge (ich spreche nicht einmal über die Speicherbereinigung), das heißt JIT und all das. Ich mag es wirklich, dass Java jetzt auf die Tatsache zusteuert, dass es auch eine vorzeitige Kompilierung geben wird. Es scheint mir sehr cool zu sein, zum Beispiel den Start eines Microservices zu starten, indem man seine vorzeitige Kompilierung, die ursprünglich auf einigen anderen Computern stattgefunden hat, aus dem Cache herunterlädt und sie sehr schnell startet, ohne sich aufzuwärmen. Das ist cool, aber Java hat einen Preis. Ich kann nicht nur Leute, die ein iOS-Projekt erstellen, bitten, Java auf ihrem System zu haben.
Mainframer wurde ursprünglich im Bash-Dialekt geschrieben. Aber ich wollte es in einer Systemsprache umschreiben, um normales Multithreading, die Fähigkeit, normale Komponententests zu schreiben, und nicht nur Integrationstests über das Dienstprogramm hinaus zu erhalten ...
Oleg : Und man könnte zum Beispiel Python nehmen.
Artyom : Ja. Aber dann würde sich die Frage stellen, dass dies zum einen eine dynamische Typisierung ist und zum anderen ...
Oleg : Also auch in Bash dynamisches Tippen.
Artyom : Also wollte ich es umschreiben. Außerdem gibt es ein Problem mit der Tatsache, dass Python jetzt zwei ist: Unter MacOS ist standardmäßig die zweite und unter Linux fast alle die dritte. Es gibt alle möglichen Witze. Wenn ich eine Art Sucht brauche, um mich zu binden, werde ich die Leute bitten, Pip zu betreiben? Oder muss ich sie schlagen?
Ich wollte eine Systemsprache verwenden, die keine Abhängigkeiten erfordert, damit ich eine Binärdatei erstellen kann, die bedingt weniger als ein Megabyte wiegt und mit minimalem Overhead arbeitet.
Oleg : Du könntest Golang nehmen, zumindest gibt es einen Müllsammler.
Artyom : Genau deshalb wollte ich Rust ausprobieren. Und es hat funktioniert. Außerdem ist Golang ein bisschen traurig über Generika.
Eugene : Seit sie angefangen haben, über Sprachen zu diskutieren ... Im Kontext der Android-Entwicklung ist die Frage "Kotlin oder Java" bereits müde, aber stellen Sie sie trotzdem, um mit der nächsten Frage fortzufahren.
Artyom : Nun, Kotlin natürlich.
Eugene : Nun die Frage, die wirklich interessiert. Kürzlich wurden in Kotlin die Koroutinen stabil und die Stimmen „Hurra, lass uns von RxJava weggehen“ sind zu hören. Wenn ich daher eine Person vor mir sehe, die RxJava sehr nahe steht, möchte ich sofort nach seiner Meinung zu Coroutinen fragen.
Artyom : Ich war den Coroutinen gegenüber sehr negativ eingestellt. Im Prinzip ist es immer noch größtenteils negativ, aber dies hat das sehr lange Gespräch mit
Roma Elizarov , die daran arbeitet, teilweise verändert.
Als Benutzer von Programmen möchte ich, dass sie so blockierungsfrei wie möglich sind und die Ressourcen so korrekt wie möglich nutzen. Damit meine ich sowohl Parallelität als auch die Tatsache, dass sie die richtigen Betriebssystem-APIs verwenden, um den Zugriff auf das Netzwerk oder die Dateien nicht zu blockieren - es gibt viele Probleme damit in Betriebssystemen, aber es gibt dennoch solche APIs. Was genau löst das? Als Benutzer ist es mir egal - wenn nur die Entwickler dieses Problem auf eine Weise lösen würden, die es ihnen bequem macht. Ich habe keine großen Probleme damit. Und das ist die Vision von Roma Elizarov. Nach diesem Gespräch ließ ich es irgendwie los.
Zuvor schien
es mir , wie mein Freund
Arthur Dremov , nach mehreren Jahren der Verwendung von Java in der Produktion ein Rückschritt
zu sein : Der Code wird wieder zwingend, unrein, er verliert das Verständnis für die Pipeline, er wird wieder zu einem Chaos, das der Compiler für Sie zu einem asynchronen Chaos macht.
Ich verwende keine Coroutinen, aber alle Beispiele, die ich jetzt beobachte, haben zu einem strukturierten Ansatz übergegangen, wenn Sie nicht einmal sehen, welcher Code daraus Coroutine ist. Um ehrlich zu sein, habe ich große Angst, es mir anzusehen. Da ich die Pull-Anforderung auf GitHub öffne, werden einige Methoden aufgerufen, um das Bild und das Profil hochzuladen. Eine davon geht an das Netzwerk und die andere an die lokale SQLite. Hier kann die lokale SQLite leicht blockiert werden. Ich sehe dies nicht im Code, da die Coroutinen so erstellt sind, dass Sie sie nicht sehen. Vielleicht ist es gut, aber für mich ist dies immer noch ein Minus des Designs, denn bei Rx-Ansätzen ist es sehr offensichtlich: Verstehst du, ob dies Teil der synchronen Pipeline ist oder nicht?
Vielleicht ist dies meine einzige Beschwerde bei Coroutinen: Ich möchte sehen, wann meine Asynchronität auftritt und wann nicht. Idealerweise möchte ich, dass die Leute mehr Funktionscode schreiben, wenn es kleine wiederverwendbare oder zumindest testbare Teile gibt, die sich mit anderen kombinieren lassen. Und wir kommen auf die Tatsache zurück, dass alles in die Logik integriert wird und der Compiler es dann einfach umdreht.
Oleg : Lass mich dir ein wenig Widerstand leisten. Legacy-Code ist viel mehr als neu. Und wenn wir einige Dinge wie die Arbeit mit einem Netzwerk, die Arbeit mit Dateien usw. übernehmen, wird niemand all dies schnell neu schreiben, beispielsweise mit RxJava. Und wenn wir Autokoroutinen haben, können wir zum Beispiel alle Systemaufrufe verfolgen, sie automatisch einwickeln und zum Parken an die Schleuse senden.
Artyom : Richtig, in jedem Fall müssen Sie Funktionen aus dem Kontext von Corutin aufrufen. Aber das ist ein interessanter Gedanke, ja.
Oleg : Vielleicht sollten sie irgendwie kombiniert werden? Die API der obersten Ebene befindet sich in RxJava und die API der unteren Ebene in Coroutinen.
Artyom : Ja, es gibt jetzt solche Verschiebungen. Aber dann stellt sich die Frage, denn im Moment kann RxJava alles, was die Coroutinen tun, und Coroutinen können nicht alles, was RxJava tut.
Das heißt, die erste Technologie kann die zweite absorbieren und die zweite die erste - nicht. Und daher wird es höchstwahrscheinlich Fortschritte in Richtung der Tatsache geben, dass es auf Kotlin auf Coroutinen eine Art plattformübergreifenden Rx geben wird. Dies ist jedoch eine andere Denkweise. So können Sie forEach nehmen und fahren, um eine Art Karte zu erstellen, aber Sie können Streams nehmen und darauf schreiben. Und es scheint, dass sogar die Java-Community des Unternehmens das Streaming bereits genehmigt und gestartet hat, da es aussagekräftiger ist. Und mit Coroutinen gehen wir jetzt in die entgegengesetzte Richtung., Kotlin — . , Go , , API, , : . , , , , legacy, , . , Java Kotlin — legacy, , . , . - , .
, , . , , , — . .
: , . , , : Android-? , .
: … . , Android- . , . , : , . RxJava , : - . , , .
, iOS. , Lyft iOS- dependency injection RxSwift. 2019-. iOS-, , , clean, . , Android — .
, , — Google. « opinionated, , : , , ». — , , .
, «RxJava — , ...» : «, LiveData». , — RxJava, , . , , Google , .
: «, Google MVVM». , MVVM , , , MVVM . , Google.
, , scope . .
: , Room . - Architecture Components — , . Google , ? .
: , . , . !
: .
Der nächste Mobius findet vom 22. bis 23. Mai in St. Petersburg statt . Jetzt wurde sein Programm noch nicht angekündigt, aber dies ist der profitabelste Moment für den Kauf eines Tickets: Am 1. Februar werden die Ticketpreise steigen. Und da das Programm noch nicht abgeschlossen ist, ist der Moment auch geeignet, sich selbst darauf einzulassen: Wir sind in vollem Gange , Bewerbungen für Berichte anzunehmen . Alle Informationen zur Konferenz und zu den Tickets finden Sie auf der Website .