Habr இலிருந்து கட்டுரைகளின் தனிப்பயனாக்கப்பட்ட தேர்வுக்கான Telegram bot

"ஏன்?" போன்ற கேள்விகளுக்கு ஒரு பழைய கட்டுரை உள்ளது - இயற்கையான Geektimes - விண்வெளியை சுத்தம் செய்யும்.

நிறைய கட்டுரைகள் உள்ளன, அகநிலை காரணங்களுக்காக அவற்றில் சில எனக்குப் பிடிக்கவில்லை, சில, மாறாக, அதைத் தவிர்ப்பது பரிதாபம். இந்த செயல்முறையை மேம்படுத்தி நேரத்தை மிச்சப்படுத்த விரும்புகிறேன்.

மேலே உள்ள கட்டுரை உலாவியில் உள்ள ஸ்கிரிப்டிங் அணுகுமுறையைப் பரிந்துரைத்தது, ஆனால் பின்வரும் காரணங்களுக்காக நான் அதை (நான் முன்பு பயன்படுத்தியிருந்தாலும்) உண்மையில் விரும்பவில்லை:

• உங்கள் கணினி/ஃபோனில் உள்ள வெவ்வேறு உலாவிகளுக்கு, முடிந்தால், அதை மீண்டும் உள்ளமைக்க வேண்டும்.
• ஆசிரியர்களால் கண்டிப்பான வடிகட்டுதல் எப்போதும் வசதியானது அல்ல.
• நீங்கள் தவறவிட விரும்பாத கட்டுரைகளின் ஆசிரியர்களின் பிரச்சனை, அவை வருடத்திற்கு ஒருமுறை வெளியிடப்பட்டாலும், தீர்க்கப்படவில்லை.

கட்டுரை மதிப்பீடுகளின் அடிப்படையில் தளத்தில் கட்டமைக்கப்பட்ட வடிகட்டுதல் எப்போதும் வசதியானது அல்ல, ஏனெனில் மிகவும் சிறப்பு வாய்ந்த கட்டுரைகள், அவற்றின் மதிப்பு இருந்தபோதிலும், ஒரு சாதாரண மதிப்பீட்டைப் பெறலாம்.

ஆரம்பத்தில், நான் RSS ஊட்டத்தை (அல்லது பல) உருவாக்க விரும்பினேன், அங்கு சுவாரஸ்யமான விஷயங்களை மட்டுமே விட்டுவிட்டேன். ஆனால் இறுதியில், RSS ஐப் படிப்பது மிகவும் வசதியானதாகத் தெரியவில்லை என்று மாறியது: எந்தவொரு சந்தர்ப்பத்திலும், ஒரு கட்டுரைக்கு கருத்து / வாக்களிக்க / உங்களுக்கு பிடித்தவற்றில் சேர்க்க, நீங்கள் உலாவி வழியாக செல்ல வேண்டும். அதனால்தான் எனக்கு தனிப்பட்ட செய்தியில் சுவாரஸ்யமான கட்டுரைகளை அனுப்பும் டெலிகிராம் போட் ஒன்றை எழுதினேன். டெலிகிராம் அவர்களிடமிருந்து அழகான முன்னோட்டங்களை உருவாக்குகிறது, இது ஆசிரியர்/மதிப்பீடு/காட்சிகள் பற்றிய தகவல்களுடன் இணைந்து, மிகவும் தகவலறிந்ததாகத் தெரிகிறது.

வெட்டுக்கு கீழே வேலையின் அம்சங்கள், எழுதும் செயல்முறை மற்றும் தொழில்நுட்ப தீர்வுகள் போன்ற விவரங்கள் உள்ளன.

போட் பற்றி சுருக்கமாக

களஞ்சியம்: https://github.com/Kright/habrahabr_reader

தந்தியில் பாட்: https://t.me/HabraFilterBot

குறிச்சொற்கள் மற்றும் ஆசிரியர்களுக்கு பயனர் கூடுதல் மதிப்பீட்டை அமைக்கிறார். அதன் பிறகு, கட்டுரைகளுக்கு ஒரு வடிப்பான் பயன்படுத்தப்படுகிறது - ஹப்ரேயில் கட்டுரையின் மதிப்பீடு, ஆசிரியரின் பயனர் மதிப்பீடு மற்றும் குறிச்சொல் மூலம் பயனர் மதிப்பீடுகளுக்கான சராசரி ஆகியவை சேர்க்கப்படுகின்றன. பயனர் குறிப்பிட்ட வரம்பை விட அதிகமாக இருந்தால், கட்டுரை வடிப்பானைக் கடந்து செல்லும்.

ஒரு போட் எழுதுவதற்கான ஒரு பக்க இலக்கு வேடிக்கை மற்றும் அனுபவத்தைப் பெறுவதாகும். கூடுதலாக, நான் அதை அடிக்கடி நினைவுபடுத்தினேன் நான் கூகுள் இல்லை, எனவே பல விஷயங்கள் முடிந்தவரை எளிமையாகவும் பழமையானதாகவும் செய்யப்படுகின்றன. இருப்பினும், இது போட் எழுதும் செயல்முறையை மூன்று மாதங்கள் எடுப்பதைத் தடுக்கவில்லை.

வெளியில் கோடை காலம்

ஜூலை முடிவடைகிறது, நான் ஒரு போட் எழுத முடிவு செய்தேன். தனியாக அல்ல, ஆனால் ஸ்கலாவில் தேர்ச்சி பெற்ற ஒரு நண்பருடன், அதில் ஏதாவது எழுத விரும்பினார். ஆரம்பம் நம்பிக்கைக்குரியதாகத் தோன்றியது - ஒரு குழுவால் குறியீடு வெட்டப்படும், பணி எளிதாகத் தோன்றியது, மேலும் ஓரிரு வாரங்கள் அல்லது ஒரு மாதத்தில் போட் தயாராகிவிடும் என்று நினைத்தேன்.

