Habr의 맞춤형 기사 선택을 위한 텔레그램 봇

“왜?”와 같은 질문의 경우 오래된 기사가 있습니다 - Natural Geektimes - 공간을 더욱 깨끗하게 만들기.

기사가 너무 많아서 주관적인 이유로 마음에 들지 않는 기사도 있고, 반대로 건너 뛰는 것이 안타깝습니다. 이 프로세스를 최적화하고 시간을 절약하고 싶습니다.

위의 기사에서는 브라우저 내 스크립팅 접근 방식을 제안했지만 다음과 같은 이유로 별로 마음에 들지 않았습니다(이전에 사용해 본 적이 있음에도 불구하고).

• 컴퓨터/휴대폰의 다른 브라우저의 경우 가능하면 다시 구성해야 합니다.
• 작성자별로 엄격한 필터링이 항상 편리한 것은 아닙니다.
• XNUMX년에 한 번 발행되는 기사라도 놓치고 싶지 않은 저자의 문제는 해결되지 않았습니다.

기사 등급에 따라 사이트에 내장된 필터링이 항상 편리한 것은 아닙니다. 고도로 전문화된 기사는 그 가치에도 불구하고 다소 적당한 등급을 받을 수 있기 때문입니다.

처음에는 흥미로운 내용만 남기고 RSS 피드(또는 여러 개)를 생성하고 싶었습니다. 그러나 결국 RSS를 읽는 것이 그리 편리해 보이지는 않는 것으로 나타났습니다. 어떤 경우에도 기사에 댓글을 달거나 투표하거나 즐겨찾기에 추가하려면 브라우저를 거쳐야 합니다. 그래서 흥미로운 기사를 개인 메시지로 보내는 텔레그램 봇을 작성했습니다. Telegram 자체는 작성자/평점/뷰에 대한 정보와 결합된 아름다운 미리보기를 만들어 매우 유익해 보입니다.

컷 아래에는 작품의 특징, 집필 과정, 기술적 솔루션 등의 세부 정보가 나와 있습니다.

봇에 대해 간략히 설명하자면

저장소: https://github.com/Kright/habrahabr_reader

텔레그램의 봇: https://t.me/HabraFilterBot

사용자는 태그와 작성자에 대한 추가 등급을 설정합니다. 그 후 기사에 필터가 적용됩니다. Habré에 대한 기사 평점, 작성자의 사용자 평점 및 태그별 사용자 평점 평균이 합산됩니다. 금액이 사용자가 지정한 임계값보다 크면 기사가 필터를 통과합니다.

봇 작성의 부차적인 목표는 재미와 경험을 얻는 것이었습니다. 게다가 나는 정기적으로 나 자신에게 다음과 같은 사실을 상기시켰다. 나는 구글이 아니다따라서 많은 일이 가능한 한 간단하고 원시적으로 수행됩니다. 하지만 이로 인해 봇을 작성하는 과정이 XNUMX개월이 걸리는 것을 막지는 못했습니다.

밖은 여름이었어

XNUMX월이 끝나가고 있었고, 저는 봇을 작성하기로 결정했습니다. 그리고 혼자가 아니라, 스칼라를 마스터하고 그것에 뭔가를 쓰고 싶어하는 친구와 함께. 시작은 유망해 보였습니다. 팀에서 코드를 잘라낼 것이고 작업이 쉬워 보였고 몇 주 또는 한 달 안에 봇이 준비될 것이라고 생각했습니다.

나 자신이 지난 몇 년간 간헐적으로 코드를 작성해 왔음에도 불구하고 일반적으로 아무도 이 코드를 보거나 보지 않습니다. 애완 동물 프로젝트, 일부 아이디어 테스트, 데이터 전처리, FP의 일부 개념 숙달. 저는 팀에서 코드를 작성하는 것이 어떤 모습인지에 정말 관심이 있었습니다. 왜냐하면 바위 위의 코드는 매우 다양한 방식으로 작성될 수 있기 때문입니다.

