Telegram bot Habr-eko artikuluen aukeraketa pertsonalizatu baterako

"Zergatik?" bezalako galderetarako artikulu zahar bat dago - Natural Geektimes - espazioa garbiago egitea.

Artikulu asko daude, arrazoi subjektiboengatik batzuk ez zaizkit gustatzen, eta beste batzuk, aitzitik, pena ematen du salto egitea. Prozesu hau optimizatu eta denbora aurreztu nahiko nuke.

Goiko artikuluak arakatzailearen barneko scripten ikuspegia iradokitzen zuen, baina ez zitzaidan asko gustatu (lehen ere erabili izan dudan arren) arrazoi hauengatik:

• Zure ordenagailu/telefonoko arakatzaile desberdinetarako, berriro konfiguratu behar duzu, ahal bada.
• Egileen iragazketa zorrotza ez da beti komenigarria.
• Artikuluak galdu nahi ez dituzun egileen arazoa, urtean behin argitaratu arren, ez da konpondu.

Artikuluen balorazioetan oinarritutako webgunean iragaztea ez da beti komenigarria, oso espezializatutako artikuluek, balio izan arren, balorazio apala jaso dezaketelako.

Hasieran, RSS jario bat (edo hainbat) sortu nahi nuen, gauza interesgarriak bakarrik utziz. Baina azkenean, RSSa irakurtzea ez zitzaiola oso erosoa iruditzen: nolanahi ere, artikulu bat iruzkintzeko/bozkatzeko/gogokoetara gehitzeko, nabigatzailean ibili behar da. Horregatik idatzi dut mezu pertsonal batean artikulu interesgarriak bidaltzen dizkidan telegram bot bat. Telegramek berak aurrebista ederrak egiten ditu haietatik, eta, egileari/balorazioa/ikustaldiei buruzko informazioarekin konbinatuta, nahiko informatiboa dirudi.

Ebakiaren azpian, lanaren ezaugarriak, idazketa prozesua eta irtenbide teknikoak bezalako xehetasunak daude.

Laburki bot-ari buruz

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

Bot telegraman: https://t.me/HabraFilterBot

Erabiltzaileak balorazio gehigarri bat ezartzen du etiketa eta egileentzat. Horren ostean, iragazki bat aplikatzen zaie artikuluei: artikuluak Habré-n duen balorazioa, egilearen erabiltzaileen balorazioa eta etiketaren araberako erabiltzaileen balorazioen batez bestekoa gehitzen dira. Zenbatekoa erabiltzaileak zehaztutako atalasea baino handiagoa bada, artikuluak iragazkia gainditzen du.

Bot bat idazteko bigarren helburua dibertsioa eta esperientzia lortzea zen. Horrez gain, aldian-aldian hori gogoratzen nion neure buruari Ez naiz Google, eta, beraz, gauza asko ahalik eta sinpleen eta baita primitiboen egiten dira. Hala ere, horrek ez zuen eragotzi bot-a idazteko prozesuak hiru hilabete irautea.

Kanpoan uda zen

Uztaila bukatzen ari zen, eta bot bat idaztea erabaki nuen. Eta ez bakarrik, scala menperatzen ari zen eta bertan zerbait idatzi nahi zuen lagun batekin baizik. Hasierak itxaropentsua zirudien: talde batek moztuko zuen kodea, zeregina erraza zirudien eta aste pare batean edo hilabete batean bot-a prest egongo zela pentsatu nuen.

Azken urteotan nik neuk tarteka kode rock gainean idazten ibili naizen arren, normalean inork ez du ikusten edo begiratzen kode hori: maskota-proiektuak, ideia batzuk probatzea, datuak aurreprozesatzea, FPko kontzeptu batzuk menperatzea. Oso interesatzen zitzaidan talde batean kodea idaztea nolakoa den, rockean kodea oso modu ezberdinetan idatz daitekeelako.

Zer joan zitekeen beraz,? Hala ere, ez ditzagun gauzak presaka.
Gertatzen den guztiaren jarraipena egin daiteke konpromisoen historia erabiliz.

Ezagun batek biltegi bat sortu zuen uztailaren 27an, baina ez zuen beste ezer egin, beraz, kodea idazten hasi nintzen.

30 uztailaren

Laburbilduz: Habr-en rss jarioaren analisia idatzi nuen.