கடந்த சில வருடங்களாக நானே ராக் மீது அவ்வப்போது குறியீட்டை எழுதி வருகிறேன் என்ற போதிலும், இந்த குறியீட்டை யாரும் பொதுவாகப் பார்ப்பதில்லை அல்லது பார்ப்பதில்லை: செல்லப்பிராணி திட்டங்கள், சில யோசனைகளைச் சோதித்தல், தரவை முன்கூட்டியே செயலாக்குதல், FP இலிருந்து சில கருத்துகளில் தேர்ச்சி பெறுதல். ஒரு குழுவில் எழுதும் குறியீடு எப்படி இருக்கும் என்பதில் நான் மிகவும் ஆர்வமாக இருந்தேன், ஏனென்றால் ராக் குறியீடு மிகவும் வித்தியாசமான வழிகளில் எழுதப்படலாம்.

என்ன போயிருக்க முடியும் எனவே? இருப்பினும், விஷயங்களை அவசரப்படுத்த வேண்டாம்.
கமிட் வரலாற்றைப் பயன்படுத்தி நடக்கும் அனைத்தையும் கண்காணிக்க முடியும்.

ஒரு அறிமுகமானவர் ஜூலை 27 அன்று ஒரு களஞ்சியத்தை உருவாக்கினார், ஆனால் வேறு எதுவும் செய்யவில்லை, அதனால் நான் குறியீட்டை எழுத ஆரம்பித்தேன்.

ஜூலை 26

சுருக்கமாக: நான் ஹப்ரின் ஆர்எஸ்எஸ் ஊட்டத்தை பாகுபடுத்தி எழுதினேன்.

• com.github.pureconfig வகைபாதுகாப்பான கட்டமைப்புகளை நேரடியாக வழக்கு வகுப்புகளில் படிக்க (இது மிகவும் வசதியாக மாறியது)
• scala-xml xml ஐப் படிக்க: ஆரம்பத்தில் நான் rss ஊட்டத்திற்காக எனது சொந்த செயலாக்கத்தை எழுத விரும்பினேன், மேலும் rss feed xml வடிவத்தில் இருப்பதால், இந்த நூலகத்தைப் பாகுபடுத்தப் பயன்படுத்தினேன். உண்மையில், ஆர்எஸ்எஸ் பாகுபடுத்தலும் தோன்றியது.
• scalatest சோதனைகளுக்கு. சிறிய திட்டங்களுக்கு கூட, சோதனைகளை எழுதுவது நேரத்தை மிச்சப்படுத்துகிறது - எடுத்துக்காட்டாக, xml பாகுபடுத்தலை பிழைத்திருத்தம் செய்யும் போது, ​​அதை ஒரு கோப்பில் பதிவிறக்கம் செய்வது, சோதனைகளை எழுதுவது மற்றும் பிழைகளை சரிசெய்வது மிகவும் எளிதானது. தவறான utf-8 எழுத்துகளுடன் சில விசித்திரமான html பாகுபடுத்தும் ஒரு பிழை பின்னர் தோன்றியபோது, ​​அதை ஒரு கோப்பில் வைத்து சோதனையைச் சேர்ப்பது மிகவும் வசதியானது.
• அக்காவிலிருந்து நடிகர்கள். புறநிலையாக, அவை எதுவும் தேவையில்லை, ஆனால் திட்டம் வேடிக்கைக்காக எழுதப்பட்டது, நான் அவற்றை முயற்சிக்க விரும்பினேன். இதன் விளைவாக, நான் அதை விரும்பினேன் என்று சொல்ல தயாராக இருக்கிறேன். OOP இன் யோசனையை மறுபக்கத்தில் இருந்து பார்க்க முடியும் - செய்திகளை பரிமாறிக்கொள்ளும் நடிகர்கள் உள்ளனர். மேலும் சுவாரஸ்யமான விஷயம் என்னவென்றால், செய்தி வராமல் அல்லது செயலாக்கப்படாமல் இருக்கும் வகையில் நீங்கள் குறியீட்டை எழுதலாம் (மற்றும் வேண்டும்) (பொதுவாக, கணக்கு ஒரே கணினியில் இயங்கும் போது, ​​செய்திகளை இழக்கக்கூடாது). முதலில் நான் தலையை சொறிந்து கொண்டிருந்தேன், நடிகர்கள் ஒருவருக்கொருவர் சந்தா செலுத்தும் குறியீட்டில் குப்பை இருந்தது, ஆனால் இறுதியில் நான் எளிமையான மற்றும் நேர்த்தியான கட்டிடக்கலையை கொண்டு வர முடிந்தது. ஒவ்வொரு நடிகருக்குள்ளும் உள்ள குறியீடு ஒற்றை-திரிக்கப்பட்டதாகக் கருதப்படலாம்; ஒரு நடிகர் செயலிழக்கும்போது, ​​அக்கா அதை மறுதொடக்கம் செய்கிறது - இதன் விளைவாக மிகவும் தவறு-சகிப்புத்தன்மை கொண்ட அமைப்பு.

ஆகஸ்ட் ஆக

திட்டத்தில் சேர்த்தேன் scala-scrapper Habr இலிருந்து html பக்கங்களைப் பாகுபடுத்துவதற்கு (கட்டுரை மதிப்பீடு, புக்மார்க்குகளின் எண்ணிக்கை போன்ற தகவல்களைப் பெற).

மற்றும் பூனைகள். பாறையில் இருப்பவை.

விநியோகிக்கப்பட்ட தரவுத்தளங்களைப் பற்றிய புத்தகத்தைப் படித்தேன், CRDT (மோதல் இல்லாத பிரதி தரவு வகை, https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type, habr), எனவே ஹப்ரே பற்றிய கட்டுரையைப் பற்றிய தகவலுக்காக பரிமாற்ற அரைகுழுவின் வகை வகுப்பை இடுகையிட்டேன்.

