Telegram-Bot für eine personalisierte Auswahl an Artikeln von Habr

Bei Fragen wie „Warum?“ es gibt einen älteren Artikel - Natural Geektimes – den Raum sauberer machen.

Es gibt viele Artikel, von denen mir einige aus subjektiven Gründen nicht gefallen und andere im Gegenteil schade, sie zu überspringen. Ich möchte diesen Prozess optimieren und Zeit sparen.

Der obige Artikel schlug einen Ansatz zur Skripterstellung im Browser vor, der mir jedoch aus folgenden Gründen nicht wirklich gefiel (obwohl ich ihn schon einmal verwendet habe):

• Für unterschiedliche Browser auf Ihrem Computer/Telefon müssen Sie es, wenn möglich, erneut konfigurieren.
• Eine strikte Filterung nach Autoren ist nicht immer praktisch.
• Das Problem mit Autoren, deren Artikel man nicht verpassen möchte, auch wenn sie einmal im Jahr erscheinen, ist nicht gelöst.

Die auf der Website integrierte Filterung nach Artikelbewertungen ist nicht immer praktisch, da hochspezialisierte Artikel trotz ihres Wertes eine eher bescheidene Bewertung erhalten können.

Ursprünglich wollte ich einen RSS-Feed (oder sogar mehrere) generieren und dort nur interessante Dinge hinterlassen. Aber am Ende stellte sich heraus, dass das Lesen von RSS nicht sehr bequem erschien: Um einen Artikel zu kommentieren, für ihn zu stimmen oder ihn zu Ihren Favoriten hinzuzufügen, müssen Sie auf jeden Fall den Browser aufrufen. Deshalb habe ich einen Telegram-Bot geschrieben, der mir interessante Artikel in einer persönlichen Nachricht sendet. Telegram selbst macht daraus schöne Vorschauen, die in Kombination mit Informationen über Autor/Bewertung/Ansichten recht informativ aussehen.

Unterhalb des Schnitts finden sich Details wie die Besonderheiten des Werks, der Schreibprozess und technische Lösungen.

Kurz zum Bot

Repository: https://github.com/Kright/habrahabr_reader

Bot im Telegramm: https://t.me/HabraFilterBot

Der Benutzer legt eine zusätzliche Bewertung für Tags und Autoren fest. Anschließend wird ein Filter auf die Artikel angewendet – die Bewertung des Artikels auf Habré, die Benutzerbewertung des Autors und der Durchschnitt der Benutzerbewertungen pro Tag werden addiert. Wenn die Menge größer als ein vom Benutzer festgelegter Schwellenwert ist, passiert der Artikel den Filter.

Ein Nebenziel beim Schreiben eines Bots war es, Spaß und Erfahrung zu sammeln. Darüber hinaus habe ich mich regelmäßig daran erinnert Ich bin nicht Google, und deshalb werden viele Dinge so einfach und sogar primitiv wie möglich gemacht. Dies verhinderte jedoch nicht, dass der Prozess zum Schreiben des Bots drei Monate dauerte.

Draußen war es Sommer

Der Juli ging zu Ende und ich beschloss, einen Bot zu schreiben. Und das nicht allein, sondern mit einem Freund, der Scala beherrschte und etwas darüber schreiben wollte. Der Anfang sah vielversprechend aus – der Code würde von einem Team erstellt werden, die Aufgabe schien einfach und ich dachte, dass der Bot in ein paar Wochen oder einem Monat fertig sein würde.

Obwohl ich selbst in den letzten Jahren von Zeit zu Zeit Code auf den Felsen geschrieben habe, sieht oder schaut normalerweise niemand diesen Code: Lieblingsprojekte, Testen einiger Ideen, Vorverarbeiten von Daten, Beherrschen einiger Konzepte von FP. Mich hat wirklich interessiert, wie das Schreiben von Code im Team aussieht, denn Code on Rock kann auf sehr unterschiedliche Weise geschrieben werden.

Was hätte passieren können so? Lassen Sie uns jedoch nichts überstürzen.
Alles, was passiert, kann mithilfe des Commit-Verlaufs nachverfolgt werden.