• com.github.pureconfig Typesafe konfigurazioak kasuen klaseetan zuzenean irakurtzeko (oso erosoa izan da)
• scala-xml xml irakurtzeko: hasieran rss jariorako neure inplementazioa idatzi nahi nuenez eta rss jarioa xml formatuan dagoenez, liburutegi hau erabili nuen analizatzeko. Egia esan, RSS analisia ere agertu zen.
• scalatest probetarako. Proiektu txikietan ere, probak idazteak denbora aurrezten du; adibidez, xml analisia araztean, askoz errazagoa da fitxategi batera deskargatzea, probak idaztea eta akatsak zuzentzea. Geroago akats bat agertu zenean utf-8 karaktere baliogabeko html arraro batzuen analisiarekin, erosoagoa izan zen fitxategi batean jartzea eta proba bat gehitzea.
• Akkako aktoreak. Objektiboki, ez ziren batere behar, baina proiektua ondo pasatzeko idatzi zen, probatu nahi nuen. Ondorioz, gustatu zaidala esateko prest nago. OOPren ideia beste alde batetik ikus daiteke - mezuak trukatzen dituzten aktoreak daude. Interesgarriena da kodea idatzi dezakezula (eta beharko zenuke) mezua ez iristeko edo prozesatu ez izateko moduan (oro har, kontua ordenagailu bakarrean exekutatzen ari denean, mezuak ez dira galdu behar). Hasieran burua urratzen ari nintzen eta aktoreak elkarren artean harpidetuta zeuden kodean zaborra zegoen, baina azkenean arkitektura sinple eta dotore samarra ateratzea lortu nuen. Aktore bakoitzaren barnean dagoen kodea hari bakarrekotzat har daiteke; aktore bat huts egiten denean, acca-k berrabiarazi egiten du; emaitza nahiko akatsekiko tolerantzia duen sistema da.

9 abuztuaren

Proiektura gehitu dut scala-scrapper Habr-eko html orriak analizatzeko (artikuluen balorazioa, laster-marken kopurua eta abar bezalako informazioa ateratzeko).

Eta Katuak. Harkaitzean daudenak.

Ondoren banatutako datu-baseei buruzko liburu bat irakurri nuen, CRDTren ideia gustatu zitzaidan (Gatazkarik gabeko datu-mota erreplikatua, https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type, habr), beraz, erditalde komunztatibo baten mota klase bat argitaratu nuen Habré-ri buruzko artikuluari buruzko informaziorako.

Izan ere, ideia oso sinplea da: monotonikoki aldatzen diren kontagailuak ditugu. Sustapen kopurua hazten ari da pixkanaka, baita plusen kopurua ere (baita minus kopurua ere). Artikulu bati buruzko informazioaren bi bertsio baditut, "bateratu" ditzaket - handiagoa den kontagailuaren egoera garrantzitsuena da.

Erditalde batek esan nahi du artikulu bati buruzko informazioa duten bi objektu bakar batean batu daitezkeela. Konmutatzaileak esan nahi du A + B eta B + A batu ditzakezula, emaitza ez da ordenaren araberakoa eta azkenean bertsio berriena geratuko da. Bide batez, hemen asoziatibotasuna ere badago.

Esate baterako, aurreikusi bezala, rss-ek analizatu ondoren artikuluari buruzko informazio apur bat ahuldua eman zuen, ikustaldi kopurua bezalako neurririk gabe. Orduan aktore berezi batek artikuluei buruzko informazioa hartu eta html orrietara joan zen eguneratu eta bertsio zaharrarekin bateratzeko.

Orokorrean, akkan bezala, ez zegoen horren beharrik, artikuluaren eguneraketa Data gorde eta berriagoa hartu zitekeen bat-egiterik gabe, baina abenturaren bideak eraman ninduen.

12 abuztuaren

Askeago sentitzen hasi nintzen eta, ondo pasatzeko, solas bakoitza aktore bereizi bihurtu nuen. Teorian, aktore batek berak 300 byte inguru pisatzen ditu eta milioika sor daitezke, beraz, ikuspegi guztiz normala da. Konponbidea nahiko interesgarria izan dela iruditzen zait:

Aktore bat telegrama zerbitzariaren eta Akkako mezu sistemaren arteko zubia zen. Besterik gabe, mezuak jaso eta nahi duzun txat-aktoreari bidali dizkio. Txat-aktoreak zerbait itzul lezake erantzun gisa, eta telegramara bidaliko litzateke. Oso komenigarria zen aktore hau ahalik eta sinpleena zela eta mezuei erantzuteko logika baino ez zuela. Bide batez, artikulu berriei buruzko informazioa txat guztietan iritsi zen, baina berriro ere ez dut arazorik ikusten honetan.