உண்மையில், யோசனை மிகவும் எளிமையானது - எங்களிடம் ஏகபோகமாக மாறும் கவுண்டர்கள் உள்ளன. பதவி உயர்வுகளின் எண்ணிக்கை படிப்படியாக அதிகரித்து வருகிறது, அதே போல் பிளஸ்களின் எண்ணிக்கையும் (அத்துடன் மைனஸ்களின் எண்ணிக்கையும்). ஒரு கட்டுரையைப் பற்றிய தகவல்களின் இரண்டு பதிப்புகள் என்னிடம் இருந்தால், நான் "அவற்றை ஒன்றாக இணைக்க" முடியும் - பெரிய கவுண்டரின் நிலை மிகவும் பொருத்தமானதாகக் கருதப்படுகிறது.

ஒரு அரைகுழு என்பது ஒரு கட்டுரையைப் பற்றிய தகவல்களைக் கொண்ட இரண்டு பொருட்களை ஒன்றாக இணைக்க முடியும். மாற்றியமைத்தல் என்பது நீங்கள் A + B மற்றும் B + A இரண்டையும் ஒன்றிணைக்க முடியும் என்பதாகும், இதன் முடிவு வரிசையைச் சார்ந்தது அல்ல, இறுதியில் புதிய பதிப்பு இருக்கும். மூலம், இங்கே சங்கதியும் உள்ளது.

எடுத்துக்காட்டாக, திட்டமிட்டபடி, கட்டுரையைப் பற்றிய பார்வைகளின் எண்ணிக்கை போன்ற அளவீடுகள் இல்லாமல் - பாகுபடுத்திய பின் ஆர்எஸ்எஸ் சற்று பலவீனமான தகவலை வழங்கியது. ஒரு சிறப்பு நடிகர் பின்னர் கட்டுரைகள் பற்றிய தகவல்களை எடுத்து, அதை புதுப்பித்து பழைய பதிப்பில் இணைக்க html பக்கங்களுக்கு ஓடினார்.

பொதுவாக, அக்காவைப் போல, இது தேவையில்லை, நீங்கள் கட்டுரைக்கான புதுப்பிப்புத் தேதியை சேமித்து, எந்த இணைப்பும் இல்லாமல் புதியதை எடுக்கலாம், ஆனால் சாகசப் பாதை என்னை வழிநடத்தியது.

ஆகஸ்ட் ஆக

நான் சுதந்திரமாக உணர ஆரம்பித்தேன், வேடிக்கைக்காக, ஒவ்வொரு அரட்டையையும் தனி நடிகராக ஆக்கினேன். கோட்பாட்டளவில், ஒரு நடிகரின் எடை சுமார் 300 பைட்டுகள் மற்றும் அவை மில்லியன் கணக்கில் உருவாக்கப்படலாம், எனவே இது முற்றிலும் இயல்பான அணுகுமுறை. தீர்வு மிகவும் சுவாரஸ்யமாக மாறியது என்று எனக்குத் தோன்றுகிறது:

ஒரு நடிகர் தந்தி சர்வருக்கும் அக்காவில் உள்ள செய்தி அமைப்புக்கும் இடையே ஒரு பாலமாக இருந்தார். அவர் வெறுமனே செய்திகளைப் பெற்று, விரும்பிய அரட்டை நடிகருக்கு அனுப்பினார். அரட்டை நடிகர் பதிலுக்கு ஏதாவது திருப்பி அனுப்பலாம் - அது மீண்டும் தந்திக்கு அனுப்பப்படும். மிகவும் வசதியான விஷயம் என்னவென்றால், இந்த நடிகர் முடிந்தவரை எளிமையானவராக மாறினார் மற்றும் செய்திகளுக்கு பதிலளிப்பதற்கான தர்க்கத்தை மட்டுமே கொண்டிருந்தார். மூலம், ஒவ்வொரு அரட்டையிலும் புதிய கட்டுரைகள் பற்றிய தகவல்கள் வந்தன, ஆனால் மீண்டும் இதில் எந்த பிரச்சனையும் இல்லை.

பொதுவாக, போட் ஏற்கனவே வேலை செய்து, செய்திகளுக்கு பதிலளித்து, பயனருக்கு அனுப்பப்பட்ட கட்டுரைகளின் பட்டியலைச் சேமித்து, போட் கிட்டத்தட்ட தயாராக உள்ளது என்று நான் ஏற்கனவே நினைத்தேன். ஆசிரியர் பெயர்கள் மற்றும் குறிச்சொற்களை இயல்பாக்குவது போன்ற சிறிய அம்சங்களை மெதுவாகச் சேர்த்தேன் ("sd f" ஐ "s_d_f" உடன் மாற்றுவது).

எஞ்சியிருந்தது ஒன்றே ஒன்றுதான் சிறிய ஆனால் - மாநிலம் எங்கும் காப்பாற்றப்படவில்லை.

எல்லாம் தவறாகிவிட்டது

நான் பாட் பெரும்பாலும் தனியாக எழுதியதை நீங்கள் கவனித்திருக்கலாம். எனவே, இரண்டாவது பங்கேற்பாளர் வளர்ச்சியில் ஈடுபட்டார், மேலும் குறியீட்டில் பின்வரும் மாற்றங்கள் தோன்றின:

• மோங்கோடிபி மாநிலத்தை சேமிக்கத் தோன்றியது. அதே நேரத்தில், திட்டத்தில் உள்ள பதிவுகள் உடைந்தன, ஏனென்றால் சில காரணங்களால் மோங்கா அவற்றை ஸ்பேம் செய்யத் தொடங்கினார், மேலும் சிலர் அவற்றை உலகளவில் அணைத்தனர்.
• டெலிகிராமில் உள்ள பாலம் நடிகர் அடையாளம் காண முடியாத அளவிற்கு மாற்றப்பட்டு, செய்திகளை தானே பாகுபடுத்தத் தொடங்கினார்.
• அரட்டைகளுக்கான நடிகர்கள் இரக்கமின்றி வெட்டப்பட்டனர், அதற்கு பதிலாக அவர்கள் ஒரு நடிகரால் மாற்றப்பட்டனர், அவர் அனைத்து அரட்டைகள் பற்றிய அனைத்து தகவல்களையும் ஒரே நேரத்தில் மறைத்தார். ஒவ்வொரு தும்மலுக்கும் இந்த நடிகர் சிக்கலில் சிக்கினார். சரி, ஆம், ஒரு கட்டுரையைப் பற்றிய தகவலைப் புதுப்பிக்கும்போது, ​​அதை அனைத்து அரட்டை நடிகர்களுக்கும் அனுப்புவது கடினம் (நாங்கள் கூகிள் போன்றவர்கள், மில்லியன் கணக்கான பயனர்கள் ஒவ்வொருவருக்கும் அரட்டையில் ஒரு மில்லியன் கட்டுரைகளுக்காக காத்திருக்கிறார்கள்), ஆனால் ஒவ்வொரு முறையும் அரட்டை புதுப்பிக்கப்படும், மோங்காவிற்குள் செல்வது இயல்பானது. நான் மிகவும் பின்னர் உணர்ந்தது போல், அரட்டைகளின் வேலை தர்க்கம் முற்றிலும் வெட்டப்பட்டது மற்றும் அதன் இடத்தில் வேலை செய்யாத ஒன்று தோன்றியது.
• வகை வகுப்புகளில் எந்த தடயமும் இல்லை.
• சில ஆரோக்கியமற்ற தர்க்கங்கள் நடிகர்கள் ஒருவருக்கொருவர் சந்தாக்களுடன் தோன்றி, இனம் நிலைக்கு இட்டுச் சென்றது.
• வகையின் புலங்களைக் கொண்ட தரவு கட்டமைப்புகள் Option[Int] -1 போன்ற மாயாஜால இயல்புநிலை மதிப்புகளுடன் Int ஆக மாற்றப்பட்டது. மோங்கோடிபி json ஐ சேமித்து வைக்கிறது என்பதையும், அதை அங்கே சேமிப்பதில் தவறில்லை என்பதையும் பின்னர் உணர்ந்தேன் Option சரி, அல்லது குறைந்தபட்சம் -1 எதுவுமில்லை என அலசவும், ஆனால் அந்த நேரத்தில் எனக்கு இது தெரியாது மற்றும் "அப்படித்தான் இருக்க வேண்டும்" என்று என் வார்த்தையை எடுத்துக் கொண்டேன். நான் அந்த குறியீட்டை எழுதவில்லை, தற்போதைக்கு அதை மாற்றுவதில் நான் கவலைப்படவில்லை.
• எனது பொது ஐபி முகவரி மாறுவதைக் கண்டறிந்தேன், ஒவ்வொரு முறையும் அதை மோங்கோவின் அனுமதிப்பட்டியலில் சேர்க்க வேண்டும். நான் போட்டை உள்நாட்டில் தொடங்கினேன், மோங்கா ஒரு நிறுவனமாக மோங்காவின் சர்வர்களில் எங்கோ இருந்தது.
• திடீரென்று, குறிச்சொற்களின் இயல்பாக்கம் மற்றும் தந்திகளுக்கான செய்தி வடிவமைத்தல் மறைந்துவிட்டது. (ஹ்ம்ம், அது ஏன்?)
• போட்டின் நிலை வெளிப்புற தரவுத்தளத்தில் சேமிக்கப்படுவதை நான் விரும்பினேன், மறுதொடக்கம் செய்யும்போது அது எதுவும் நடக்காதது போல் தொடர்ந்து செயல்படுகிறது. இருப்பினும், இது ஒரே பிளஸ் ஆகும்.

இரண்டாவது நபர் குறிப்பாக அவசரப்படவில்லை, இந்த மாற்றங்கள் அனைத்தும் செப்டம்பர் தொடக்கத்தில் ஏற்கனவே ஒரு பெரிய குவியலில் தோன்றின. இதன் விளைவாக ஏற்படும் அழிவின் அளவை நான் உடனடியாகப் பாராட்டவில்லை, மேலும் தரவுத்தளத்தின் வேலையைப் புரிந்துகொள்ள ஆரம்பித்தேன், ஏனென்றால்... நான் இதுவரை அவர்களுடன் பழகியதில்லை. பிறகுதான் எனக்கு வேலை குறியீடு எவ்வளவு வெட்டப்பட்டது மற்றும் அதன் இடத்தில் எத்தனை பிழைகள் சேர்க்கப்பட்டன என்பதை உணர்ந்தேன்.

செப்டம்பர்

மோங்காவை மாஸ்டர் செய்து நன்றாகச் செய்வது பயனுள்ளதாக இருக்கும் என்று முதலில் நினைத்தேன். தரவுத்தளத்துடன் தகவல்தொடர்புகளை ஒழுங்கமைப்பதும் ஒரு கலை, அதில் நீங்கள் நிறைய பந்தயங்களைச் செய்யலாம் மற்றும் தவறுகளைச் செய்யலாம் என்பதை நான் மெதுவாகப் புரிந்துகொள்ள ஆரம்பித்தேன். எடுத்துக்காட்டாக, பயனர் இரண்டு செய்திகளைப் பெற்றால் /subscribe - மற்றும் ஒவ்வொன்றிற்கும் பதிலளிக்கும் வகையில், அட்டவணையில் ஒரு உள்ளீட்டை உருவாக்குவோம், ஏனெனில் அந்தச் செய்திகளைச் செயலாக்கும் போது பயனர் குழுசேரவில்லை. மோங்காவுடன் தற்போதைய வடிவத்தில் தொடர்பு சிறந்த முறையில் எழுதப்படவில்லை என்ற சந்தேகம் எனக்கு உள்ளது. எடுத்துக்காட்டாக, பயனரின் அமைப்புகள் அவர் பதிவு செய்த தருணத்தில் உருவாக்கப்பட்டன. சந்தாவின் உண்மைக்கு முன் அவற்றை மாற்ற முயன்றால்... பாட் எதற்கும் பதிலளிக்கவில்லை, ஏனெனில் நடிகரில் உள்ள குறியீடு அமைப்புகளுக்கான தரவுத்தளத்தில் சென்று அதைக் கண்டுபிடிக்கவில்லை மற்றும் செயலிழந்தது. தேவைக்கேற்ப அமைப்புகளை ஏன் உருவாக்கக்கூடாது என்று கேட்டபோது, ​​பயனர் குழுசேரவில்லை என்றால், அவற்றை மாற்ற வேண்டிய அவசியமில்லை என்பதை அறிந்தேன்... செய்தி வடிகட்டுதல் அமைப்பு எப்படியோ வெளிப்படையாக இல்லாமல் செய்யப்பட்டது, மேலும் குறியீட்டை உன்னிப்பாகப் பார்த்த பிறகும் என்னால் முடிந்தது இது ஆரம்பத்தில் இந்த வழியில் இருந்ததா அல்லது பிழை உள்ளதா என்பது புரியவில்லை.