Ein Bekannter hat am 27. Juli ein Repository erstellt, aber nichts anderes getan, also habe ich angefangen, Code zu schreiben.

30 Juli

Kurz gesagt: Ich habe eine Analyse des RSS-Feeds von Habr geschrieben.

• com.github.pureconfig zum direkten Einlesen typsicherer Konfigurationen in Fallklassen (was sich als sehr praktisch herausstellte)
• scala-xml zum Lesen von XML: Da ich ursprünglich meine eigene Implementierung für den RSS-Feed schreiben wollte und der RSS-Feed im XML-Format vorliegt, habe ich diese Bibliothek zum Parsen verwendet. Tatsächlich erschien auch RSS-Parsing.
• scalatest für Tests. Selbst bei kleinen Projekten spart das Schreiben von Tests Zeit – zum Beispiel ist es beim Debuggen der XML-Analyse viel einfacher, sie in eine Datei herunterzuladen, Tests zu schreiben und Fehler zu korrigieren. Als später ein Fehler beim Parsen eines seltsamen HTML-Codes mit ungültigen UTF-8-Zeichen auftrat, erwies es sich als bequemer, ihn in eine Datei zu schreiben und einen Test hinzuzufügen.
• Schauspieler aus Akka. Objektiv gesehen wurden sie überhaupt nicht benötigt, aber das Projekt war zum Spaß geschrieben, ich wollte sie ausprobieren. Daher bin ich bereit zu sagen, dass es mir gefallen hat. Die Idee von OOP kann von der anderen Seite betrachtet werden – es gibt Akteure, die Nachrichten austauschen. Interessanter ist, dass Sie Code so schreiben können (und sollten), dass die Nachricht möglicherweise nicht ankommt oder nicht verarbeitet wird (im Allgemeinen sollten Nachrichten nicht verloren gehen, wenn das Konto auf einem einzelnen Computer ausgeführt wird). Zuerst habe ich mir den Kopf darüber zerbrochen, dass der Code mit den sich gegenseitig abonnierenden Akteuren Müll enthielt, aber am Ende gelang es mir, eine eher einfache und elegante Architektur zu entwickeln. Der Code in jedem Akteur kann als Single-Threaded betrachtet werden; wenn ein Akteur abstürzt, wird er von Acca neu gestartet – das Ergebnis ist ein ziemlich fehlertolerantes System.

9 August

Ich habe dem Projekt hinzugefügt scala-scrapper zum Parsen von HTML-Seiten aus Habr (um Informationen wie Artikelbewertung, Anzahl der Lesezeichen usw. abzurufen).

Und Katzen. Die im Felsen.

Ich habe dann ein Buch über verteilte Datenbanken gelesen. Mir gefiel die Idee von CRDT (Konfliktfreier replizierter Datentyp). https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type, habr), also habe ich eine Typklasse einer kommutativen Halbgruppe gepostet, um Informationen zum Artikel über Habré zu erhalten.

Tatsächlich ist die Idee sehr einfach: Wir haben Zähler, die sich monoton ändern. Die Zahl der Beförderungen nimmt sukzessive zu, ebenso wie die Zahl der Pluspunkte (aber auch die Zahl der Minuspunkte). Wenn ich zwei Versionen von Informationen zu einem Artikel habe, kann ich sie „zu einer zusammenführen“ – der größere Zählerstand wird als relevanter angesehen.

Eine Halbgruppe bedeutet, dass zwei Objekte mit Informationen zu einem Artikel zu einem zusammengeführt werden können. Kommutativ bedeutet, dass man sowohl A + B als auch B + A zusammenführen kann, das Ergebnis nicht von der Reihenfolge abhängt und am Ende die neueste Version übrig bleibt. Hier gibt es übrigens auch Assoziativität.

Beispielsweise lieferte RSS nach dem Parsen wie geplant leicht abgeschwächte Informationen zum Artikel – ohne Metriken wie die Anzahl der Aufrufe. Ein spezieller Akteur nahm dann Informationen über die Artikel auf und rannte zu den HTML-Seiten, um sie zu aktualisieren und mit der alten Version zusammenzuführen.