Orokorrean, bot-a jada lanean ari zen, mezuei erantzuten, erabiltzaileari bidalitako artikuluen zerrenda gordetzen, eta jada pentsatzen ari nintzen bot-a ia prest zegoela. Poliki-poliki, egileen izenak eta etiketak normalizatzea bezalako ezaugarri txikiak gehitu ditut ("sd f" ordezkatuz "s_d_f").

Gauza bakarra geratzen zen txikia baina — Estatua ez zen inon salbatu.

Dena gaizki joan zen

Konturatuko zara bot-a gehienetan bakarrik idatzi nuela. Beraz, bigarren parte-hartzaileak garapenean parte hartu zuen, eta aldaketa hauek agertu ziren kodean:

• MongoDB egoera gordetzeko agertu zen. Aldi berean, proiektuko erregistroak hautsi egin ziren, arrazoiren batengatik Monga spam-a bidaltzen hasi zelako eta pertsona batzuek globalki itzali egin baitzituzten.
• Telegram-eko zubi-aktorea aitorpenik gabe eraldatu zen eta mezuak berak analizatzen hasi zen.
• Txatetarako aktoreak errukirik gabe moztu zituzten, eta horren ordez txat guztiei buruzko informazio guztia aldi berean ezkutatzen zuen aktore batek ordezkatu zuten. Dominstiku bakoitzeko, aktore honek arazoak izaten zituen. Tira, bai, artikulu bati buruzko informazioa eguneratzean bezala, txat-eragile guztiei bidaltzea zaila da (Google bezalakoak gara, milioi bat erabiltzaile txatean milioi bat artikuluren zain daude bakoitzarentzat), baina txata eguneratzen den bakoitzean, normala da Mongara sartzea. Askoz geroago konturatu nintzenez, txatetako lan-logika ere erabat moztuta zegoen eta bere ordez funtzionatu ez zuen zerbait agertu zen.
• Mota-klaseen arrastorik ez da geratzen.
• Logika gaiztoren bat agertu da aktoreengan elkarren arteko harpidetzarekin, lasterketa baldintza bat ekarriz.
• Datu-egiturak motako eremuekin Option[Int] Int bihurtu da -1 bezalako balio lehenetsi magikoekin. Geroago konturatu nintzen mongoDB-k json gordetzen duela eta ez dagoela gaizki hor gordetzeak Option beno, edo gutxienez analizatu -1 None gisa, baina garai hartan ez nekien hau eta nire hitza hartu nuen "horrela izan behar zen". Ez nuen kode hori idatzi, eta momentuz ez nintzen aldatzeko trabarik egin.
• Nire IP helbide publikoa aldatu ohi dela jakin nuen, eta Mongoko zerrenda zurian gehitu behar izan nuen bakoitzean. Bota lokalean abiarazi nuen, Monga nonbait zegoen Mongako zerbitzarietan enpresa gisa.
• Bat-batean, etiketen normalizazioa eta telegramen mezuen formatua desagertu zen. (Hmm, zergatik izango litzateke hori?)
• Gustatu zait bot-en egoera kanpoko datu-base batean gordetzen dela, eta berrabiarazitakoan ezer gertatu ez balitz bezala funtzionatzen jarraitzen duela. Hala ere, hau izan zen abantaila bakarra.

Bigarren pertsonak ez zuen presarik izan, eta aldaketa horiek guztiak pila handi batean agertu ziren jada irailaren hasieran. Ez nuen berehala baloratu ondoriozko suntsipenaren tamaina eta datu-basearen lana ulertzen hasi nintzen, zeren... Ez dut inoiz haiekin jorratu. Geroago konturatu nintzen zenbat lan kodea moztu zen eta zenbat akats gehitu ziren haren ordez.

Iraila