அரட்டையில் சமர்ப்பிக்கப்பட்ட கட்டுரைகளின் பட்டியல் எதுவும் இல்லை; மாறாக, அவற்றை நானே எழுதும்படி பரிந்துரைக்கப்பட்டது. இது என்னை ஆச்சரியப்படுத்தியது - பொதுவாக, எல்லா வகையான விஷயங்களையும் திட்டத்தில் இழுப்பதை நான் எதிர்க்கவில்லை, ஆனால் இந்த விஷயங்களைக் கொண்டு வந்து அவற்றைத் திருகியவருக்கு இது தர்க்கரீதியானதாக இருக்கும். ஆனால் இல்லை, இரண்டாவது பங்கேற்பாளர் எல்லாவற்றையும் விட்டுவிடுவது போல் தோன்றியது, ஆனால் அரட்டையில் உள்ள பட்டியல் ஒரு மோசமான தீர்வாக இருப்பதாகக் கூறப்படுகிறது, மேலும் "பயனர் x க்கு ஒரு கட்டுரை y அனுப்பப்பட்டது" போன்ற நிகழ்வுகளுடன் ஒரு அடையாளத்தை உருவாக்குவது அவசியம் என்று கூறினார். பின்னர், பயனர் புதிய கட்டுரைகளை அனுப்பக் கோரினால், தரவுத்தளத்திற்கு ஒரு கோரிக்கையை அனுப்ப வேண்டியது அவசியம், இது நிகழ்வுகளிலிருந்து பயனர் தொடர்பான நிகழ்வுகளைத் தேர்ந்தெடுக்கும், புதிய கட்டுரைகளின் பட்டியலைப் பெறவும், அவற்றை வடிகட்டி, பயனருக்கு அனுப்பவும். மற்றும் இது பற்றிய நிகழ்வுகளை மீண்டும் தரவுத்தளத்தில் எறியுங்கள்.

இரண்டாவது பங்கேற்பாளர் சுருக்கங்களை நோக்கி எங்காவது கொண்டு செல்லப்பட்டார், அப்போது போட் ஹப்ரிடமிருந்து கட்டுரைகளை மட்டும் பெறாது மற்றும் தந்திக்கு மட்டும் அனுப்பப்படும்.

செப்டம்பர் இரண்டாம் பாதியில் ஒரு தனி அடையாளத்தின் வடிவத்தில் நிகழ்வுகளை எப்படியாவது செயல்படுத்தினேன். இது உகந்ததாக இல்லை, ஆனால் குறைந்தபட்சம் போட் வேலை செய்யத் தொடங்கியது மற்றும் மீண்டும் எனக்கு கட்டுரைகளை அனுப்பத் தொடங்கியது, மேலும் குறியீட்டில் என்ன நடக்கிறது என்பதை நான் மெதுவாக கண்டுபிடித்தேன்.

இப்போது நீங்கள் தொடக்கத்திற்குச் சென்று, களஞ்சியம் நான் முதலில் உருவாக்கவில்லை என்பதை நினைவில் கொள்ளலாம். என்ன இப்படி போயிருக்க முடியும்? எனது கோரிக்கை நிராகரிக்கப்பட்டது. என்னிடம் ரெட்நெக் குறியீடு உள்ளது, ஒரு குழுவில் எப்படி வேலை செய்வது என்று எனக்குத் தெரியவில்லை, மேலும் தற்போதைய செயல்படுத்தல் வளைவில் உள்ள பிழைகளைச் சரிசெய்ய வேண்டியிருந்தது, மேலும் அதைப் பயன்படுத்தக்கூடிய நிலைக்குச் செம்மைப்படுத்தவில்லை.

நான் வருத்தப்பட்டு, கமிட் ஹிஸ்டரி மற்றும் எழுதப்பட்ட குறியீட்டின் அளவைப் பார்த்தேன். நான் முதலில் நன்றாக எழுதப்பட்ட தருணங்களைப் பார்த்தேன், பின்னர் மீண்டும் உடைந்தேன் ...

F*rk அதை

கட்டுரை நினைவுக்கு வந்தது நீங்கள் Google அல்ல.

நடைமுறைப்படுத்தாமல் யாருக்கும் யோசனை தேவையில்லை என்று நினைத்தேன். நான் ஒரு வேலை செய்யும் போட் வேண்டும் என்று நினைத்தேன், இது ஒரு கணினியில் ஒரு நகலில் ஒரு எளிய ஜாவா நிரலாக வேலை செய்யும். இதுபோன்ற போட்களை நான் ஏற்கனவே எழுதியிருப்பதால், எனது போட் மறுதொடக்கம் இல்லாமல் பல மாதங்கள் வேலை செய்யும் என்று எனக்குத் தெரியும். அது திடீரென்று விழுந்து பயனருக்கு வேறொரு கட்டுரையை அனுப்பவில்லை என்றால், வானம் தரையில் விழாது, பேரழிவு எதுவும் நடக்காது.