Im Allgemeinen war dies wie bei Akka nicht erforderlich. Sie konnten einfach das Aktualisierungsdatum für den Artikel speichern und einen neueren Artikel ohne Zusammenführungen verwenden, aber der Weg des Abenteuers führte mich.

12 August

Ich begann mich freier zu fühlen und machte aus Spaß jedem Chat einen eigenen Akteur. Theoretisch wiegt ein Akteur selbst etwa 300 Bytes und es können Millionen davon erstellt werden, das ist also ein völlig normaler Ansatz. Mir scheint, dass die Lösung recht interessant war:

Ein Akteur fungierte als Brücke zwischen dem Telegrammserver und dem Nachrichtensystem in Akka. Er empfing einfach Nachrichten und schickte sie an den gewünschten Chat-Akteur. Der Chat-Akteur könnte als Antwort etwas zurücksenden – und es würde an das Telegramm zurückgesendet. Was sehr praktisch war, war, dass dieser Akteur so einfach wie möglich war und nur die Logik zum Antworten auf Nachrichten enthielt. Übrigens kamen in jedem Chat Informationen über neue Artikel, aber auch hier sehe ich keine Probleme.

Im Allgemeinen funktionierte der Bot bereits, reagierte auf Nachrichten und speicherte eine Liste der an den Benutzer gesendeten Artikel, und ich dachte bereits, dass der Bot fast fertig war. Ich habe nach und nach kleine Funktionen hinzugefügt, wie die Normalisierung von Autorennamen und Tags (Ersetzen von „sd f“ durch „s_d_f“).

Es blieb nur noch eines übrig klein aber — Der Staat wurde nirgendwo gerettet.

Alles ging schief

Ihnen ist vielleicht aufgefallen, dass ich den Bot größtenteils alleine geschrieben habe. Also beteiligte sich der zweite Teilnehmer an der Entwicklung und es traten folgende Änderungen im Code auf:

• MongoDB schien den Status zu speichern. Gleichzeitig waren die Protokolle im Projekt kaputt, weil Monga aus irgendeinem Grund anfing, sie zu spammen, und einige Leute sie einfach global deaktivierten.
• Der Bridge-Akteur in Telegram war bis zur Unkenntlichkeit verwandelt und begann selbst, Nachrichten zu analysieren.
• Schauspieler für Chats wurden gnadenlos herausgeschnitten und stattdessen durch einen Schauspieler ersetzt, der alle Informationen zu allen Chats auf einmal verheimlichte. Bei jedem Niesen geriet dieser Schauspieler in Schwierigkeiten. Nun ja, wie beim Aktualisieren von Informationen zu einem Artikel ist es schwierig, diese an alle Chat-Akteure zu senden (wir sind wie Google, Millionen von Benutzern warten auf jeweils eine Million Artikel im Chat), aber jedes Mal, wenn der Chat aktualisiert wird, Es ist normal, nach Monga zu gehen. Wie ich viel später feststellte, wurde auch die Arbeitslogik der Chats komplett herausgeschnitten und an ihrer Stelle tauchte etwas auf, das nicht funktionierte.
• Von den Typklassen ist keine Spur mehr vorhanden.
• Es ist eine ungesunde Logik bei den Abonnements der Schauspieler untereinander aufgetaucht, die zu einer Race Condition geführt hat.
• Datenstrukturen mit Feldern vom Typ Option[Int] wird zu Int mit magischen Standardwerten wie -1. Später wurde mir klar, dass MongoDB JSON speichert und es nichts Falsches daran ist, es dort zu speichern Option Nun ja, oder zumindest -1 als None analysieren, aber damals wusste ich das noch nicht und glaubte mir, dass „es so sein sollte.“ Ich habe diesen Code nicht geschrieben und habe mir vorerst auch nicht die Mühe gemacht, ihn zu ändern.
• Ich habe herausgefunden, dass sich meine öffentliche IP-Adresse tendenziell ändert, und musste sie jedes Mal zur Whitelist von Mongo hinzufügen. Ich habe den Bot lokal gestartet, Monga befand sich irgendwo auf den Servern von Monga als Unternehmen.
• Plötzlich verschwand die Normalisierung von Tags und Nachrichtenformatierungen für Telegramme. (Hmm, warum sollte das so sein?)
• Mir gefiel, dass der Status des Bots in einer externen Datenbank gespeichert wird und er nach einem Neustart weiter funktioniert, als wäre nichts passiert. Dies war jedoch der einzige Pluspunkt.