무엇이 갔을까? 그래서? 그러나 서두르지 말자.
발생하는 모든 일은 커밋 기록을 사용하여 추적할 수 있습니다.

지인이 27월 XNUMX일에 저장소를 만들었지만 별다른 조치를 취하지 않아서 코드 작성을 시작했습니다.

7월 30

간단히 말해서: 나는 Habr의 RSS 피드를 분석하여 작성했습니다.

• com.github.pureconfig 유형이 안전한 구성을 케이스 클래스로 직접 읽기 위한 것입니다(매우 편리한 것으로 나타났습니다).
• scala-xml xml 읽기: 처음에는 RSS 피드에 대한 자체 구현을 작성하고 싶었고 RSS 피드는 xml 형식이므로 구문 분석에 이 라이브러리를 사용했습니다. 실제로 RSS 파싱도 등장했다.
• scalatest 테스트를 위해. 작은 프로젝트의 경우에도 테스트를 작성하면 시간이 절약됩니다. 예를 들어 XML 구문 분석을 디버깅할 때 파일로 다운로드하고 테스트를 작성하고 오류를 수정하는 것이 훨씬 쉽습니다. 나중에 잘못된 utf-8 문자가 포함된 이상한 HTML을 구문 분석할 때 버그가 나타났을 때 이를 파일에 넣고 테스트를 추가하는 것이 더 편리한 것으로 나타났습니다.
• 아카 출신 배우들. 객관적으로 전혀 필요하지 않았지만 프로젝트는 재미로 작성되었으므로 시도해보고 싶었습니다. 결과적으로 마음에 들었다고 말할 준비가되었습니다. OOP의 아이디어는 다른 측면에서 볼 수 있습니다. 메시지를 교환하는 배우가 있습니다. 더 흥미로운 점은 메시지가 도착하지 않거나 처리되지 않을 수 있는 방식으로 코드를 작성할 수 있고 작성해야 한다는 것입니다(일반적으로 계정이 단일 컴퓨터에서 실행될 때 메시지가 손실되어서는 안 됩니다). 처음에는 머리를 긁적이며 배우들이 서로 구독하는 코드에 쓰레기가 있었지만 결국에는 다소 단순하고 우아한 아키텍처를 생각해 냈습니다. 각 액터 내부의 코드는 단일 스레드로 간주될 수 있습니다. 액터가 충돌하면 Acca가 이를 다시 시작합니다. 결과적으로 상당히 내결함성이 있는 시스템이 됩니다.

9 8월

프로젝트에 추가했어요 scala-scrapper Habr에서 html 페이지를 구문 분석하기 위해(기사 등급, 북마크 수 등과 같은 정보를 가져오기 위해)

그리고 고양이. 바위에 있는 것들.

그러다가 분산 데이터베이스에 관한 책을 읽었는데, CRDT(충돌 없는 복제 데이터 유형, https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type, 하브르), 그래서 Habré에 관한 기사에 대한 정보를 위해 교환형 세미그룹의 유형 클래스를 게시했습니다.

사실 아이디어는 매우 간단합니다. 단조롭게 변하는 카운터가 있습니다. 프로모션 수는 플러스 수와 마이너스 수와 마찬가지로 점차 증가하고 있습니다. 기사에 대한 두 가지 버전의 정보가 있는 경우 "하나로 병합"할 수 있습니다. 카운터의 상태가 클수록 관련성이 더 높은 것으로 간주됩니다.

세미그룹은 기사에 대한 정보가 포함된 두 개체를 하나로 병합할 수 있음을 의미합니다. 교환 가능이란 A + B와 B + A를 모두 병합할 수 있고 결과가 순서에 영향을 받지 않으며 결국 최신 버전이 유지된다는 의미입니다. 그건 그렇고, 여기에도 연관성이 있습니다.