குறியீடு வேலை செய்யாவிட்டாலோ அல்லது தவறாக வேலை செய்தாலோ எனக்கு ஏன் Docker, mongoDB மற்றும் "தீவிர" மென்பொருளின் பிற சரக்கு வழிபாட்டு முறை தேவை?

நான் திட்டத்தை கைவிட்டு, நான் விரும்பியபடி அனைத்தையும் செய்தேன்.

அதே நேரத்தில், நான் வேலைகளை மாற்றினேன், ஓய்வு நேரம் மிகவும் குறைவாக இருந்தது. காலையில் நான் ரயிலில் எழுந்தேன், மாலையில் நான் தாமதமாகத் திரும்பினேன், இனி எதுவும் செய்ய விரும்பவில்லை. நான் சிறிது நேரம் எதுவும் செய்யவில்லை, பின்னர் போட் முடிக்க வேண்டும் என்ற ஆசை என்னை ஆட்கொண்டது, நான் காலையில் வேலைக்குச் செல்லும்போது குறியீட்டை மெதுவாக மீண்டும் எழுத ஆரம்பித்தேன். இது பயனுள்ளதாக இருந்தது என்று நான் கூறமாட்டேன்: மடியில் மடிக்கணினியுடன் நடுங்கும் ரயிலில் உட்கார்ந்து, உங்கள் தொலைபேசியிலிருந்து ஸ்டாக் ஓவர்ஃப்ளோவைப் பார்ப்பது மிகவும் வசதியானது அல்ல. இருப்பினும், குறியீடு எழுதுவதற்கு செலவழித்த நேரம் முற்றிலும் கவனிக்கப்படாமல் பறந்தது, மேலும் திட்டம் மெதுவாக செயல்படும் நிலையை நோக்கி நகரத் தொடங்கியது.

என் மனதின் பின்புறத்தில் எங்கோ மோங்கோடிபியைப் பயன்படுத்த விரும்பும் சந்தேகத்தின் புழு இருந்தது, ஆனால் "நம்பகமான" நிலை சேமிப்பகத்தின் நன்மைகளுக்கு கூடுதலாக, குறிப்பிடத்தக்க குறைபாடுகளும் இருப்பதாக நான் நினைத்தேன்:

• தரவுத்தளம் தோல்வியின் மற்றொரு புள்ளியாக மாறும்.
• குறியீடு மிகவும் சிக்கலானதாகி வருகிறது, அதை எழுத எனக்கு அதிக நேரம் எடுக்கும்.
• குறியீடு மெதுவாகவும் திறமையற்றதாகவும் மாறும்; நினைவகத்தில் ஒரு பொருளை மாற்றுவதற்குப் பதிலாக, மாற்றங்கள் தரவுத்தளத்திற்கு அனுப்பப்பட்டு, தேவைப்பட்டால், பின்வாங்கப்படும்.
• ஒரு தனி அட்டவணையில் நிகழ்வுகளின் சேமிப்பக வகைக்கு கட்டுப்பாடுகள் உள்ளன, அவை தரவுத்தளத்தின் தனித்தன்மையுடன் தொடர்புடையவை.
• மோங்காவின் சோதனைப் பதிப்பில் சில வரம்புகள் உள்ளன, அவற்றை நீங்கள் இயக்கினால், நீங்கள் மோங்காவை ஏதாவது ஒன்றைத் துவக்கி உள்ளமைக்க வேண்டும்.

நான் மோங்காவை வெட்டினேன், இப்போது போட்டின் நிலை வெறுமனே நிரலின் நினைவகத்தில் சேமிக்கப்படுகிறது மற்றும் அவ்வப்போது json வடிவத்தில் ஒரு கோப்பில் சேமிக்கப்படுகிறது. ஒருவேளை கருத்துகளில் அவர்கள் நான் தவறு என்று எழுதுவார்கள், இங்குதான் தரவுத்தளத்தைப் பயன்படுத்த வேண்டும், முதலியன. ஆனால் இது எனது திட்டம், கோப்புடனான அணுகுமுறை முடிந்தவரை எளிமையானது மற்றும் இது வெளிப்படையான முறையில் செயல்படுகிறது.

-1 போன்ற மேஜிக் மதிப்புகளை தூக்கி எறிந்துவிட்டு சாதாரண மதிப்புகளை திரும்பப் பெற்றனர் Option, அரட்டை தகவலுடன் பொருளுக்கு அனுப்பப்பட்ட கட்டுரைகளுடன் ஹாஷ் அட்டவணையின் சேமிப்பகத்தைச் சேர்த்தது. ஐந்து நாட்களுக்கு மேல் பழைய கட்டுரைகள் பற்றிய தகவல்களை நீக்குதல், அதனால் எல்லாவற்றையும் சேமிக்க முடியாது. நான் பதிவுசெய்தலை வேலை செய்யும் நிலைக்கு கொண்டு வந்தேன் - பதிவுகள் கோப்பு மற்றும் கன்சோல் இரண்டிற்கும் நியாயமான அளவில் எழுதப்பட்டுள்ளன. நிலையைச் சேமிப்பது அல்லது பயனர்கள் மற்றும் கட்டுரைகளின் எண்ணிக்கை போன்ற புள்ளிவிவரங்களைப் பெறுவது போன்ற பல நிர்வாகக் கட்டளைகளைச் சேர்த்தது.

சிறிய விஷயங்களின் தொகுப்பு சரி செய்யப்பட்டது: எடுத்துக்காட்டாக, கட்டுரைகளுக்கு, பயனரின் வடிப்பானைக் கடக்கும் நேரத்தில் பார்வைகள், விருப்பங்கள், விருப்பமின்மைகள் மற்றும் கருத்துகளின் எண்ணிக்கை இப்போது சுட்டிக்காட்டப்படுகிறது. பொதுவாக, எத்தனை சிறிய விஷயங்களை சரிசெய்ய வேண்டும் என்பது ஆச்சரியமாக இருக்கிறது. நான் ஒரு பட்டியலை வைத்திருந்தேன், அங்குள்ள "முறைகேடுகள்" அனைத்தையும் குறிப்பிட்டு முடிந்தவரை அவற்றை சரிசெய்தேன்.