Hasieran pentsatu nuen erabilgarria izango zela Monga menperatu eta ondo egitea. Orduan, poliki-poliki, datu-basearekin komunikazioa antolatzea lasterketa asko egin eta akatsak besterik ez egiteko artea dela ulertzen hasi nintzen. Adibidez, erabiltzaileak bezalako bi mezu jasotzen baditu /subscribe - eta bakoitzari erantzunez taulan sarrera bat sortuko dugu, mezu horiek prozesatzeko unean erabiltzailea ez dagoelako harpidetuta. Susmoa daukat Mongarekiko komunikazioa gaur egungo forman ez dagoela ondoen idatzita. Adibidez, erabiltzailearen ezarpenak erregistratu zen unean sortu ziren. Harpidetza egin baino lehen aldatzen saiatzen bazen... bot-ak ez zuen ezer erantzun, aktorearen kodea ezarpenetarako datu-basean sartu zelako, ez zuelako aurkitu eta huts egin zuelako. Ezarpenak behar den moduan zergatik ez sortu galdetuta, erabiltzailea harpidetu ez bada ez dagoela aldatu behar jakin nuen... Mezuak iragazteko sistema nolabait ez da argia egin, eta kodeari arretaz begiratu ondoren ere nezakeen. Ez dut ulertzen hasiera batean horrela pentsatuta zegoen edo akats bat dagoen.

Ez zegoen txatera bidalitako artikuluen zerrenda; horren ordez, nik neuk idaztea proposatu zidaten. Horrek harritu ninduen, oro har, ez nengoen era guztietako gauzak proiektuan arrastatzearen aurka, baina logikoa litzateke gauza horiek ekarri eta izorratu zituenarentzat. Baina ez, bigarren parte-hartzaileak dena amore eman zuela zirudien, baina esan zuen txataren barruko zerrenda ustez irtenbide txarra zela, eta beharrezkoa zela "y artikulua bidali zitzaion x erabiltzaileari" bezalako gertakariekin seinale bat egitea. Orduan, erabiltzaileak artikulu berriak bidaltzea eskatzen bazuen, beharrezkoa zen datu-basera eskaera bat bidali, eta horrek erabiltzaileari lotutako gertaerak hautatuko zituen ekitaldietatik, artikulu berrien zerrenda ere lortu, iragazi, erabiltzaileari bidali. eta bota honi buruzko gertaerak berriro datu-basera.

Bigarren parte-hartzailea abstrakzioetara eraman zuten nonbait, bot-ak Habr-en artikuluak ez ezik, telegramara ez ezik bidaliko dituenean.

Nolabait irailaren bigarren hamabostaldirako ekitaldiak ezarri nituen seinale bereizi baten moduan. Ez da optimoa, baina gutxienez bot-a lanean hasi zen eta berriro artikuluak bidaltzen hasi zitzaidan, eta pixkanaka-pixkanaka kodean zer gertatzen zen konturatu nintzen.

Orain hasierara itzuli zaitezke eta gogoratu biltegia ez nuela nik sortu. Zer joan zitekeen horrela? Nire tira eskaera baztertu egin da. Agertu zen redneck kodea nuela, ez nekiela taldean lan egiten eta egungo inplementazio-kurbaren akatsak konpondu behar izan ditudala, eta ez egoera erabilgarri batera findu.

Haserretu egin nintzen eta konpromezuen historia eta idatzitako kode kopurua ikusi nuen. Hasieran ondo idatzitako momentuak begiratu nituen, eta gero hautsi zirenak...

Auskalo

artikulua gogoratu nuen Ez zara Google.

Pentsatu nuen inork ez zuela ideiarik behar benetan gauzatu gabe. Laneko bot bat izan nahi nuela pentsatu nuen, ordenagailu bakarrean kopia bakarrean funtzionatuko duena java programa soil gisa. Badakit nire bot-ak hilabetez funtzionatuko duela berrabiarazi gabe, iraganean horrelako bot-ak idatzi ditudalako. Bat-batean erori eta erabiltzaileari beste artikulu bat bidaltzen ez badio, zerua ez da lurrera eroriko eta ez da ezer hondamendirik gertatuko.

Zergatik behar ditut Docker, mongoDB eta beste software "serio" baten zama-gurtza, kodea besterik ez bada funtzionatzen edo gaizki funtzionatzen badu?

Proiektua bideratu eta nahi nuen guztia egin nuen.

Garai berean, lanez aldatu eta denbora librea izugarri falta zen. Goizean trenean bertan esnatu nintzen, arratsaldean berandu itzuli nintzen eta jada ez nuen ezer egin nahi. Denbora batez ez nuen ezer egin, orduan bot-a amaitzeko gogoak menderatu ninduen, eta pixkanaka kodea berridazten hasi nintzen goizean lanera gidatzen ari nintzela. Ez dut esango produktiboa izan zenik: dardarka dagoen tren batean esertzea ordenagailu eramangarria altzoan duela eta telefonotik pila gainezkatzeari begiratzea ez da oso erosoa. Hala ere, kodea idazten emandako denbora guztiz oharkabean igaro zen, eta proiektua poliki-poliki lan-egoerarantz joaten hasi zen.