Die zweite Person hatte es nicht besonders eilig und all diese Veränderungen erschienen bereits Anfang September in einem großen Haufen. Ich war mir des Ausmaßes der daraus resultierenden Zerstörung nicht sofort bewusst und begann, die Funktionsweise der Datenbank zu verstehen, weil... Ich habe mich noch nie mit ihnen beschäftigt. Erst später wurde mir klar, wie viel Arbeitscode gestrichen und wie viele Fehler stattdessen hinzugefügt wurden.

September

Zuerst dachte ich, es wäre nützlich, Monga zu beherrschen und es gut zu machen. Dann begann ich langsam zu verstehen, dass die Organisation der Kommunikation mit der Datenbank auch eine Kunst ist, bei der man viele Rennen fahren und einfach Fehler machen kann. Wenn der Benutzer beispielsweise zwei Nachrichten erhält, z /subscribe - und als Antwort auf jede einzelne erstellen wir einen Eintrag in der Tabelle, da der Benutzer zum Zeitpunkt der Verarbeitung dieser Nachrichten nicht abonniert war. Ich habe den Verdacht, dass die Kommunikation mit Monga in ihrer jetzigen Form nicht optimal geschrieben ist. Beispielsweise wurden die Einstellungen des Benutzers zum Zeitpunkt seiner Anmeldung erstellt. Wenn er versuchte, sie vor der Tatsache des Abonnements zu ändern, reagierte der Bot nicht, da der Code im Akteur in die Datenbank für die Einstellungen ging, ihn nicht fand und abstürzte. Als ich gefragt wurde, warum ich die Einstellungen nicht nach Bedarf erstellen sollte, erfuhr ich, dass es nicht nötig ist, sie zu ändern, wenn der Benutzer kein Abonnement hat ... Das Nachrichtenfiltersystem wurde irgendwie nicht offensichtlich erstellt, und selbst nach einem genauen Blick auf den Code konnte ich es tun Ich verstehe nicht, ob es ursprünglich so beabsichtigt war oder ob dort ein Fehler vorliegt.

Es gab keine Liste der im Chat eingereichten Artikel; stattdessen wurde mir vorgeschlagen, sie selbst zu schreiben. Das hat mich überrascht – im Allgemeinen hatte ich nichts dagegen, alle möglichen Dinge in das Projekt einzubeziehen, aber es wäre logisch für denjenigen, der diese Dinge eingebracht und vermasselt hat. Aber nein, der zweite Teilnehmer schien alles aufzugeben, sagte aber, dass die Liste im Chat angeblich eine schlechte Lösung sei und es notwendig sei, ein Schild mit Ereignissen wie „Ein Artikel y wurde an Benutzer x gesendet“ zu erstellen. Wenn der Benutzer dann das Senden neuer Artikel anforderte, musste eine Anfrage an die Datenbank gesendet werden, die aus den Ereignissen Ereignisse im Zusammenhang mit dem Benutzer auswählte, außerdem eine Liste neuer Artikel abrufte, sie filterte und an den Benutzer sendete und werfen Sie Ereignisse dazu zurück in die Datenbank.

Der zweite Teilnehmer ließ sich irgendwo hin zu Abstraktionen hinreißen, bei denen der Bot nicht nur Artikel von Habr empfängt und nicht nur per Telegramm verschickt wird.

Irgendwie habe ich Veranstaltungen in Form eines separaten Schildes für die zweite Septemberhälfte umgesetzt. Es ist nicht optimal, aber zumindest hat der Bot angefangen zu arbeiten und mir wieder Artikel zu schicken, und ich habe langsam herausgefunden, was im Code passiert.