예를 들어, 계획대로 구문 분석 후 RSS는 조회수와 같은 지표 없이 기사에 대한 약간 약한 정보를 제공했습니다. 그런 다음 특별한 행위자가 기사에 대한 정보를 가져와 HTML 페이지로 이동하여 이를 업데이트하고 이전 버전과 병합했습니다.

일반적으로 말하면 akka에서는 이것이 필요하지 않았습니다. 단순히 기사의 updateDate를 저장하고 병합하지 않고 새로운 기사를 가져올 수 있었지만 모험의 길이 저를 이끌었습니다.

12 8월

나는 더 자유로워지기 시작했고 단지 재미를 위해 각 채팅을 별도의 배우로 만들었습니다. 이론적으로 액터 자체의 무게는 약 300바이트이고 수백만 개로 생성될 수 있으므로 이는 완전히 정상적인 접근 방식입니다. 제 생각에는 그 해결책이 꽤 흥미로웠던 것 같습니다.

한 행위자는 텔레그램 서버와 Akka의 메시지 시스템 사이를 연결하는 역할을 했습니다. 그는 단순히 메시지를 받고 이를 원하는 채팅 배우에게 보냈습니다. 채팅 행위자는 응답으로 무언가를 다시 보낼 수 있으며 이는 다시 텔레그램으로 전송됩니다. 매우 편리한 점은 이 액터가 최대한 단순하고 메시지에 응답하는 로직만 포함하고 있다는 점입니다. 그건 그렇고, 모든 채팅에 새로운 기사에 대한 정보가 왔지만 이번에도 아무런 문제가 없습니다.

일반적으로 봇은 이미 작동하고 있고, 메시지에 응답하고, 사용자에게 전송된 기사 목록을 저장하고 있었고, 저는 이미 봇이 거의 준비되었다고 생각하고 있었습니다. 저자 이름과 태그 정규화("sd f"를 "s_d_f"로 대체)와 같은 작은 기능을 천천히 추가했습니다.

남은 건 딱 하나뿐이었어 작지만 — 상태는 어디에도 저장되지 않았습니다.

모든 것이 잘못되었다

제가 봇을 주로 혼자 작성했다는 사실을 눈치채셨을 것입니다. 그래서 두 번째 참가자가 개발에 참여했고 코드에 다음과 같은 변경 사항이 나타났습니다.

• MongoDB는 상태를 저장하는 것으로 나타났습니다. 동시에 프로젝트의 로그가 손상되었습니다. 어떤 이유로 Monga가 로그에 스팸을 보내기 시작했고 일부 사람들은 단순히 로그를 전역적으로 꺼버렸기 때문입니다.
• 텔레그램의 브릿지 액터는 알아볼 수 없을 정도로 변형되어 스스로 메시지를 분석하기 시작했습니다.
• 채팅을 위한 배우들을 가차 없이 잘라내고, 대신 모든 채팅에 대한 모든 정보를 한꺼번에 숨기는 배우로 교체했습니다. 재채기할 때마다 이 배우는 곤경에 처했다. 예, 예, 기사에 대한 정보를 업데이트할 때 이를 모든 채팅 참여자에게 보내는 것은 어렵지만(우리는 Google과 마찬가지로 수백만 명의 사용자가 각각 채팅에서 백만 개의 기사를 기다리고 있습니다) 채팅이 업데이트될 때마다 Monga에 들어가는 것은 정상입니다. 한참 후에야 깨달았지만, 채팅의 작동 논리도 완전히 끊어졌고 그 자리에 작동하지 않는 것이 나타났습니다.
• 유형 클래스에는 흔적이 남지 않습니다.
• 서로 구독하는 배우들에게 건강에 해로운 논리가 나타나 경쟁 조건이 발생했습니다.
• 유형의 필드가 있는 데이터 구조 Option[Int] -1과 같은 마법의 기본값을 사용하여 Int로 변환되었습니다. 나중에 나는 mongoDB가 json을 저장하고 거기에 저장하는 데 아무런 문제가 없다는 것을 깨달았습니다. Option 글쎄, 아니면 적어도 -1을 없음으로 구문 분석했지만 그 당시 나는 이것을 몰랐고 "그렇게 되어야 한다"고 내 말을 받아들였습니다. 나는 그 코드를 작성하지 않았고 당분간 코드를 변경하지도 않았습니다.
• 나는 내 공용 IP 주소가 변경되는 경향이 있다는 것을 알았고, 매번 이를 Mongo의 화이트리스트에 추가해야 했습니다. 로컬에서 봇을 시작했는데 Monga는 회사로서 Monga 서버 어딘가에 있었습니다.
• 갑자기 텔레그램의 태그 및 메시지 형식 정규화가 사라졌습니다. (흠, 왜 그럴까요?)
• 봇의 상태가 외부 데이터베이스에 저장되어 있고 다시 시작해도 아무 일도 없었던 것처럼 계속 작동한다는 점이 마음에 들었습니다. 그러나 이것이 유일한 장점이었습니다.