எடுத்துக்காட்டாக, ஒரே செய்தியில் அனைத்து அமைப்புகளையும் நேரடியாக அமைக்கும் திறனைச் சேர்த்துள்ளேன்:

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

மற்றும் மற்றொரு அணி /settings இந்த வடிவத்தில் அவற்றை சரியாகக் காட்டுகிறது, நீங்கள் அதிலிருந்து உரையை எடுத்து அனைத்து அமைப்புகளையும் நண்பருக்கு அனுப்பலாம்.
இது ஒரு சிறிய விஷயம் போல் தெரிகிறது, ஆனால் டஜன் கணக்கான ஒத்த நுணுக்கங்கள் உள்ளன.

ஒரு எளிய நேரியல் மாதிரியின் வடிவத்தில் கட்டுரை வடிகட்டுதல் செயல்படுத்தப்பட்டது - பயனர் ஆசிரியர்கள் மற்றும் குறிச்சொற்களுக்கு கூடுதல் மதிப்பீட்டையும், அதே போல் ஒரு நுழைவு மதிப்பையும் அமைக்கலாம். ஆசிரியரின் மதிப்பீட்டின் கூட்டுத்தொகை, குறிச்சொற்களுக்கான சராசரி மதிப்பீடு மற்றும் கட்டுரையின் உண்மையான மதிப்பீடு ஆகியவை வாசல் மதிப்பை விட அதிகமாக இருந்தால், கட்டுரை பயனருக்குக் காண்பிக்கப்படும். நீங்கள் /புதிய கட்டளையுடன் கட்டுரைகளை bot கேட்கலாம் அல்லது bot க்கு குழுசேரலாம் மற்றும் நாளின் எந்த நேரத்திலும் தனிப்பட்ட செய்தியில் கட்டுரைகளை அனுப்பும்.

பொதுவாகச் சொன்னால், ஒவ்வொரு கட்டுரைக்கும் கூடுதல் அம்சங்களை (ஹப்கள், கருத்துகளின் எண்ணிக்கை, புக்மார்க்குகள், ரேட்டிங் மாற்றங்களின் இயக்கவியல், கட்டுரையின் உரையின் அளவு, படங்கள் மற்றும் குறியீடு, முக்கிய வார்த்தைகள்) வெளியே இழுத்து, பயனருக்கு சரி என்பதைக் காட்ட எனக்கு ஒரு யோசனை இருந்தது/ சரி இல்லை ஒவ்வொரு கட்டுரையின் கீழும் வாக்களித்து ஒவ்வொரு பயனருக்கும் ஒரு மாதிரியைப் பயிற்றுவிக்கவும், ஆனால் நான் மிகவும் சோம்பேறியாக இருந்தேன்.

கூடுதலாக, வேலையின் தர்க்கம் அவ்வளவு தெளிவாக இருக்காது. இப்போது நான் நோயாளி ஜீரோவிற்கு +9000 மதிப்பீட்டை கைமுறையாக அமைக்க முடியும் மற்றும் +20 வரம்பு மதிப்பீட்டின் மூலம் அவருடைய அனைத்து கட்டுரைகளையும் பெறுவதற்கு நான் உத்தரவாதம் அளிக்கிறேன் (நிச்சயமாக, சில குறிச்சொற்களுக்கு -100500 ஐ அமைக்கவில்லை என்றால்).

இறுதி கட்டிடக்கலை மிகவும் எளிமையானதாக மாறியது:

1. அனைத்து அரட்டைகள் மற்றும் கட்டுரைகளின் நிலையை சேமிக்கும் நடிகர். இது வட்டில் உள்ள ஒரு கோப்பிலிருந்து அதன் நிலையை ஏற்றுகிறது மற்றும் ஒவ்வொரு முறையும் ஒரு புதிய கோப்பில் அவ்வப்போது சேமிக்கிறது.
2. ஆர்எஸ்எஸ் ஊட்டத்திற்கு அவ்வப்போது சென்று, புதிய கட்டுரைகளைப் பற்றி அறிந்து, இணைப்புகளைப் பார்த்து, பாகுபடுத்தி, இந்தக் கட்டுரைகளை முதல் நடிகருக்கு அனுப்பும் நடிகர். கூடுதலாக, இது சில சமயங்களில் முதல் நடிகரிடமிருந்து கட்டுரைகளின் பட்டியலைக் கோருகிறது, மூன்று நாட்களுக்கு மேல் இல்லாதவற்றைத் தேர்ந்தெடுத்து, நீண்ட காலமாக புதுப்பிக்கப்படாமல், அவற்றை புதுப்பிக்கிறது.
3. தந்தி மூலம் தொடர்பு கொள்ளும் நடிகர். நான் இன்னும் செய்தியை முழுமையாக இங்கு கொண்டு வந்துள்ளேன். ஒரு இணக்கமான வழியில், நான் அதை இரண்டாகப் பிரிக்க விரும்புகிறேன் - ஒன்று உள்வரும் செய்திகளை அலசுகிறது, இரண்டாவது அனுப்பப்படாத செய்திகளை மீண்டும் அனுப்புவது போன்ற போக்குவரத்து சிக்கல்களைக் கையாளுகிறது. இப்போது மீண்டும் அனுப்புதல் இல்லை, மேலும் பிழை காரணமாக வராத செய்தி வெறுமனே இழக்கப்படும் (அது பதிவுகளில் குறிப்பிடப்படாவிட்டால்), ஆனால் இதுவரை இது எந்த பிரச்சனையும் ஏற்படவில்லை. ஒரு சில பேர் போட்க்கு குழுசேர்ந்தால், நான் செய்திகளை அனுப்புவதற்கான வரம்பை அடைந்தால் சிக்கல்கள் எழலாம்).