Jetzt können Sie zum Anfang zurückkehren und sich daran erinnern, dass das Repository ursprünglich nicht von mir erstellt wurde. Was hätte so passieren können? Meine Pull-Anfrage wurde abgelehnt. Es stellte sich heraus, dass ich Redneck-Code hatte, dass ich nicht wusste, wie man im Team arbeitet, und dass ich Fehler in der aktuellen Implementierungskurve beheben und ihn nicht in einen brauchbaren Zustand verfeinern musste.

Ich war verärgert und schaute mir den Commit-Verlauf und die Menge des geschriebenen Codes an. Ich habe mir Momente angeschaut, die ursprünglich gut geschrieben waren und dann zurückgebrochen wurden ...

Scheiß drauf

Ich erinnerte mich an den Artikel Du bist nicht Google.

Ich dachte, dass niemand wirklich eine Idee ohne Umsetzung braucht. Ich dachte, ich möchte einen funktionierenden Bot haben, der in einer einzigen Kopie auf einem einzigen Computer als einfaches Java-Programm funktioniert. Ich weiß, dass mein Bot monatelang ohne Neustarts funktionieren wird, da ich in der Vergangenheit bereits solche Bots geschrieben habe. Wenn es plötzlich herunterfällt und dem Benutzer keinen weiteren Artikel sendet, wird der Himmel nicht zu Boden fallen und es wird nichts Katastrophales passieren.

Warum brauche ich Docker, MongoDB und andere Frachtkulte „seriöser“ Software, wenn der Code einfach nicht oder schief funktioniert?

Ich habe das Projekt gespalten und alles so gemacht, wie ich wollte.

Etwa zur gleichen Zeit wechselte ich den Job und es fehlte mir an Freizeit. Morgens bin ich direkt im Zug aufgewacht, abends bin ich spät zurückgekommen und hatte keine Lust mehr, etwas zu unternehmen. Eine Zeit lang tat ich nichts, dann überkam mich der Wunsch, den Bot fertigzustellen, und ich begann, den Code langsam neu zu schreiben, während ich morgens zur Arbeit fuhr. Ich will nicht sagen, dass es produktiv war: Mit einem Laptop auf dem Schoß in einem zitternden Zug zu sitzen und von seinem Telefon aus auf den Stapelüberlauf zu schauen, ist nicht sehr praktisch. Die Zeit, die für das Schreiben von Code aufgewendet wurde, verging jedoch völlig unbemerkt und das Projekt begann sich langsam in einen funktionsfähigen Zustand zu bewegen.

Irgendwo in meinem Hinterkopf gab es einen Wurm des Zweifels, der mongoDB verwenden wollte, aber ich dachte, dass es neben den Vorteilen einer „zuverlässigen“ Zustandsspeicherung auch spürbare Nachteile gibt:

• Die Datenbank wird zu einer weiteren Fehlerquelle.
• Der Code wird komplexer und es wird länger dauern, ihn zu schreiben.
• Der Code wird langsam und ineffizient; anstatt ein Objekt im Speicher zu ändern, werden die Änderungen an die Datenbank gesendet und bei Bedarf zurückgezogen.
• Es gibt Einschränkungen hinsichtlich der Art der Speicherung von Ereignissen in einer separaten Tabelle, die mit den Besonderheiten der Datenbank verbunden sind.
• Die Testversion von Monga weist einige Einschränkungen auf, und wenn Sie auf diese stoßen, müssen Sie Monga auf etwas starten und konfigurieren.

Ich habe den Monga herausgeschnitten, jetzt wird der Status des Bots einfach im Speicher des Programms gespeichert und von Zeit zu Zeit in einer Datei im JSON-Format gespeichert. Vielleicht schreiben sie in den Kommentaren, dass ich falsch liege, dass hier die Datenbank verwendet werden sollte usw. Aber das ist mein Projekt, die Vorgehensweise mit der Datei ist möglichst einfach und es funktioniert transparent.