두 번째 사람은 특별히 서두르지 않았으며 이러한 모든 변화는 이미 XNUMX월 초에 하나의 큰 더미로 나타났습니다. 나는 그 결과로 발생한 파괴의 규모를 즉시 인식하지 못했고 데이터베이스의 작업을 이해하기 시작했습니다. 왜냐하면... 나는 전에 그들을 다루어 본 적이 없습니다. 나중에서야 얼마나 많은 작업 코드가 잘리고 그 자리에 얼마나 많은 버그가 추가되었는지 깨달았습니다.

9월

처음에는 몽가를 마스터해서 잘하면 도움이 될 것 같다고 생각했어요. 그러다가 데이터베이스와의 통신을 구성하는 것도 많은 경주를 하고 실수를 할 수 있는 기술이라는 것을 천천히 이해하기 시작했습니다. 예를 들어, 사용자가 다음과 같은 두 개의 메시지를 받은 경우 /subscribe - 각 메시지에 대한 응답으로 테이블에 항목을 생성합니다. 왜냐하면 해당 메시지를 처리할 때 사용자가 구독하고 있지 않기 때문입니다. 현재 형태의 Monga와의 의사 소통이 최선의 방법으로 작성되지 않았다는 의심이 듭니다. 예를 들어, 사용자의 설정은 가입하는 순간 생성되었습니다. 구독이 이루어지기 전에 변경하려고 시도한 경우... 배우의 코드가 설정을 위해 데이터베이스에 들어가서 찾지 못하고 충돌했기 때문에 봇은 아무 응답도 하지 않았습니다. 필요에 따라 설정을 만들지 않는 이유를 물었을 때 사용자가 구독하지 않은 경우 변경할 필요가 없다는 것을 알게되었습니다. 메시지 필터링 시스템은 왠지 모르게 만들어졌고 코드를 자세히 살펴본 후에도 처음에 이런 식으로 의도된 것인지 아니면 오류가 있는지 이해할 수 없습니다.

채팅에 제출된 글 목록은 없었고, 대신 제가 직접 작성해 보자는 제안이 있었습니다. 이것은 저를 놀라게 했습니다. 일반적으로 저는 모든 종류의 것들을 프로젝트에 끌어들이는 것에 반대하지는 않았지만 이러한 것들을 가져와서 망친 사람에게는 논리적일 것입니다. 그런데 아니, 두 번째 참가자는 모든 것을 포기한 것 같았는데, 채팅 안의 목록이 잘못된 해결책인 것 같다며, “y가 사용자 x에게 기사를 보냈습니다.”와 같은 이벤트로 표시를 만들어야 한다고 말했습니다. 그런 다음 사용자가 새 기사를 보내도록 요청한 경우 데이터베이스에 요청을 보내 이벤트에서 사용자와 관련된 이벤트를 선택하고 새 기사 목록을 가져와 필터링한 다음 사용자에게 보내야 했습니다. 이에 대한 이벤트를 다시 데이터베이스에 던집니다.