Nonbait nire buruan mongoDB erabili nahi zuen zalantza harra zegoen, baina uste nuen egoera "fidagarriaren" biltegiratzearen abantailez gain, desabantaila nabariak zeudela:

• Datu-basea beste porrot puntu bat bihurtzen da.
• Kodea gero eta konplexuagoa da, eta denbora gehiago beharko dut idazteko.
• Kodea motela eta eraginkorra bihurtzen da; memorian objektu bat aldatu beharrean, aldaketak datu-basera bidaltzen dira eta, behar izanez gero, atzera botatzen dira.
• Taula bereizi batean gertaeren biltegiratze motari buruzko murrizketak daude, datu-basearen berezitasunekin lotuta daudenak.
• Mongaren probako bertsioak muga batzuk ditu, eta haiekin topo egiten baduzu, Monga abiarazi eta konfiguratu beharko duzu zerbaitetan.

Monga moztu dut, orain bot-aren egoera programaren memorian gordetzen da eta noizean behin fitxategi batean gordetzen da json moduan. Beharbada iruzkinetan oker nagoela idatziko dute, hor erabili behar dela datu-basea, etab. Baina hau da nire proiektua, fitxategiaren planteamendua ahalik eta sinpleena da eta modu gardenean funtzionatzen du.

-1 bezalako balio magikoak bota eta normalak itzuli Option, txat-informazioarekin objektura bidalitako artikuluak dituen hash-taula baten biltegiratzea gehitu da. Bost egun baino zaharragoak diren artikuluei buruzko informazioa ezabatzea gehitu da, dena ez gordetzeko. Erregistroa lan-egoerara eraman nuen - erregistroak arrazoizko kantitateetan idazten dira fitxategian zein kontsolan. Hainbat administra-komando gehitu dira, hala nola egoera gordetzea edo estatistikak lortzea, hala nola erabiltzaile eta artikulu kopurua.

Gauza txiki mordoa konpondu dira: adibidez, artikuluen kasuan, erabiltzailearen iragazkia pasatzeko unean ikusitako, gustatu ez diren, gustatu ez diren eta iruzkinen kopurua adierazten da orain. Oro har, harritzekoa da zenbat gauza txiki zuzendu behar izan ziren. Zerrenda bat gorde nuen, han "irregulartasun" guztiak apuntatu eta ahal den neurrian zuzendu nituen.

Adibidez, ezarpen guztiak zuzenean mezu batean ezartzeko gaitasuna gehitu dut:

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

Eta beste talde bat /settings zehatz-mehatz bistaratzen ditu formulario honetan, bertatik testua hartu eta ezarpen guztiak lagun bati bidal ditzakezu.
Gauza txikia dirudi, baina dozenaka antzeko ñabardura daude.

Artikuluen iragazketa eredu lineal sinple baten moduan inplementatu da - erabiltzaileak balorazio gehigarri bat ezar dezake egileentzat eta etiketarentzat, baita atalase-balio bat ere. Egilearen balorazioa, etiketen batez besteko balorazioa eta artikuluaren benetako balorazioa atalasearen balioa baino handiagoa bada, orduan artikulua erakutsiko zaio erabiltzaileari. Bot-ari artikuluak eskatu ditzakezu /new komandoarekin, edo bot-ra harpidetu eta mezu pertsonal batean artikuluak bidaliko ditu eguneko edozein unetan.

Oro har, artikulu bakoitzak ezaugarri gehiago ateratzeko ideia bat izan nuen (zentroak, iruzkin kopurua, laster-markak, balorazio-aldaketen dinamika, testu-kopurua, artikuluaren irudiak eta kodea, gako-hitzak) eta erabiltzaileari ok/ bat erakusteko. ez dago ondo artikulu bakoitzaren azpian bozkatu eta erabiltzaile bakoitzarentzat eredu bat trebatu, baina alferra nengoen.

Gainera, lanaren logika ez da hain agerikoa izango. Orain +9000-ko ​​balorazioa eskuz ezar dezaket pazienteZerorentzat eta +20-ko atalase-balorazioarekin bermatuta egongo naiz bere artikulu guztiak jasoko ditudala (ez ez bada, jakina, etiketa batzuetarako -100500 ezarri).

Azken arkitektura nahiko sinplea izan zen:

1. Txat eta artikulu guztien egoera gordetzen duen aktorea. Bere egoera diskoko fitxategi batetik kargatzen du eta noizean behin atzera gordetzen du, aldi bakoitzean fitxategi berri batean.
2. Noizean behin RSS jarioa bisitatzen duen aktore batek, artikulu berriak ezagutu, estekak begiratu, analizatu eta artikulu horiek lehen aktoreari bidaltzen dizkio. Horrez gain, batzuetan lehen aktoreari artikulu zerrenda bat eskatzen dio, hiru egun baino zaharragoak ez direnak, baina denbora luzez eguneratu gabe daudenak hautatzen ditu eta eguneratzen ditu.
3. Telegrama batekin komunikatzen den aktorea. Oraindik mezua guztiz analizatuz ekarri dut hona. Modu adiskidetsuan, bitan banatu nahiko nuke, batak sarrerako mezuak azter ditzan eta bigarrenak garraio-arazoak lantzen ditu, hala nola bidali gabeko mezuak berriro bidaltzea. Orain ez dago berriro bidalketarik, eta errore baten ondorioz iritsi ez den mezu bat galduko da besterik gabe (erregistroetan adierazi ezean), baina orain arte horrek ez du arazorik sortu. Agian arazoak sortuko dira jende mordoa bot-ra harpidetzen bada eta mezuak bidaltzeko mugara iristen naiz).

Gustatu zaidana da akkari esker, 2 eta 3 aktoreen erorketak, oro har, ez dutela bot-aren errendimenduan eragiten. Agian artikulu batzuk ez dira garaiz eguneratzen edo mezu batzuk ez dira telegramara iristen, baina kontuak aktorea berrabiarazten du eta denak funtzionatzen jarraitzen du. Artikulua erabiltzaileari erakusten dion informazioa gordetzen dut telegramako aktoreak mezua behar bezala entregatu duela erantzuten duenean soilik. Mehatxatzen nauen gauzarik txarrena mezua hainbat aldiz bidaltzea da (entregatzen bada, baina baieztapena nolabait galdu egiten da). Printzipioz, lehen aktoreak bere baitan egoera gordetzen ez balu, datu-base batzuekin komunikatzen ez balu, orduan ezin hauteman liteke eta bizitzara itzul liteke. Akka persistentzia ere saiatuko nintzateke aktoreen egoera berreskuratzeko, baina oraingo ezarpena bere sinpletasunarekin egokitzen zait. Ez da nire kodea sarritan huts egiten zuenik; aitzitik, ahalegin handia egin nuen ezinezkoa izateko. Baina kaka gertatzen da, eta programa pieza isolatu-aktoreetan zatitzeko gaitasuna benetan erosoa eta praktikoa iruditu zitzaidan.

Circle-ci gehitu dut, kodea hausten bada, berehala jakin dezazun. Gutxienez, kodea konpilatzeari utzi diola esan nahi du. Hasieran travis gehitu nahi nuen, baina nire proiektuak sardexkarik gabe bakarrik erakusten zituen. Oro har, bi gauza hauek libreki erabil daitezke biltegi irekietan.

Emaitzak

Dagoeneko azaroa da. Bota idatzita dago, azken bi asteetan erabiltzen ari naiz eta gustatu zait. Hobetzeko ideiak badituzu, idatzi. Ez dut zentzurik ikusten dirua irabazteari: utzi funtzionatzen eta bidali artikulu interesgarriak.

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

Ondorio txikiak:

• Proiektu txiki batek ere denbora asko behar izan dezake.
• Ez zara Google. Ez du balio kanoi batetik txolarreak tiro egiteak. Irtenbide sinple batek ere ondo funtziona dezake.
• Pet proiektuak oso onak dira teknologia berriak esperimentatzeko.
• Telegram bot-ak nahiko erraz idazten dira. "Talde-lanagatik" eta teknologiarekin esperimentatu ez balitz, aste batean edo bitan idatziko zen bot-a.
• Aktore-eredua gauza interesgarri bat da, hari anitzeko eta akatsekiko tolerantzia-kodearekin ondo doana.
• Uste dut kode irekiko komunitateak sardexkak zergatik maite dituen ikusi dudala.
• Datu-baseak onak dira, aplikazioaren egoera jada ez baitago aplikazioen hutsegite/berrabiarren araberakoa, baina datu-base batekin lan egiteak kodea zaildu egiten du eta datuen egituran murrizketak ezartzen ditu.

Iturria: www.habr.com