Hat magische Werte wie -1 weggeworfen und normale Werte zurückgegeben Option, Speicherung einer Hash-Tabelle mit gesendeten Artikeln zurück zum Objekt mit Chat-Informationen hinzugefügt. Löschung von Informationen zu Artikeln, die älter als fünf Tage sind, hinzugefügt, um nicht alles zu speichern. Ich habe die Protokollierung in einen funktionierenden Zustand gebracht – Protokolle werden in angemessenen Mengen sowohl in die Datei als auch in die Konsole geschrieben. Mehrere Admin-Befehle hinzugefügt, z. B. zum Speichern des Status oder zum Abrufen von Statistiken wie der Anzahl der Benutzer und Artikel.

Eine Reihe kleiner Dinge wurden behoben: Beispielsweise wird für Artikel jetzt die Anzahl der Aufrufe, Likes, Dislikes und Kommentare zum Zeitpunkt des Passierens des Benutzerfilters angezeigt. Generell ist es überraschend, wie viele Kleinigkeiten korrigiert werden mussten. Ich habe eine Liste geführt, dort alle „Unregelmäßigkeiten“ notiert und diese soweit möglich korrigiert.

Ich habe zum Beispiel die Möglichkeit hinzugefügt, alle Einstellungen direkt in einer Nachricht festzulegen:

/subscribe
/rating +20
/author a -30
/author s -20
/author p +9000
/tag scala 20
/tag akka 50

Und noch ein Team /settings Zeigt sie genau in dieser Form an, können Sie den Text daraus übernehmen und alle Einstellungen an einen Freund senden.
Es scheint eine Kleinigkeit zu sein, aber es gibt Dutzende ähnlicher Nuancen.

Artikelfilterung in Form eines einfachen linearen Modells implementiert – der Benutzer kann eine zusätzliche Bewertung für Autoren und Tags sowie einen Schwellenwert festlegen. Wenn die Summe aus der Bewertung des Autors, der durchschnittlichen Bewertung für Tags und der tatsächlichen Bewertung des Artikels größer als der Schwellenwert ist, wird der Artikel dem Benutzer angezeigt. Sie können den Bot entweder mit dem Befehl /new nach Artikeln fragen oder den Bot abonnieren und er sendet Ihnen zu jeder Tageszeit Artikel in einer persönlichen Nachricht.

Im Allgemeinen hatte ich die Idee, für jeden Artikel mehr Funktionen herauszuholen (Hubs, Anzahl der Kommentare, Lesezeichen, Dynamik von Bewertungsänderungen, Textmenge, Bilder und Code im Artikel, Schlüsselwörter) und dem Benutzer ein OK/ anzuzeigen. Es ist nicht in Ordnung, unter jedem Artikel abzustimmen und für jeden Benutzer ein Modell zu trainieren, aber ich war zu faul.

Außerdem wird die Logik der Arbeit nicht so offensichtlich sein. Jetzt kann ich für patientZero manuell eine Bewertung von +9000 festlegen und mit einer Schwellenwertbewertung von +20 erhalte ich garantiert alle seine Artikel (es sei denn, ich stelle natürlich für einige Tags -100500 ein).

Die endgültige Architektur erwies sich als recht einfach:

1. Ein Akteur, der den Status aller Chats und Artikel speichert. Es lädt seinen Status aus einer Datei auf der Festplatte und speichert ihn von Zeit zu Zeit jedes Mal in einer neuen Datei.
2. Ein Akteur, der von Zeit zu Zeit den RSS-Feed besucht, sich über neue Artikel informiert, sich die Links ansieht, analysiert und diese Artikel an den ersten Akteur sendet. Darüber hinaus fordert es manchmal eine Liste von Artikeln vom ersten Akteur an, wählt diejenigen aus, die nicht älter als drei Tage sind, aber schon lange nicht mehr aktualisiert wurden, und aktualisiert sie.
3. Ein Schauspieler, der mit einem Telegramm kommuniziert. Ich habe die Nachrichtenanalyse noch vollständig hierher gebracht. Auf freundliche Weise würde ich es gerne in zwei Teile aufteilen – so dass einer eingehende Nachrichten analysiert und der zweite sich mit Transportproblemen wie dem erneuten Senden nicht gesendeter Nachrichten befasst. Jetzt gibt es kein erneutes Versenden, und eine Nachricht, die aufgrund eines Fehlers nicht angekommen ist, geht einfach verloren (sofern dies nicht in den Protokollen vermerkt ist), aber bisher hat dies keine Probleme verursacht. Möglicherweise treten Probleme auf, wenn viele Leute den Bot abonnieren und ich das Limit für den Nachrichtenversand erreiche.