두 번째 참가자는 봇이 Habr로부터 기사를 수신할 뿐만 아니라 전보로도 전송될 때 추상화를 향해 어딘가로 끌려갔습니다.

어떻게든 XNUMX월 하반기를 맞아 별도의 간판 형태로 이벤트를 구현했습니다. 최적은 아니지만 적어도 봇이 작동하기 시작하고 다시 기사를 보내기 시작했고 코드에서 무슨 일이 일어나고 있는지 천천히 알아냈습니다.

이제 처음으로 돌아가서 저장소가 원래 내가 만든 것이 아니라는 것을 기억할 수 있습니다. 무엇이 이렇게 될 수 있었습니까? 내 풀 요청이 거부되었습니다. 알고 보니 제게는 팀에서 일하는 방법을 몰랐고, 현재 구현 곡선의 버그를 수정해야 했고 사용 가능한 상태로 개선하지 못한 상태의 코드가 있었습니다.

나는 화가 나서 커밋 이력과 작성된 코드의 양을 살펴보았습니다. 원래 잘 쓰여졌던 순간들을 봤는데, 그러다가 깨져서...

빌어먹을

기사가 생각났어요 당신은 구글이 아니다.

구현하지 않고 아이디어가 필요한 사람은 없다고 생각했습니다. 나는 단일 컴퓨터에서 단일 복사본으로 간단한 Java 프로그램으로 작동하는 작업 봇을 갖고 싶다고 생각했습니다. 나는 과거에 이미 그러한 봇을 작성했기 때문에 내 봇이 다시 시작하지 않고도 몇 달 동안 작동할 것이라는 것을 알고 있습니다. 갑자기 떨어져서 사용자에게 다른 기사를 보내지 않으면 하늘이 땅에 떨어지지 않으며 어떤 재앙도 일어나지 않을 것입니다.

코드가 단순히 작동하지 않거나 비뚤어지게 작동하는 경우 Docker, mongoDB 및 기타 "심각한" 소프트웨어의 화물 컬트가 필요한 이유는 무엇입니까?

나는 프로젝트를 포크하고 내가 원하는 대로 모든 것을 했습니다.

그 무렵 나는 직업을 바꾸었고 여가 시간이 너무 부족해졌습니다. 아침에 나는 기차에서 바로 일어났고, 저녁에는 늦게 돌아왔고 더 이상 아무것도 하고 싶지 않았습니다. 한동안 아무것도 하지 않더니 봇을 완성하고 싶은 마음이 나를 압도했고, 아침에 출근하는 동안 천천히 코드를 다시 작성하기 시작했습니다. 그것이 생산적이었다고는 말하지 않겠습니다. 흔들리는 기차에 앉아 노트북을 무릎 위에 놓고 휴대폰으로 스택 오버플로를 보는 것은 그리 편리하지 않습니다. 그러나 코드 작성에 소요된 시간은 전혀 눈에 띄지 않게 지나갔고 프로젝트는 천천히 작업 상태로 이동하기 시작했습니다.

마음 속 어딘가에는 mongoDB를 사용하고 싶다는 의구심이 있었지만, "신뢰할 수 있는" 상태 저장소의 장점 외에도 눈에 띄는 단점이 있다고 생각했습니다.

• 데이터베이스는 또 다른 실패 지점이 됩니다.
• 코드가 점점 복잡해지고 있어 작성하는 데 시간이 더 오래 걸립니다.
• 코드는 느리고 비효율적입니다. 메모리의 개체를 변경하는 대신 변경 사항이 데이터베이스로 전송되고 필요한 경우 다시 가져옵니다.
• 데이터베이스의 특성과 관련된 별도의 테이블에 이벤트를 저장하는 유형에는 제한이 있습니다.
• Monga의 평가판에는 몇 가지 제한 사항이 있으며, 이러한 제한 사항이 발생하는 경우 Monga를 시작하고 구성해야 합니다.

