Wir vom „Python Junior Podcast“ - einem Podcast für diejenigen, die Python besser verstehen wollen - versuchen, in jeder Hinsicht zum Wunsch nach Lernen beizutragen. Wir laden Experten ein, stellen knifflige Fragen, erhalten Tipps, was und wie man für einen Python-Anfänger oder für einen Nicht-Anfänger oder nicht Python lernt - alles kann passieren.
Heute machen wir Sie auf eine Textversion unseres Gesprächs mit Arseny Gabdullin, dem Entwickler des Tinkoff-Magazins, zum Thema seines zukünftigen Berichts über
Moscow Python Conf ++ aufmerksam , jedoch ohne Spoiler.
Obwohl ich immer sage, dass Menschen zu Konferenzen gehen, nicht um zu studieren, haben sie viele Vorteile. Wie in unserem Podcast.
Das Gespräch beinhaltete:
- Grigory Petrov, Evangelist von MoscowPython, Leiter des Programmkomitees von Moscow Python Conf ++;
- Arseny Gabdullin, Entwickler des Tinkoff-Magazins, Sprecher bei MoscowPython Conf ++;
- Zlata Obukhovskaya, Teamleiterin Nvidia, Evangelistin MoscowPython, Mitglied des Programmkomitees von Moscow Python Conf ++;
- Valentin Dombrovsky, Mitorganisator und Mitbegründer von MoscowPython,
Valentin Dombrovsky: Arseny, Ihr
Bericht ohne Spoiler - was werden Sie uns auf der Konferenz sagen?
Wie Arseny Entwickler bei TJ wurde
Arseny Gabdullin: Tatsächlich werden wir mit Partner Vadim Goncharov, dem Leiter unserer Entwicklung, sprechen. Es ist von der Geschäftsseite und ich von der Entwicklungsseite. Wir werden darüber sprechen, wie Medienprojekte mit Python durchgeführt werden, welche Vorteile dies für Unternehmen und Medien bietet, wie wir von WordPress zu Django gewechselt sind, was wir jetzt tun, welche Probleme und Erfolge wir hatten und was unsere Pläne für die Zukunft sind.
Valentin Dombrovsky: Gehen wir einen Schritt zurück. Sagen Sie mir, was Sie tun und wie Sie zu einer so wunderbaren Organisation wie Tinkoff gekommen sind? Was hat dich dorthin gebracht? Ihr beruflicher Weg?
Arseny Gabdullin: Ich habe als Soziologe in St. Petersburg gelebt und studiert. Ich hatte eine seltsame Spezialität "Informatik-Soziologe" - scheinbar ein Forscher, aber irgendwie verbunden mit der Entwicklung und mit Informationssystemen für die Sozialforschung. Für eine Weile habe ich Datenbanken und Informationssysteme erstellt, um Fallstudien zu unterstützen. In der Soziologie wird Python häufig verwendet. Gleichzeitig habe ich alle Arten von Websites auf WordPress erstellt - es ist passiert.
WordPress-bezogenes Kollektiv kommt heraus
Grigory Petrov: Es gibt nichts, wofür man sich schämen müsste. Alles passiert im Leben.
Zlata Obukhovskaya: Ja, alles ist passiert.
Valentin Dombrovsky: Nun, jetzt werden sie wieder sagen, dass wir PHP-Spezialisten vergiften.
Zlata Obukhovskaya: Grisha, hast du WordPress-Sites erstellt?
Grigory Petrov: Natürlich!
Zlata Obukhovskaya: Und ich habe Websites auf WordPress erstellt.
Valentin Dombrowski: Und ich habe WordPress-Sites gemacht. Ich habe nicht einmal in Python entwickelt, aber ich habe Websites in WordPress erstellt.
Arseny Gabdullin: Ja, ich war jung, ich brauchte Geld. Irgendwann wurde ich dann zu dem Outsourcing-Team gerufen, das TJ gemacht hat. Dann hatten wir keine Entwickler im Staat, alles war fern. Ich begann mit einigen kleinen Aufgaben, dann wurden sie immer mehr. Am Ende sagten sie mir dann: Willst du dich dem Team anschließen, dem Staat, Moskau? Ich dachte und tauschte Petersburg gegen das Tinkoff Magazine.
Valentin Dombrowski: Und dann war es WordPress?
Arseny Gabdullin: Ja.
Valentin Dombrovsky: Das heißt, Ihre Migration zu Python erfolgte direkt während des Arbeitsprozesses?
Arseny Gabdullin: Ich habe vorher in Python geschrieben, aber im Grunde waren es soziologische Systeme für die Wissenschaft, und die Entwicklung war auf WordPress.
Im Jahr 2016 war T - F nur ein WordPress-Thema. Wir hatten nur wenige Artikel und es war eine perfekt passende Lösung. Bis zu einem gewissen Punkt reicht WordPress für die Augen. Dann, bis Ende 2016, schlug ich vor, nach Django zu ziehen, da sich eine Reihe von Problemen angesammelt hatten, die angegangen werden mussten.
Experimentieren Sie mit Lautsprechern im nächstgelegenen Moscow Python Conf ++
Grigory Petrov: Übrigens ist dies natürlich nicht üblich. Sie müssen zuerst eine Konferenz abhalten und dann zwei Monate später, um Feedback von den Rednern zu erhalten. Noah kann es nicht ändern. Auf dieser Konferenz führen wir zum ersten Mal ein Experiment durch -
wir bereiten die Redner von Grund auf vor . Wir haben Arseny nicht nur zusammen mit Vadim eingeladen. Erstens nehmen sie zum ersten Mal an diesem Experiment teil. Und dies wird das erste Mal während der Existenz meines Systems sein, wenn wir es für die Geschichte von zwei Sprechern gleichzeitig anpassen.
Wissen Sie, wie die Geschichten zweier Sprecher normalerweise aussehen? Es ist sehr traurig: Eine Person erzählt, erzählt, erzählt, die zweite mit einem traurigen Gesichtsausdruck steht auf der ersten hinter seinem Rücken. Dann wechseln sie kaum die Plätze.
Bei uns wird alles falsch sein. Arseny und Vadim werden die Geschichte nahtlos von einem zum anderen übertragen. Jetzt ist alles fertig, wir drei haben die Aufführung bereits durchgeführt. Es hat Spaß gemacht.
Arseny, teile deine ersten Eindrücke von unserem Workshop. Ich denke, sie sind jetzt besonders wertvoll, weil Sie und Vadim noch nicht aufgetreten sind. Sie befinden sich mitten auf der Reise, aber der Bericht ist fertig. Wie gefällt dir der Workshop? Wie verrückt, kompliziert, ungewöhnlich war das - wie passt das zu Ihrer bisherigen Erfahrung?
Arseny Gabdullin: Wir haben es wirklich genossen, uns mit Vadim vorzubereiten. Jedes Mal, wenn wir den Laptop schlossen, dachten wir: "Wie cool!" Ein sehr cooler Ansatz, der in kleinen Portionen, aber regelmäßig. Jedes Mal, wenn Sie feststellen, dass Sie einige Fortschritte erzielt haben, ist im Großen und Ganzen bereits ein langer Weg zurückgelegt worden.
Ein interessantes System ist ein scheinbar einfaches Prinzip im Zentrum der Rede, aber gleichzeitig verstehen Sie sofort, wie alles miteinander verbunden ist und wie es in Zukunft funktionieren wird. Natürlich habe ich nie zusammen mit jemandem auf der Bühne gespielt. Es ist interessant zu versuchen - ich weiß nicht, was sich herausstellen wird. Hoffe alles läuft reibungslos.
Grigory Petrov: Es wird gut ausgehen, das System fällt nicht aus. Sehr schön das zu hören. Neben Arseny und Vadim sind elf weitere Berichte in Vorbereitung. Die meisten der zwei Monate vor Abschluss der Konferenz. Das bedeutet, dass
ich ein paranoider Rückversicherer bin - einen Monat vor der Konferenz, und die Berichte sind fertig.Valentin Dombrovsky: Wir haben nur ein halbes Jahr zwischen den Konferenzen, die
letzte Moskauer Python Conf ++ war im Oktober.
Grigory Petrov: Heute haben wir eine Art Smalltalk mit einem Sprecher für unser Publikum.
Der Python Junior-Podcast ist für Anfänger-Entwickler gedacht, obwohl ich Ihnen ein Geheimnis verraten werde, dass nicht nur Junioren uns zuhören.
Arseny Gabdullin: Gerüchten zufolge hat Guido Van Rossum manchmal nachgesehen.
Valentin Dombrowski: Untertitel in Englisch enthalten - sehr gut!
Ist Django 2019 als Online-Medien-Framework geeignet?
Grigory Petrov: Sagen Sie mir, Arseny, aus Ihrer Erfahrung - für Anfängerentwickler - wie zufrieden Sie mit Django waren. Im Prinzip war Django ursprünglich als Rahmen für das Verlagswesen, dh für Magazine, positioniert. Aber das ist sehr lange her. Das Web hat sich seitdem stark verändert, und Sie haben kürzlich begonnen, Django für das Tinkoff Magazine zu verwenden. Sag mir, bist du enttäuscht? Was hat Django 2016 und darüber hinaus für Publishing-Systeme gefallen? Was ist Ihre persönliche Meinung?
Valentin Dombrovsky: Zur gleichen Zeit ohne Spoiler! Nun, wenn auch nur ein bisschen.
Arseny Gabdullin: Letztes Jahr haben wir an DevOps gearbeitet. Wir hatten ein großartiges Team von Ingenieuren, die uns direkt zur Superinfrastruktur machen. Sie stehen Python und insbesondere Django im Allgemeinen sehr skeptisch gegenüber. Wir hatten ein ständiges Tischtennis.
Zlata Obukhovskaya: Sie mussten das Magazin einfach nicht selbst machen.
Arseny Gabdullin: Ja übrigens. Sie sind es gewohnt, Unternehmensdienste auszuführen, jetzt erledigen sie alles auf Node.js. Sie sind es einfach gewohnt, alles auf Node.js zu heben, aber ich habe viele davon überzeugt, dass Sie sowohl in Python als auch in Django gut abschneiden können. Ich betone jedoch, dass es viele Ideen zum Blockieren von Anfragen gibt - schließlich ist dies die
Synchronität von Django, die nicht wiederholt werden kann . Dies ist das Highlight.
In Bezug auf die Arbeit mit ORM glaube ich, dass dies für große Projekte ist, bei denen es viele Beziehungen gibt, bei denen sich alles ändert und Sie einen Rahmen benötigen, in dem die Datendomäne angelegt wird. Django ist sehr praktisch. Wir werden nun Django als API verwenden, wofür es vorgesehen ist, d. H. Daten zu verteilen.
Wie lange lebt ein Content-Projekt gut im Django REST Framework?
Zlata Obukhovskaya: Sie verwenden DRF, Sie müssen darüber sprechen.
Arseniy Gabdullin: Ja,
DRF ist de facto ein Standard . Es gibt ein Django-Modell zusätzlich zu DRF - Glück (bis zu einem gewissen Punkt).
Zlata Obukhovskaya: Bis zu welchem Zeitpunkt?
Arseny Gabdullin: Bis zu dem Moment, an dem komplexe verschachtelte Beziehungen beginnen. In unserer Zeitschrift ist das Publikationssystem komplex, aber eher linear. Wir haben einen weiteren Dienst für die Bank bei Django geleistet - Tinkoff Help, der aus der Zeitschrift hervorgegangen ist. Dort ist alles viel komplizierter, weil Designer und Produkte eine sehr komplexe Hierarchie von Produkten und Abschnitten entwickelt haben. Irgendwann stellten wir fest, dass die Implementierung in REST schwierig, die Serialisierung und die Sicherstellung der Leistung schwierig ist. Sie können, aber Sie müssen viel Zeit aufwenden und sich nicht offensichtliche Optimierungsschritte einfallen lassen.
Zlata Obukhovskaya: Das heißt, sobald die dreistufige Verbindung beginnt - okay, keine dreistufige Verbindung, aber etwas noch Tieferes, es ist wahrscheinlich schon schwierig.
Arseny Gabdullin: Genau.
Zlata Obukhovskaya: Es stellt sich heraus, dass das Tinkoff-Projekt Help besser wäre, um auf eine andere Technologie umzuschreiben. Irgendwelche Ideen, was verwendet werden könnte? Aus Ihrer persönlichen Sicht?
Valentin Dombrovsky: Stellen Sie uns ein wenig vor, was ist Tinkoff Help?
Arseniy Gabdullin: Dies ist eine reine Bankdienstleistung - Informationen zu den Produkten der Bank. Aber er lebte lange Zeit in einer Zeitschrift. Es war ein bisschen absurd, weil er wenig mit der Zeitschrift zu tun hat. Aber wir hatten bereits eine funktionierende Veröffentlichungsplattform, etablierten Produktionsprozesse und war zu diesem Zeitpunkt nicht in der Lage, einen separaten Service zu erbringen.
Valentin Dombrovsky: Das heißt, de facto haben sie in Tinkoff grob gesagt ein Inhaltsprojekt kombiniert: Das Magazin und die Hilfe wurden auf derselben Plattform erstellt.
Arseny Gabdullin: Es war ein Experiment. Wir haben geholfen, genau wie ein kleiner Abschnitt in einer Zeitschrift, und dann wuchs es und es wurde klar, dass er bereits in einer Zeitschrift lebte. Dann haben wir es zu einem separaten Dienst gebracht.
Valentin Dombrovsky: Und zu einer neuen technischen Plattform?
Wenn nicht Django, was dann?
Zlata Obukhovskaya: Ich habe eine Frage: Wenn nicht Django - was dann? Was sind die Alternativen?
Arseny Gabdullin: Wir alle lieben Node.js, wir waren überzeugt, Node.js zu machen. Wir haben abgelehnt, es besteht kein Wunsch, mit Daten in Node.js zu arbeiten. Ja, natürlich gibt es Leistung, Asynchronität und mehr. Aber lassen Sie uns trotzdem die Daten in den Modellen auslegen.
Zlata Obukhovskaya: Dann stellt sich heraus, dass asynchrones Python?
Arseny Gabdullin: Ja, wenn Sie in Python schreiben möchten, denke ich, dass dies direkt eine Rettung ist.
Valentin Dombrowski: Hier ist dann die Frage - Node.js gegen Python - wer wen schlagen wird. Wenn wir über die Gewohnheiten der Menschen sprechen, ist dies eine Sache, aber immer noch in Gebrauch, wo funktioniert das am besten? Grisha, Node.js oder Asynchronous Python?
Grigory Petrov: Du bist es nur ...
Zlata Obukhovskaya: Sie haben die Büchse der Pandora praktisch geöffnet!
Informationen zum Hintergrund der synchronen und asynchronen Entwicklung in Python
Grigory Petrov: Ich habe das mehrmals gesagt und werde es sagen, denn dies sind die Grundprinzipien, die sehr gut aus dem PythonJunior-Podcast übertragen werden - Hallo, Jones und alle anderen!
Die asynchrone Programmierung im Allgemeinen - Event Loop in Python 3.7 und in Node.js 11 - ist sehr ähnlich.
Aber es gibt historische Schichten. Node.js ging von JavaScript aus, das vom Browser ging. Im Prinzip kann sich der Browser keine Blockierungsvorgänge in JS leisten, da sonst die Seite blockiert und nicht gescrollt wird.
Wir können nicht zulassen, dass JavaScript den vom Browser angezeigten Bildlauf unserer Seite blockiert. Daher war JavaScript ursprünglich auf Rückrufen. Wir konnten dort nicht sofort etwas unternehmen, zum Beispiel einen lokalen Speicher oder eine Datenbank öffnen. Wir konnten die Operation starten, einen Rückruf angeben und nach einer Weile, wenn der Browser die Operation ausführt, wurde der Rückruf aufgerufen. Das war schon immer so.
Als sie Node.js entwickelten, wurde dieses Paradigma, dass alles asynchron ist, aus Rückrufen nahtlos in Node.js umgewandelt und wirkte sehr gut im asynchronen Paradigma, wenn es einen Thread gibt und es zu dieser Zeit viele, viele Dinge auf niedriger Ebene gibt von Zeit zu Zeit Rückrufe auf diesen Thread-Bericht.
Als nach vielen Jahren asynchrones und Warten in JavaScript ankam, genau wie in Python, passierte das Rätsel. Jetzt sieht die Node.js-Anwendung wie eine asynchrone Coroutine aus und wartet im Inneren auf alles, was Sie können.
Python ist schief gelaufen. Python war ursprünglich keine einbettbare Datei, sondern eine Anwendungssprache, in der vollständige, vom Benutzer ausgeführte Systeme erstellt wurden: Nummernbrecher, Server usw. Wenn alle diese Systeme eine Datei öffnen wollten, war dies eine Blockierungsoperation. Python war historisch gesehen aufgrund der GIL praktisch zu züchten und mit Threads zu multiplizieren.
Wenn wir in Python etwas parallel machen wollten, haben wir einen Thread-Pool genommen und mit Threads multipliziert - es gab Glück! Dann kam Event Loop.
Was hat Python zugunsten von Event Loop auf das Thread-Paradigma verzichtet?
Warum haben sie begonnen, das Flow-Paradigma in Richtung EventLoop aufzugeben?
Für Entwickler ist es viel einfacher, alle Blockierungsmaschinen unter der Haube zu verstecken und nur die Ergebnisse asynchroner Vorgänge in einem Thread zu verwalten.
Dies ist sehr praktisch - viel praktischer, als tausend Threads zu starten und gleichzeitig darauf zu warten. Außerdem sind die Streams selbst nicht kostenlos. Das Starten zwischen ihnen und das Wechseln zwischen ihnen für das Betriebssystem ist eine Belastung.
Als Python von den Threads zu Event Loop wechselte, stellte sich heraus, dass alle vorhandenen Bibliotheken blockiert waren. In Node.js, JavaScript, waren alle vorhandenen Bibliotheken anfangs nicht blockierend, während sie in Python anfänglich blockierten. Daher bietet das wunderbare Asyncio aus der Box im Wesentlichen zwei Grundelemente, auf die wir warten können: Netzwerkbetrieb und Timer.
Arbeiten Sie mit Dateien, Datenbanken, Pipes, Nummernbrechern, NumPy und der Größenänderung von Bildern - all dies in alten synchronen Bibliotheken. Und um sie zu verwenden, müssen wir den Thread-Pool selbst erstellen, sie selbst starten, die Zukunft gestalten und sie mit Event Loop wieder in den Stream werfen - im Allgemeinen ist das eine traurige Sache. Neue, frische Bibliotheken wie asyncpg versuchen irgendwie, dies zusammenzufassen.
Asynchrones Python ist noch sehr jung.
Er hatte keine so erfolgreiche Vererbung wie Node.js und ist daher noch nicht gereift. Die Sprache selbst ist jedoch sehr stark. Wenn es also ein Team von Python-Entwicklern gibt, das selbst diese Einschränkung der Jugend der asynchronen Programmierung in Python hat, kann ein erfahrener Python-Entwickler bereits eine produktive Lösung entwickeln, deren Geschwindigkeit Node.js nicht unterlegen ist. Gleichzeitig wird die Lösung aufgrund der Tatsache, dass Python sie viel besser kennt als Node.js, besser und schneller entwickelt, der Code ist sauberer und der Support billiger.
Ist es schwierig, asynchrone Lösungen in Python von Grund auf neu zu schreiben?
Zlata Obukhovskaya: Tatsächlich verbietet niemand das Schreiben eines eigenen asynchronen Treibers für ein neues modisches Repository.
Grigory Petrov: Ja zu dir.
Zlata Obukhovskaya: Und wer nicht?
Grigory Petrov: Alle Entwickler sind niedriger als ältere Entwickler. Asynchrone Lösungen sind sehr schwer zu schreiben. Sie scheitern an unerwarteten Orten. Arseny, sag, es ist schwer, diese Dinge zu tun.
Arseny Gabdullin: Asynchronität? Ungewöhnlich.
Zlata Obukhovskaya: Verwenden Sie irgendwo in Tinkoff Asynchronität? Vielleicht erzählten einige Leute beim Abendessen eine traurige oder umgekehrt lustige Geschichte über die Verwendung von Asynchronität?
Arseny Gabdullin: Die meisten unserer Dienste werden von Node.js bereitgestellt. Dort ist Asynchronität in DNA eingebettet. Wir haben zum Beispiel auch Sprachdienste, von denen viele in Python funktionieren. Um ehrlich zu sein, weiß ich nicht genau, wie sie das alles implementieren, aber ich denke, dass Asynchronität durch Multithreading erreicht wird. In hoch geladenen APIs ist es im Allgemeinen nicht mehr Node.js, sondern zumindest einige Scala. Und sie erledigen sehr hohe Workloads in C ++, aber auch hier plus Multithreading.
Über das perfekte Programmierwerkzeug
Grigory Petrov: Es gibt eine Sache, über die ich gerne spreche. Die schöne Geschichte, dass es ein ideales Werkzeug zur Lösung des Problems gibt, ist leider nur ein Märchen. Im Laufe der Jahre entwickelt der Entwickler unter Verwendung derselben Sprache, des Frameworks, viele Muster. Diese Muster erweitern seine Fähigkeit als Entwickler erheblich, wie sehr er Objekte im Fokus halten kann. Wenn ein Schachspieler im Laufe der Jahre Schach lernen lernt, beginnt er nach vielen Jahren, das Brett als eine Kombination aus vertrauten und vertrauten Figuren zu betrachten.
Wenn ein Python-Entwickler beispielsweise seit 5 bis 10 Jahren in Python programmiert, ist er möglicherweise ein erfahrener Entwickler, T-förmig, kennt Go, Node.js usw. Aufgrund der Tatsache, dass er über so große Erfahrung in der Verwendung von Python verfügt, werden er und sein Python-Team immer schnellere Dienste schreiben, die einfacher zu entwickeln und zu warten sind als auf Node.js und sogar auf Go. Nur weil das seit vielen Jahren bekannte Tool allen Seiten des Code-Schreibens einen enormen Bonus bietet.
Natürlich gibt es entartete Fälle - natürlich. Im Allgemeinen ist dies bei den meisten Aufgaben der Fall. Oder nicht? Streite mit mir.
Zlata Obukhovskaya: Man kann natürlich argumentieren, denn wenn der Entwickler ein langes Bein vom Buchstaben T hat, hindert ihn nichts daran, einen Code zu schreiben, der zu voll mit bestimmten Merkmalen der Sprache ist, die später niemand verstehen wird. Aber er versteht - er ist cool!
Grigory Petrov: Sie sagen, dass erfahrene Entwickler im Gegenteil einfachen Code schreiben.Zlata Obukhovskaya: Das nächste Mal werden wir mehrere erfahrene Entwickler aus verschiedenen Technologien ins Studio bringen, Ihnen eine Waffe geben und sie eine Stunde lang stehen lassen.
Valentin Dombrovsky: Ich schlage vor, dass jeder von ihnen den Code des anderen liest und sieht, was passiert. Es wird eine Schlacht sein!
Zlata Obukhovskaya: Lassen Sie uns dieses philosophische Argument beenden und zu Django zurückkehren. Ich bin sehr interessiert an der Meinung von Arseny, aber was ist, wenn nicht Django? Über asynchrone hochgeladene Dinge haben wir ein wenig verstanden. Und für Aufgaben wie das Erstellen eines Magazins oder das Veröffentlichen von Mediensystemen ist Django wirklich die beste Lösung. Warum nicht Flask?
Valentin Dombrovsky: War dies aus Ihrer Sicht die beste Wahl, oder könnte es noch etwas anderes geben?
Arseny Gabdullin: Ich glaube, dass
Django die beste Wahl für die Medien ist.Valentin Dombrovsky: Welche Möglichkeiten gab es? Vielleicht wurde etwas anderes in Betracht gezogen?
Arseny Gabdullin: Es gab eine Option für den
Bankstapel, dh die Best Practices im Tinkoff-Verwaltungsbereich. Es gab eine Variante des PHP-Frameworks, weil wir PHP hatten - um im selben Paradigma zu bleiben. Es gab keine besonderen Optionen mehr. Aber wir wollten unseren Kreislauf beibehalten, das heißt, nicht an den Bankenentwicklungszyklus gebunden sein, da es immer noch ihre eigenen Merkmale gibt.
Zlata Obukhovskaya: Das heißt, wenn Python und Medien Django sind?
Arseny Gabdullin: Ich denke schon.
ORM löst .
Zlata Obukhovskaya: Aber es gibt auch ORM und nicht mit Django verwandt.
Arseny Gabdullin: Es scheint ja. SQLAlchemy zum Beispiel.
Valentin Dombrowski: PonyORM.
Zlata Obukhovskaya: Aber Peewee wird immer noch in der Produktion verwendet.
Arseny Gabdullin: Trotzdem wurde Django ursprünglich für solche komplex strukturierten Projekte entwickelt, die an Daten gebunden sind, an die Beziehung zwischen Daten, und dies wird direkt in der DNA unseres Modells in der Konstruktion von Logik gelesen.
Spezifität der Entwicklung in der Bank
Grigory Petrov: Den Rest werden wir aus dem Bericht lernen. Bei dieser Gelegenheit möchte ich auch eine Frage stellen, die nicht mit Python zusammenhängt.
In unserer Gesellschaft besteht die Tendenz, so stark regulierte Institutionen wie zum Beispiel die Regierung, die Medizin oder die Bank zu romantisieren: „Bank ?! Das Geld ist da! Wahrscheinlich gibt es Maschinengewehre am Eingang, ein vierstufiges Zugangssystem, Saurons Auge ist auf dem Dach installiert “usw. Gibt es für Sie als Entwickler, der zuvor bei einer Bank gearbeitet hat und dann bei einer Bank angefangen hat, eine Besonderheit bei einer Bank?
Übrigens ist es ein Glück, dass Sie nicht am regulierten Finanzkern arbeiten, sondern an verwandten Infrastrukturdiensten. Hat die Arbeit bei der Bank außerhalb der Kernentwicklung irgendwelche lustigen Besonderheiten, oder ist es nur ein gewöhnliches IT-Unternehmen, nur anstatt mit Likes in sozialen Netzwerken arbeiten wir mit Geld?
: , - , IT- .
: vc.ru, , , , . , -, - .., . . .
IT- ?
: . , , . .
Moscow Python Conf ++
: , Moscow Python Conf ++ , , . ? ? ?
: — . , : « , , PostgreSQL 10 ».
— - -, , . , , .
: ? , - , - , ?
: , . , , .
: , Django — !
: Django.
: , , Django — . .
: , .
: , 24 , Python Core Developer, , - . , .
: Moscow Python Conf++.
: Python- 5 . . , , . Komm mit!