Was mir gefallen hat, ist, dass Stürze der Akteure 2 und 3 dank Akka im Allgemeinen keinen Einfluss auf die Leistung des Bots haben. Möglicherweise werden einige Artikel nicht rechtzeitig aktualisiert oder einige Nachrichten erreichen das Telegramm nicht, aber der Account startet den Akteur neu und alles funktioniert weiterhin. Ich speichere die Information, dass der Artikel dem Benutzer nur dann angezeigt wird, wenn der Telegram-Akteur antwortet, dass er die Nachricht erfolgreich zugestellt hat. Das Schlimmste, was mir droht, ist, die Nachricht mehrmals zu senden (wenn sie zugestellt wird, aber die Bestätigung irgendwie verloren geht). Wenn der erste Akteur den Zustand nicht in sich selbst speicherte, sondern mit einer Datenbank kommunizierte, könnte er im Prinzip auch unmerklich fallen und ins Leben zurückkehren. Ich könnte auch Akka-Persistenz ausprobieren, um den Zustand von Akteuren wiederherzustellen, aber die aktuelle Implementierung gefällt mir aufgrund ihrer Einfachheit. Es ist nicht so, dass mein Code oft abgestürzt wäre – im Gegenteil, ich habe ziemlich viel Mühe darauf verwendet, es unmöglich zu machen. Aber es passiert Scheiße, und die Möglichkeit, das Programm in einzelne Schauspieler zu zerlegen, erschien mir wirklich praktisch und praktisch.

Ich habe „circle-ci“ hinzugefügt, damit Sie sofort davon erfahren, wenn der Code kaputt geht. Zumindest bedeutet dies, dass die Kompilierung des Codes gestoppt wurde. Ursprünglich wollte ich Travis hinzufügen, aber es zeigte nur meine Projekte ohne Forks. Im Allgemeinen können beide Dinge in offenen Repositories frei verwendet werden.

Ergebnisse

Es ist bereits November. Der Bot ist geschrieben, ich benutze ihn seit zwei Wochen und er hat mir gefallen. Wenn Sie Verbesserungsvorschläge haben, schreiben Sie. Ich sehe keinen Sinn darin, es zu monetarisieren – lassen Sie es einfach funktionieren und senden Sie interessante Artikel.

Bot-Link: https://t.me/HabraFilterBot
Github: https://github.com/Kright/habrahabr_reader

Kleine Schlussfolgerungen:

• Selbst ein kleines Projekt kann viel Zeit in Anspruch nehmen.
• Du bist nicht Google. Es hat keinen Sinn, mit einer Kanone auf Spatzen zu schießen. Eine einfache Lösung kann genauso gut funktionieren.
• Lieblingsprojekte eignen sich sehr gut zum Experimentieren mit neuen Technologien.
• Telegram-Bots sind ganz einfach geschrieben. Ohne „Teamwork“ und Experimente mit Technologie wäre der Bot in ein oder zwei Wochen geschrieben worden.
• Das Akteurmodell ist eine interessante Sache, die gut zu Multithreading und fehlertolerantem Code passt.
• Ich glaube, ich habe einen Eindruck davon bekommen, warum die Open-Source-Community Forks liebt.
• Datenbanken sind gut, weil der Anwendungsstatus nicht mehr von Anwendungsabstürzen/-neustarts abhängt, aber die Arbeit mit einer Datenbank verkompliziert den Code und führt zu Einschränkungen bei der Datenstruktur.

Source: habr.com