몽가를 잘라냈더니 이제 봇의 상태가 단순히 프로그램의 메모리에 저장되고 때때로 json 형식의 파일에 저장됩니다. 아마도 댓글에서 그들은 내가 틀렸다고, 이것이 데이터베이스를 사용해야 하는 곳이라는 등을 쓸 것입니다. 하지만 이것은 내 프로젝트이므로 파일에 대한 접근 방식은 최대한 간단하고 투명한 방식으로 작동합니다.

-1과 같은 마법 값을 버리고 일반 값을 반환했습니다. Option, 채팅 정보가 포함된 개체로 다시 전송된 기사가 포함된 해시 테이블의 저장 공간을 추가했습니다. 모든 내용을 저장하지 않도록 XNUMX일이 지난 기사에 대한 정보 삭제를 추가했습니다. 로깅을 작업 상태로 전환했습니다. 로그는 파일과 콘솔 모두에 합리적인 양으로 기록됩니다. 상태 저장 또는 사용자 및 기사 수와 같은 통계 얻기와 같은 여러 관리 명령을 추가했습니다.

여러 가지 작은 문제가 수정되었습니다. 예를 들어 기사의 경우 이제 사용자 필터를 통과할 때 조회수, 좋아요, 싫어요 및 댓글 수가 표시됩니다. 일반적으로 수정해야 할 사소한 일이 얼마나 많은지 놀랍습니다. 나는 목록을 작성하고 거기에 있는 모든 "불규칙성"을 기록하고 가능한 한 수정했습니다.

예를 들어, 하나의 메시지에 모든 설정을 직접 지정하는 기능을 추가했습니다.

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

그리고 또 다른 팀 /settings 이 형식으로 정확하게 표시하면 텍스트를 가져와 모든 설정을 친구에게 보낼 수 있습니다.
사소한 것 같지만 비슷한 뉘앙스가 수십 가지 있습니다.

간단한 선형 모델 형태로 기사 필터링을 구현했습니다. 사용자는 작성자 및 태그에 대한 추가 등급과 임계값을 설정할 수 있습니다. 작성자 평점, 태그 평균 평점, 기사 실제 평점의 합이 임계값보다 크면 기사가 사용자에게 표시됩니다. /new 명령을 사용하여 봇에게 기사를 요청하거나 봇을 구독하면 하루 중 언제든지 개인 메시지로 기사를 보낼 수 있습니다.

일반적으로 말하면 각 기사에 대해 더 많은 기능(허브, 댓글 수, 북마크, 등급 변경 역학, 기사의 텍스트 양, 그림 및 코드, 키워드)을 끌어내고 사용자에게 확인/확인을 표시하는 아이디어가 있었습니다. 각 기사에 투표하고 각 사용자에 대한 모델을 교육하는 것은 좋지 않지만 너무 게으르다.

게다가 작업의 논리도 그렇게 명확하지 않을 것이다. 이제 PatientZero에 대해 +9000의 등급을 수동으로 설정할 수 있으며 +20의 임계 등급을 사용하면 그의 모든 기사를 받을 수 있습니다(물론 일부 태그에 대해 -100500을 설정하지 않은 경우).

최종 아키텍처는 매우 간단했습니다.

1. 모든 채팅과 기사의 상태를 저장하는 행위자입니다. 디스크의 파일에서 상태를 로드하고 수시로 새 파일에 다시 저장합니다.
2. RSS 피드를 수시로 방문하는 행위자는 새로운 기사에 대해 배우고, 링크를 보고, 구문 분석하고, 이러한 기사를 첫 번째 행위자에게 보냅니다. 또한, 가끔 첫 번째 배우에게 기사 목록을 요청하고, XNUMX일 이내이지만 오랫동안 업데이트되지 않은 기사를 선별하여 업데이트하기도 한다.
3. 텔레그램으로 소통하는 배우. 나는 여전히 여기에 메시지 구문 분석을 완전히 가져 왔습니다. 우호적인 방식으로 이를 두 개로 나누고 싶습니다. 하나는 들어오는 메시지를 구문 분석하고 두 번째는 보내지 않은 메시지를 다시 보내는 것과 같은 전송 문제를 처리합니다. 이제는 재전송이 없으며 오류로 인해 도착하지 않은 메시지는 단순히 손실되지만(로그에 기록되지 않는 한) 지금까지 이로 인해 문제가 발생하지 않았습니다. 많은 사람들이 봇을 구독하고 메시지 전송 제한에 도달하면 문제가 발생할 수 있습니다.