எனக்கு பிடித்தது என்னவென்றால், அக்காவுக்கு நன்றி, நடிகர்கள் 2 மற்றும் 3 வீழ்ச்சிகள் பொதுவாக போட்டின் செயல்திறனை பாதிக்காது. ஒருவேளை சில கட்டுரைகள் சரியான நேரத்தில் புதுப்பிக்கப்படாமல் இருக்கலாம் அல்லது சில செய்திகள் தந்திக்கு வரவில்லை, ஆனால் கணக்கு நடிகரை மறுதொடக்கம் செய்கிறது மற்றும் எல்லாம் தொடர்ந்து வேலை செய்கிறது. தந்தி நடிகர் செய்தியை வெற்றிகரமாக வழங்கியதாக பதிலளிக்கும் போது மட்டுமே கட்டுரை பயனருக்கு காண்பிக்கப்படும் என்ற தகவலை நான் சேமிக்கிறேன். என்னை அச்சுறுத்தும் மோசமான விஷயம் என்னவென்றால், செய்தியை பல முறை அனுப்புவது (அது வழங்கப்பட்டால், ஆனால் உறுதிப்படுத்தல் எப்படியோ இழக்கப்படுகிறது). கொள்கையளவில், முதல் நடிகர் தனக்குள்ளேயே நிலையைச் சேமிக்காமல், சில தரவுத்தளத்துடன் தொடர்பு கொண்டால், அவர் கண்ணுக்குத் தெரியாமல் விழுந்து வாழ்க்கைக்குத் திரும்பலாம். நடிகர்களின் நிலையை மீட்டெடுக்க நான் அக்கா விடாமுயற்சியையும் முயற்சி செய்யலாம், ஆனால் தற்போதைய செயலாக்கம் அதன் எளிமையுடன் எனக்குப் பொருந்துகிறது. எனது குறியீடு அடிக்கடி செயலிழந்தது அல்ல - மாறாக, அதை சாத்தியமற்றதாக்க நான் நிறைய முயற்சி செய்தேன். ஆனால் அது நடக்கிறது, மேலும் நிரலை தனிமைப்படுத்தப்பட்ட துண்டுகளாக உடைக்கும் திறன் எனக்கு மிகவும் வசதியானதாகவும் நடைமுறைக்குரியதாகவும் தோன்றியது.

நான் Circle-ciஐச் சேர்த்தேன், அதனால் குறியீடு உடைந்தால், அதைப் பற்றி நீங்கள் உடனடியாக அறிந்துகொள்வீர்கள். குறைந்தபட்சம், குறியீடு தொகுப்பதை நிறுத்திவிட்டது என்று அர்த்தம். ஆரம்பத்தில் நான் டிராவிஸைச் சேர்க்க விரும்பினேன், ஆனால் அது ஃபோர்க்ஸ் இல்லாமல் எனது திட்டங்களை மட்டுமே காட்டியது. பொதுவாக, இந்த இரண்டு விஷயங்களையும் திறந்த களஞ்சியங்களில் சுதந்திரமாகப் பயன்படுத்தலாம்.

முடிவுகளை

இது ஏற்கனவே நவம்பர். போட் எழுதப்பட்டுள்ளது, நான் கடந்த இரண்டு வாரங்களாக இதைப் பயன்படுத்துகிறேன், எனக்கு பிடித்திருந்தது. முன்னேற்றத்திற்கான யோசனைகள் இருந்தால், எழுதுங்கள். நான் அதை பணமாக்குவதில் அர்த்தமில்லை - அது வேலை செய்து சுவாரஸ்யமான கட்டுரைகளை அனுப்பட்டும்.

பாட் இணைப்பு: https://t.me/HabraFilterBot
கிதுப்: https://github.com/Kright/habrahabr_reader

சிறிய முடிவுகள்:

• ஒரு சிறிய திட்டம் கூட நிறைய நேரம் எடுக்கும்.
• நீங்கள் Google அல்ல. பீரங்கியில் இருந்து சிட்டுக்குருவிகளைச் சுடுவதில் எந்தப் பயனும் இல்லை. ஒரு எளிய தீர்வு நன்றாக வேலை செய்யலாம்.
• புதிய தொழில்நுட்பங்களை பரிசோதிப்பதற்கு செல்ல பிராணிகளுக்கான திட்டங்கள் மிகவும் நல்லது.
• டெலிகிராம் போட்கள் மிகவும் எளிமையாக எழுதப்பட்டுள்ளன. இது "டீம் ஒர்க்" மற்றும் தொழில்நுட்பத்துடன் சோதனைகள் இல்லாவிட்டால், போட் ஒரு வாரத்தில் அல்லது இரண்டு வாரங்களில் எழுதப்பட்டிருக்கும்.
• நடிகர் மாதிரி என்பது ஒரு சுவாரஸ்யமான விஷயம், இது மல்டி த்ரெடிங் மற்றும் தவறு-சகிப்புக் குறியீட்டுடன் நன்றாக செல்கிறது.
• ஓப்பன் சோர்ஸ் சமூகம் ஏன் ஃபோர்க்ஸை விரும்புகிறது என்பதை நான் சுவைத்தேன் என்று நினைக்கிறேன்.
• தரவுத்தளங்கள் நன்றாக இருக்கும், ஏனெனில் பயன்பாட்டின் நிலை இனி பயன்பாட்டு செயலிழப்புகள்/மறுதொடக்கம் சார்ந்து இருக்காது, ஆனால் தரவுத்தளத்துடன் பணிபுரிவது குறியீட்டை சிக்கலாக்குகிறது மற்றும் தரவு கட்டமைப்பில் கட்டுப்பாடுகளை விதிக்கிறது.

ஆதாரம்: www.habr.com