마음에 들었던 점은 akka 덕분에 배우 2, 3의 추락이 일반적으로 봇 성능에 영향을 미치지 않는다는 점입니다. 일부 기사가 제 시간에 업데이트되지 않거나 일부 메시지가 전보에 도달하지 못할 수도 있지만 계정이 액터를 다시 시작하고 모든 것이 계속 작동합니다. 텔레그램 행위자가 메시지를 성공적으로 전달했다고 응답한 경우에만 사용자에게 기사가 표시된다는 정보를 저장합니다. 나를 위협하는 최악의 상황은 메시지를 여러 번 보내는 것입니다(메시지가 전달되었지만 확인 메시지가 손실된 경우). 원칙적으로 첫 번째 배우가 상태를 자신 안에 저장하지 않고 일부 데이터베이스와 통신했다면 눈에 띄지 않게 넘어져 다시 살아날 수도 있습니다. 액터의 상태를 복원하기 위해 akka 지속성을 시도할 수도 있지만 현재 구현은 단순성 때문에 나에게 적합합니다. 내 코드가 자주 충돌하는 것은 아닙니다. 오히려 그것을 불가능하게 만들기 위해 많은 노력을 기울였습니다. 하지만 이런 일이 벌어지고, 프로그램을 분리된 조각으로 나누는 능력, 즉 배우들이 나에게는 정말 편리하고 실용적으로 보였습니다.

코드가 깨지면 즉시 알 수 있도록 Circle-ci를 추가했습니다. 최소한 이는 코드 컴파일이 중지되었음을 의미합니다. 처음에는 트래비스를 추가하고 싶었지만 포크 없이 내 프로젝트만 표시되었습니다. 일반적으로 이 두 가지 모두 오픈 리포지토리에서 자유롭게 사용할 수 있습니다.

결과

벌써 XNUMX월이네요. 봇이 작성되어 있는데, 지난 XNUMX주 동안 사용해봤는데 마음에 들었어요. 개선할 아이디어가 있으면 적어주세요. 수익을 창출하는 데 의미가 없습니다. 그냥 작동하도록 두고 흥미로운 기사를 보내세요.

봇 링크: https://t.me/HabraFilterBot
Github: https://github.com/Kright/habrahabr_reader

작은 결론:

• 작은 프로젝트라도 시간이 오래 걸릴 수 있습니다.
• 당신은 구글이 아닙니다. 대포에서 참새를 쏘는 것은 의미가 없습니다. 간단한 솔루션도 효과가 있을 수 있습니다.
• 애완동물 프로젝트는 새로운 기술을 실험하는데 매우 좋습니다.
• 텔레그램 봇은 매우 간단하게 작성되었습니다. “팀워크”와 기술 실험이 아니었다면 봇은 XNUMX~XNUMX주 안에 작성되었을 것입니다.
• 행위자 모델은 멀티스레딩 및 내결함성 코드와 잘 어울리는 흥미로운 것입니다.
• 오픈소스 커뮤니티가 포크를 좋아하는 이유를 맛본 것 같습니다.
• 애플리케이션 상태가 더 이상 애플리케이션 충돌/다시 시작에 의존하지 않기 때문에 데이터베이스는 좋지만 데이터베이스 작업으로 인해 코드가 복잡해지고 데이터 구조에 제한이 적용됩니다.

출처 : habr.com