Habr-ൽ നിന്നുള്ള ലേഖനങ്ങളുടെ വ്യക്തിഗതമായ തിരഞ്ഞെടുപ്പിനുള്ള ടെലിഗ്രാം ബോട്ട്

"എന്തുകൊണ്ട്?" തുടങ്ങിയ ചോദ്യങ്ങൾക്ക് ഒരു പഴയ ലേഖനമുണ്ട് - സ്വാഭാവിക ഗീക്ക് ടൈംസ് - സ്പേസ് ക്ലീനർ ആക്കുന്നു.

ധാരാളം ലേഖനങ്ങളുണ്ട്, ആത്മനിഷ്ഠമായ കാരണങ്ങളാൽ അവയിൽ ചിലത് എനിക്ക് ഇഷ്ടമല്ല, ചിലത്, നേരെമറിച്ച്, ഒഴിവാക്കുന്നത് ദയനീയമാണ്. ഈ പ്രക്രിയ ഒപ്റ്റിമൈസ് ചെയ്യാനും സമയം ലാഭിക്കാനും ഞാൻ ആഗ്രഹിക്കുന്നു.

മുകളിലെ ലേഖനം ഒരു ഇൻ-ബ്രൗസർ സ്‌ക്രിപ്റ്റിംഗ് സമീപനം നിർദ്ദേശിച്ചു, പക്ഷേ ഇനിപ്പറയുന്ന കാരണങ്ങളാൽ എനിക്ക് ഇത് ശരിക്കും ഇഷ്ടപ്പെട്ടില്ല (ഞാൻ മുമ്പ് ഇത് ഉപയോഗിച്ചിട്ടുണ്ടെങ്കിലും):

• നിങ്ങളുടെ കമ്പ്യൂട്ടറിലെ/ഫോണിലെ വ്യത്യസ്‌ത ബ്രൗസറുകൾക്കായി, സാധ്യമെങ്കിൽ നിങ്ങൾ അത് വീണ്ടും കോൺഫിഗർ ചെയ്യേണ്ടതുണ്ട്.
• രചയിതാക്കളുടെ കർശനമായ ഫിൽട്ടറിംഗ് എല്ലായ്പ്പോഴും സൗകര്യപ്രദമല്ല.
• നിങ്ങൾ നഷ്‌ടപ്പെടുത്താൻ ആഗ്രഹിക്കാത്ത ലേഖനങ്ങളുടെ രചയിതാക്കളുടെ പ്രശ്നം, അവ വർഷത്തിലൊരിക്കൽ പ്രസിദ്ധീകരിച്ചാലും, പരിഹരിച്ചിട്ടില്ല.

ലേഖന റേറ്റിംഗുകളെ അടിസ്ഥാനമാക്കി സൈറ്റിൽ നിർമ്മിച്ച ഫിൽട്ടറിംഗ് എല്ലായ്പ്പോഴും സൗകര്യപ്രദമല്ല, കാരണം ഉയർന്ന പ്രത്യേക ലേഖനങ്ങൾക്ക് അവയുടെ മൂല്യം ഉണ്ടായിരുന്നിട്ടും, മിതമായ റേറ്റിംഗ് ലഭിക്കും.

തുടക്കത്തിൽ, ഒരു RSS ഫീഡ് (അല്ലെങ്കിൽ പലതും) സൃഷ്ടിക്കാൻ ഞാൻ ആഗ്രഹിച്ചു, അവിടെ രസകരമായ കാര്യങ്ങൾ മാത്രം അവശേഷിക്കുന്നു. എന്നാൽ അവസാനം, RSS വായിക്കുന്നത് വളരെ സൗകര്യപ്രദമല്ലെന്ന് മനസ്സിലായി: ഏത് സാഹചര്യത്തിലും, ഒരു ലേഖനത്തിന് അഭിപ്രായമിടാൻ / വോട്ട് ചെയ്യാൻ / നിങ്ങളുടെ പ്രിയപ്പെട്ടവയിലേക്ക് ചേർക്കാൻ, നിങ്ങൾ ബ്രൗസറിലൂടെ പോകേണ്ടതുണ്ട്. അതുകൊണ്ടാണ് ഞാൻ ഒരു ടെലിഗ്രാം ബോട്ട് എഴുതിയത്, അത് എനിക്ക് ഒരു വ്യക്തിഗത സന്ദേശത്തിൽ രസകരമായ ലേഖനങ്ങൾ അയയ്ക്കുന്നു. ടെലിഗ്രാം തന്നെ അവയിൽ നിന്ന് മനോഹരമായ പ്രിവ്യൂകൾ ഉണ്ടാക്കുന്നു, അവ രചയിതാവിനെ/റേറ്റിംഗ്/കാഴ്‌ചകളെക്കുറിച്ചുള്ള വിവരങ്ങളുമായി സംയോജിപ്പിച്ച് തികച്ചും വിജ്ഞാനപ്രദമായി കാണപ്പെടുന്നു.

സൃഷ്ടിയുടെ സവിശേഷതകൾ, എഴുത്ത് പ്രക്രിയ, സാങ്കേതിക പരിഹാരങ്ങൾ തുടങ്ങിയ വിശദാംശങ്ങളാണ് കട്ടിന് താഴെയുള്ളത്.

ബോട്ടിനെക്കുറിച്ച് ചുരുക്കത്തിൽ

സംഭരണിയാണ്: https://github.com/Kright/habrahabr_reader

ടെലിഗ്രാമിലെ ബോട്ട്: https://t.me/HabraFilterBot

ടാഗുകൾക്കും രചയിതാക്കൾക്കുമായി ഉപയോക്താവ് ഒരു അധിക റേറ്റിംഗ് സജ്ജമാക്കുന്നു. അതിനുശേഷം, ലേഖനങ്ങളിൽ ഒരു ഫിൽട്ടർ പ്രയോഗിക്കുന്നു - ഹബ്രെയിലെ ലേഖനത്തിന്റെ റേറ്റിംഗ്, രചയിതാവിന്റെ ഉപയോക്തൃ റേറ്റിംഗ്, ടാഗ് പ്രകാരമുള്ള ഉപയോക്തൃ റേറ്റിംഗുകളുടെ ശരാശരി എന്നിവ കൂട്ടിച്ചേർക്കുന്നു. തുക ഉപയോക്താവ് വ്യക്തമാക്കിയ പരിധിയേക്കാൾ കൂടുതലാണെങ്കിൽ, ലേഖനം ഫിൽട്ടർ കടന്നുപോകുന്നു.

ഒരു ബോട്ട് എഴുതുന്നതിന്റെ ഒരു സൈഡ് ലക്ഷ്യം വിനോദവും അനുഭവവും നേടുക എന്നതായിരുന്നു. കൂടാതെ, ഞാൻ അത് പതിവായി എന്നെത്തന്നെ ഓർമ്മിപ്പിച്ചു ഞാൻ Google അല്ല, അതിനാൽ പല കാര്യങ്ങളും കഴിയുന്നത്ര ലളിതമായും പ്രാകൃതമായും ചെയ്യുന്നു. എന്നിരുന്നാലും, ബോട്ട് എഴുതുന്നതിനുള്ള പ്രക്രിയ മൂന്ന് മാസമെടുക്കുന്നതിൽ നിന്ന് ഇത് തടഞ്ഞില്ല.

പുറത്ത് വേനൽക്കാലമായിരുന്നു

ജൂലൈ അവസാനിക്കുകയായിരുന്നു, ഞാൻ ഒരു ബോട്ട് എഴുതാൻ തീരുമാനിച്ചു. ഒറ്റയ്‌ക്കല്ല, സ്‌കാലയിൽ വൈദഗ്‌ധ്യമുള്ള, അതിൽ എന്തെങ്കിലും എഴുതാൻ ആഗ്രഹിക്കുന്ന ഒരു സുഹൃത്തിനൊപ്പം. തുടക്കം ആശാവഹമായി തോന്നി - കോഡ് ഒരു ടീം കട്ട് ചെയ്യും, ടാസ്ക് എളുപ്പമാണെന്ന് തോന്നി, രണ്ടാഴ്ചയോ ഒരു മാസമോ ബോട്ട് തയ്യാറാകുമെന്ന് ഞാൻ കരുതി.

കഴിഞ്ഞ കുറച്ച് വർഷങ്ങളായി ഞാൻ തന്നെ കാലാകാലങ്ങളിൽ പാറയിൽ കോഡ് എഴുതുന്നുണ്ടെങ്കിലും, ആരും സാധാരണയായി ഈ കോഡ് കാണുകയോ നോക്കുകയോ ചെയ്യുന്നില്ല: വളർത്തുമൃഗങ്ങളുടെ പ്രോജക്റ്റുകൾ, ചില ആശയങ്ങൾ പരീക്ഷിക്കുക, ഡാറ്റ പ്രീപ്രോസസ്സ് ചെയ്യുക, FP-യിൽ നിന്നുള്ള ചില ആശയങ്ങൾ മാസ്റ്റേഴ്സ് ചെയ്യുക. ഒരു ടീമിലെ എഴുത്ത് കോഡ് എങ്ങനെയിരിക്കും എന്നതിൽ എനിക്ക് ശരിക്കും താൽപ്പര്യമുണ്ടായിരുന്നു, കാരണം റോക്കിലെ കോഡ് വളരെ വ്യത്യസ്തമായ രീതിയിൽ എഴുതാം.

എന്ത് പോയിരിക്കും അതുപോലെ? എന്നിരുന്നാലും, കാര്യങ്ങൾ തിരക്കുകൂട്ടരുത്.
കമ്മിറ്റ് ഹിസ്റ്ററി ഉപയോഗിച്ച് സംഭവിക്കുന്നതെല്ലാം ട്രാക്ക് ചെയ്യാൻ കഴിയും.

ഒരു പരിചയക്കാരൻ ജൂലൈ 27 ന് ഒരു ശേഖരം സൃഷ്ടിച്ചു, പക്ഷേ മറ്റൊന്നും ചെയ്തില്ല, അതിനാൽ ഞാൻ കോഡ് എഴുതാൻ തുടങ്ങി.

ജൂലൈ ജൂലൈ

ചുരുക്കത്തിൽ: ഹബറിന്റെ ആർഎസ്എസ് ഫീഡിന്റെ പാഴ്‌സിംഗ് ഞാൻ എഴുതി.

• com.github.pureconfig ടൈപ്പ് സേഫ് കോൺഫിഗറുകൾ നേരിട്ട് കേസ് ക്ലാസുകളിലേക്ക് വായിക്കുന്നതിന് (ഇത് വളരെ സൗകര്യപ്രദമായി മാറി)
• scala-xml xml വായിക്കാൻ: തുടക്കത്തിൽ ഞാൻ rss ഫീഡിനായി സ്വന്തമായി നടപ്പിലാക്കാൻ ആഗ്രഹിച്ചിരുന്നതിനാൽ, rss ഫീഡ് xml ഫോർമാറ്റിൽ ആയതിനാൽ, ഞാൻ ഈ ലൈബ്രറി പാഴ്‌സിംഗിനായി ഉപയോഗിച്ചു. യഥാർത്ഥത്തിൽ, ആർഎസ്എസ് പാഴ്സിംഗും പ്രത്യക്ഷപ്പെട്ടു.
• scalatest പരിശോധനകൾക്കായി. ചെറിയ പ്രോജക്റ്റുകൾക്ക് പോലും, ടെസ്റ്റുകൾ എഴുതുന്നത് സമയം ലാഭിക്കുന്നു - ഉദാഹരണത്തിന്, xml പാഴ്സിംഗ് ഡീബഗ്ഗ് ചെയ്യുമ്പോൾ, അത് ഒരു ഫയലിലേക്ക് ഡൗൺലോഡ് ചെയ്യാനും ടെസ്റ്റുകൾ എഴുതാനും പിശകുകൾ തിരുത്താനും വളരെ എളുപ്പമാണ്. അസാധുവായ utf-8 പ്രതീകങ്ങളുള്ള ചില വിചിത്രമായ html പാഴ്‌സിംഗ് ഉപയോഗിച്ച് ഒരു ബഗ് പിന്നീട് പ്രത്യക്ഷപ്പെട്ടപ്പോൾ, അത് ഒരു ഫയലിൽ ഇടാനും ഒരു ടെസ്റ്റ് ചേർക്കാനും കൂടുതൽ സൗകര്യപ്രദമായി മാറി.
• അക്കയിൽ നിന്നുള്ള അഭിനേതാക്കൾ. വസ്തുനിഷ്ഠമായി, അവ ആവശ്യമില്ല, പക്ഷേ പ്രോജക്റ്റ് വിനോദത്തിനായി എഴുതിയതാണ്, അവ പരീക്ഷിക്കാൻ ഞാൻ ആഗ്രഹിച്ചു. തൽഫലമായി, എനിക്ക് ഇത് ഇഷ്ടപ്പെട്ടുവെന്ന് പറയാൻ ഞാൻ തയ്യാറാണ്. OOP എന്ന ആശയം മറുവശത്ത് നിന്ന് നോക്കാം - സന്ദേശങ്ങൾ കൈമാറുന്ന അഭിനേതാക്കളുണ്ട്. കൂടുതൽ രസകരമായ കാര്യം, സന്ദേശം വരാത്തതോ അല്ലെങ്കിൽ പ്രോസസ്സ് ചെയ്യപ്പെടാത്തതോ ആയ രീതിയിൽ നിങ്ങൾക്ക് കോഡ് എഴുതാം (കൂടാതെ വേണം) (സാധാരണയായി പറഞ്ഞാൽ, ഒരൊറ്റ കമ്പ്യൂട്ടറിൽ അക്കൗണ്ട് പ്രവർത്തിക്കുമ്പോൾ, സന്ദേശങ്ങൾ നഷ്‌ടപ്പെടരുത്). ആദ്യം ഞാൻ തലയിൽ മാന്തികുഴിയുണ്ടാക്കി, അഭിനേതാക്കൾ പരസ്പരം വരിക്കാരാകുന്ന കോഡിൽ ചവറ്റുകുട്ടകൾ ഉണ്ടായിരുന്നു, പക്ഷേ അവസാനം എനിക്ക് ലളിതവും മനോഹരവുമായ ഒരു വാസ്തുവിദ്യ കൊണ്ടുവരാൻ കഴിഞ്ഞു. ഓരോ നടന്റെയും ഉള്ളിലെ കോഡ് സിംഗിൾ-ത്രെഡായി കണക്കാക്കാം; ഒരു നടൻ ക്രാഷ് ചെയ്യുമ്പോൾ, അക്കാ അത് പുനരാരംഭിക്കുന്നു - ഫലം തികച്ചും തെറ്റ്-സഹിഷ്ണുതയുള്ള സംവിധാനമാണ്.

ആഗസ്റ്റ് ആഗസ്റ്റ്

ഞാൻ പദ്ധതിയിൽ ചേർത്തു scala-scrapper Habr-ൽ നിന്ന് html പേജുകൾ പാഴ്‌സ് ചെയ്യുന്നതിന് (ലേഖന റേറ്റിംഗ്, ബുക്ക്‌മാർക്കുകളുടെ എണ്ണം മുതലായവ പോലുള്ള വിവരങ്ങൾ പുറത്തെടുക്കാൻ).

ഒപ്പം പൂച്ചകളും. പാറയിൽ ഉള്ളവർ.

വിതരണം ചെയ്ത ഡാറ്റാബേസുകളെക്കുറിച്ചുള്ള ഒരു പുസ്തകം ഞാൻ വായിച്ചു, CRDT എന്ന ആശയം എനിക്ക് ഇഷ്ടപ്പെട്ടു (സംഘർഷരഹിതമായ പകർത്തിയ ഡാറ്റ തരം, https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type, ഹബ്ർ), അതിനാൽ ഹബ്രെയെക്കുറിച്ചുള്ള ലേഖനത്തെക്കുറിച്ചുള്ള വിവരങ്ങൾക്കായി ഞാൻ ഒരു കമ്മ്യൂട്ടേറ്റീവ് സെമിഗ്രൂപ്പിന്റെ ഒരു തരം ക്ലാസ് പോസ്റ്റ് ചെയ്തു.

വാസ്തവത്തിൽ, ആശയം വളരെ ലളിതമാണ് - നമുക്ക് ഏകതാനമായി മാറുന്ന കൗണ്ടറുകൾ ഉണ്ട്. പ്ലസുകളുടെ എണ്ണം (അതുപോലെ മൈനസുകളുടെ എണ്ണം) പോലെ പ്രൊമോഷനുകളുടെ എണ്ണം ക്രമേണ വളരുകയാണ്. ഒരു ലേഖനത്തെക്കുറിച്ചുള്ള വിവരങ്ങളുടെ രണ്ട് പതിപ്പുകൾ എനിക്കുണ്ടെങ്കിൽ, എനിക്ക് "അവയെ ഒന്നായി ലയിപ്പിക്കാൻ" കഴിയും - വലിയ കൗണ്ടറിന്റെ അവസ്ഥ കൂടുതൽ പ്രസക്തമായി കണക്കാക്കപ്പെടുന്നു.

ഒരു അർദ്ധഗ്രൂപ്പ് എന്നാൽ ഒരു ലേഖനത്തെക്കുറിച്ചുള്ള വിവരങ്ങളുള്ള രണ്ട് ഒബ്ജക്റ്റുകൾ ഒന്നായി ലയിപ്പിക്കാൻ കഴിയും എന്നാണ്. കമ്യൂട്ടേറ്റീവ് എന്നാൽ നിങ്ങൾക്ക് A + B, B + A എന്നിവ ലയിപ്പിക്കാൻ കഴിയും, ഫലം ഓർഡറിനെ ആശ്രയിക്കുന്നില്ല, അവസാനം ഏറ്റവും പുതിയ പതിപ്പ് നിലനിൽക്കും. വഴിയിൽ, ഇവിടെ അസോസിയേറ്റിവിറ്റിയും ഉണ്ട്.

ഉദാഹരണത്തിന്, ആസൂത്രണം ചെയ്‌തതുപോലെ, ലേഖനത്തെക്കുറിച്ചുള്ള അൽപ്പം ദുർബലമായ വിവരങ്ങൾ - കാഴ്‌ചകളുടെ എണ്ണം പോലുള്ള മെട്രിക്‌സ് ഇല്ലാതെ - പാഴ്‌സിംഗിന് ശേഷമുള്ള rss. ഒരു പ്രത്യേക നടൻ ലേഖനങ്ങളെക്കുറിച്ചുള്ള വിവരങ്ങൾ എടുക്കുകയും അത് അപ്‌ഡേറ്റ് ചെയ്യാനും പഴയ പതിപ്പുമായി ലയിപ്പിക്കാനും html പേജുകളിലേക്ക് ഓടി.

പൊതുവായി പറഞ്ഞാൽ, അക്കയെപ്പോലെ, ഇതിന്റെ ആവശ്യമില്ല, നിങ്ങൾക്ക് ലേഖനത്തിനായുള്ള അപ്‌ഡേറ്റ് ഡേറ്റ് സംഭരിച്ച് ലയനമില്ലാതെ പുതിയത് എടുക്കാം, പക്ഷേ സാഹസികതയുടെ പാത എന്നെ നയിച്ചു.

ആഗസ്റ്റ് ആഗസ്റ്റ്

എനിക്ക് കൂടുതൽ സ്വാതന്ത്ര്യം തോന്നിത്തുടങ്ങി, വിനോദത്തിനായി, ഞാൻ ഓരോ ചാറ്റിനെയും ഒരു പ്രത്യേക അഭിനേതാവാക്കി. സൈദ്ധാന്തികമായി, ഒരു നടന് തന്നെ ഏകദേശം 300 ബൈറ്റുകൾ ഭാരമുണ്ട്, അവ ദശലക്ഷക്കണക്കിന് സൃഷ്ടിക്കാൻ കഴിയും, അതിനാൽ ഇത് തികച്ചും സാധാരണമായ ഒരു സമീപനമാണ്. പരിഹാരം വളരെ രസകരമായി മാറിയെന്ന് എനിക്ക് തോന്നുന്നു:

അക്കയിലെ ടെലിഗ്രാം സെർവറിനും സന്ദേശ സംവിധാനത്തിനും ഇടയിലുള്ള ഒരു പാലമായിരുന്നു ഒരു നടൻ. അയാൾക്ക് സന്ദേശങ്ങൾ ലഭിക്കുകയും അവ ആവശ്യമുള്ള ചാറ്റ് നടന് അയയ്ക്കുകയും ചെയ്തു. ചാറ്റ് നടന് പ്രതികരണമായി എന്തെങ്കിലും തിരികെ അയയ്ക്കാൻ കഴിയും - അത് ടെലിഗ്രാമിലേക്ക് തിരികെ അയയ്‌ക്കും. വളരെ സൗകര്യപ്രദമായ കാര്യം, ഈ നടൻ കഴിയുന്നത്ര ലളിതമായി മാറി, സന്ദേശങ്ങളോട് പ്രതികരിക്കുന്നതിനുള്ള യുക്തി മാത്രം ഉൾക്കൊള്ളുന്നു. വഴിയിൽ, പുതിയ ലേഖനങ്ങളെക്കുറിച്ചുള്ള വിവരങ്ങൾ എല്ലാ ചാറ്റിലും വന്നു, എന്നാൽ വീണ്ടും ഞാൻ ഇതിൽ പ്രശ്നങ്ങളൊന്നും കാണുന്നില്ല.

പൊതുവേ, ബോട്ട് ഇതിനകം തന്നെ പ്രവർത്തിക്കുന്നു, സന്ദേശങ്ങളോട് പ്രതികരിക്കുന്നു, ഉപയോക്താവിന് അയച്ച ലേഖനങ്ങളുടെ ഒരു ലിസ്റ്റ് സംഭരിക്കുന്നു, ബോട്ട് ഏകദേശം തയ്യാറാണെന്ന് ഞാൻ ഇതിനകം ചിന്തിച്ചിരുന്നു. രചയിതാവിന്റെ പേരുകളും ടാഗുകളും നോർമലൈസ് ചെയ്യുന്നതുപോലുള്ള ചെറിയ ഫീച്ചറുകൾ ഞാൻ പതുക്കെ ചേർത്തു (“s.d f” എന്നതിന് പകരം “s_d_f”).

ഒരു കാര്യം മാത്രം അവശേഷിച്ചു ചെറുതെങ്കിലും - സംസ്ഥാനം എവിടെയും രക്ഷപ്പെട്ടില്ല.

എല്ലാം തെറ്റി

ബോട്ട് കൂടുതലും ഞാൻ ഒറ്റയ്ക്കാണ് എഴുതിയതെന്ന് നിങ്ങൾ ശ്രദ്ധിച്ചിരിക്കാം. അതിനാൽ, രണ്ടാമത്തെ പങ്കാളി വികസനത്തിൽ ഏർപ്പെട്ടു, ഇനിപ്പറയുന്ന മാറ്റങ്ങൾ കോഡിൽ പ്രത്യക്ഷപ്പെട്ടു:

• മോംഗോഡിബി സംസ്ഥാനം സംഭരിക്കാൻ പ്രത്യക്ഷപ്പെട്ടു. അതേ സമയം, പ്രോജക്റ്റിലെ ലോഗുകൾ തകർന്നു, കാരണം ചില കാരണങ്ങളാൽ മോംഗ അവ സ്പാം ചെയ്യാൻ തുടങ്ങി, ചില ആളുകൾ അവ ആഗോളതലത്തിൽ ഓഫാക്കി.
• ടെലിഗ്രാമിലെ ബ്രിഡ്ജ് നടൻ തിരിച്ചറിയാൻ കഴിയാത്തവിധം രൂപാന്തരപ്പെടുകയും സന്ദേശങ്ങൾ സ്വയം പാഴ്‌സ് ചെയ്യാൻ തുടങ്ങുകയും ചെയ്തു.
• ചാറ്റുകൾക്കായുള്ള അഭിനേതാക്കളെ നിഷ്കരുണം വെട്ടിമാറ്റി, പകരം എല്ലാ ചാറ്റുകളെക്കുറിച്ചുള്ള എല്ലാ വിവരങ്ങളും ഒരേസമയം മറച്ചുവെച്ച ഒരു നടനെ അവർ മാറ്റി. ഓരോ തുമ്മലിനും ഈ നടൻ കുഴപ്പത്തിലായി. ശരി, അതെ, ഒരു ലേഖനത്തെക്കുറിച്ചുള്ള വിവരങ്ങൾ അപ്‌ഡേറ്റ് ചെയ്യുമ്പോൾ, അത് എല്ലാ ചാറ്റ് അഭിനേതാക്കൾക്കും അയയ്ക്കുന്നത് ബുദ്ധിമുട്ടാണ് (ഞങ്ങൾ Google-നെ പോലെയാണ്, ദശലക്ഷക്കണക്കിന് ഉപയോക്താക്കൾ ഓരോന്നിനും വേണ്ടി ചാറ്റിൽ ഒരു ദശലക്ഷം ലേഖനങ്ങൾക്കായി കാത്തിരിക്കുന്നു), എന്നാൽ ഓരോ തവണയും ചാറ്റ് അപ്‌ഡേറ്റ് ചെയ്യപ്പെടുന്നു, മോംഗയിലേക്ക് പോകുന്നത് സാധാരണമാണ്. വളരെക്കാലം കഴിഞ്ഞ് ഞാൻ മനസ്സിലാക്കിയതുപോലെ, ചാറ്റുകളുടെ പ്രവർത്തന ലോജിക്കും പൂർണ്ണമായും വെട്ടിമാറ്റി, അതിന്റെ സ്ഥാനത്ത് പ്രവർത്തിക്കാത്ത എന്തെങ്കിലും പ്രത്യക്ഷപ്പെട്ടു.
• തരം ക്ലാസുകളുടെ ഒരു സൂചനയും അവശേഷിക്കുന്നില്ല.
• അന്യോന്യം സബ്‌സ്‌ക്രിപ്‌ഷനുള്ള അഭിനേതാക്കളിൽ അനാരോഗ്യകരമായ ചില യുക്തികൾ പ്രത്യക്ഷപ്പെട്ടു, ഇത് ഒരു വംശീയ അവസ്ഥയിലേക്ക് നയിക്കുന്നു.
• തരം ഫീൽഡുകളുള്ള ഡാറ്റാ ഘടനകൾ Option[Int] -1 പോലുള്ള മാന്ത്രിക ഡിഫോൾട്ട് മൂല്യങ്ങൾ ഉപയോഗിച്ച് Int ആയി മാറി. mongoDB json ആണ് സംഭരിക്കുന്നതെന്നും അത് അവിടെ സൂക്ഷിക്കുന്നതിൽ തെറ്റില്ലെന്നും പിന്നീട് മനസ്സിലായി Option ശരി, അല്ലെങ്കിൽ കുറഞ്ഞത് -1 ഒന്നുമില്ല എന്ന് പാഴ്‌സ് ചെയ്യുക, പക്ഷേ ആ സമയത്ത് എനിക്ക് ഇത് അറിയില്ലായിരുന്നു, കൂടാതെ "അങ്ങനെയായിരിക്കണം" എന്ന എന്റെ വാക്ക് ഞാൻ സ്വീകരിച്ചു. ഞാൻ ആ കോഡ് എഴുതിയിട്ടില്ല, തൽക്കാലം അത് മാറ്റാൻ ഞാൻ വിഷമിച്ചില്ല.
• എന്റെ പൊതു ഐപി വിലാസം മാറിക്കൊണ്ടിരിക്കുന്നതായി ഞാൻ കണ്ടെത്തി, ഓരോ തവണയും എനിക്ക് അത് മോംഗോയുടെ വൈറ്റ്‌ലിസ്റ്റിലേക്ക് ചേർക്കേണ്ടി വന്നു. ഞാൻ പ്രാദേശികമായി ബോട്ട് സമാരംഭിച്ചു, മോംഗ ഒരു കമ്പനിയായി മോംഗയുടെ സെർവറുകളിൽ എവിടെയോ ഉണ്ടായിരുന്നു.
• പെട്ടെന്ന്, ടെലിഗ്രാമുകൾക്കായുള്ള ടാഗുകളുടെയും സന്ദേശ ഫോർമാറ്റിംഗിന്റെയും സാധാരണവൽക്കരണം അപ്രത്യക്ഷമായി. (ഹും, അത് എന്തിനായിരിക്കും?)
• ബോട്ടിന്റെ അവസ്ഥ ഒരു ബാഹ്യ ഡാറ്റാബേസിൽ സംഭരിച്ചിരിക്കുന്നത് എനിക്ക് ഇഷ്ടപ്പെട്ടു, പുനരാരംഭിക്കുമ്പോൾ ഒന്നും സംഭവിക്കാത്തത് പോലെ അത് പ്രവർത്തിക്കുന്നത് തുടരുന്നു. എന്നിരുന്നാലും, ഇത് ഒരേയൊരു പ്ലസ് ആയിരുന്നു.

രണ്ടാമത്തെ വ്യക്തിക്ക് പ്രത്യേകിച്ച് തിരക്കില്ല, ഈ മാറ്റങ്ങളെല്ലാം സെപ്റ്റംബർ തുടക്കത്തിൽ തന്നെ ഒരു വലിയ കൂമ്പാരത്തിൽ പ്രത്യക്ഷപ്പെട്ടു. തത്ഫലമായുണ്ടാകുന്ന നാശത്തിന്റെ തോത് ഞാൻ ഉടനടി വിലമതിച്ചില്ല, കൂടാതെ ഡാറ്റാബേസിന്റെ പ്രവർത്തനം മനസിലാക്കാൻ തുടങ്ങി, കാരണം ... ഞാൻ ഇതുവരെ അവരോട് ഇടപെട്ടിട്ടില്ല. പിന്നീടാണ് എനിക്ക് മനസ്സിലായത്, എത്ര വർക്കിംഗ് കോഡ് കട്ട് ചെയ്തുവെന്നും അതിന്റെ സ്ഥാനത്ത് എത്ര ബഗുകൾ ചേർത്തുവെന്നും.

സെപ്തംബർ

മോംഗയെ മാസ്റ്റർ ചെയ്ത് നന്നായി ചെയ്താൽ ഉപകാരപ്പെടുമെന്നാണ് ആദ്യം കരുതിയത്. ഡാറ്റാബേസ് ഉപയോഗിച്ച് ആശയവിനിമയം സംഘടിപ്പിക്കുന്നതും നിങ്ങൾക്ക് ധാരാളം മത്സരങ്ങൾ നടത്താനും തെറ്റുകൾ വരുത്താനും കഴിയുന്ന ഒരു കലയാണെന്ന് ഞാൻ പതുക്കെ മനസ്സിലാക്കാൻ തുടങ്ങി. ഉദാഹരണത്തിന്, ഉപയോക്താവിന് രണ്ട് സന്ദേശങ്ങൾ ലഭിക്കുകയാണെങ്കിൽ /subscribe - കൂടാതെ ഓരോന്നിനും പ്രതികരണമായി ഞങ്ങൾ പട്ടികയിൽ ഒരു എൻട്രി സൃഷ്ടിക്കും, കാരണം ആ സന്ദേശങ്ങൾ പ്രോസസ്സ് ചെയ്യുന്ന സമയത്ത് ഉപയോക്താവ് സബ്‌സ്‌ക്രൈബ് ചെയ്തിട്ടില്ല. മോംഗയുമായുള്ള ആശയവിനിമയം അതിന്റെ നിലവിലെ രൂപത്തിൽ മികച്ച രീതിയിൽ എഴുതിയിട്ടില്ലെന്ന് എനിക്ക് സംശയമുണ്ട്. ഉദാഹരണത്തിന്, ഉപയോക്താവിന്റെ ക്രമീകരണങ്ങൾ അവൻ സൈൻ അപ്പ് ചെയ്‌ത നിമിഷത്തിൽ സൃഷ്‌ടിച്ചതാണ്. സബ്‌സ്‌ക്രിപ്‌ഷന്റെ വസ്തുതയ്‌ക്ക് മുമ്പ് അവ മാറ്റാൻ ശ്രമിച്ചാൽ ... ബോട്ട് ഒന്നും പ്രതികരിച്ചില്ല, കാരണം നടനിലെ കോഡ് ക്രമീകരണങ്ങൾക്കായി ഡാറ്റാബേസിലേക്ക് പോയി, അത് കണ്ടെത്താതെ തകർന്നു. എന്തുകൊണ്ട് ആവശ്യാനുസരണം സെറ്റിംഗ്‌സ് സൃഷ്‌ടിക്കരുത് എന്ന് ചോദിച്ചപ്പോൾ, ഉപയോക്താവ് സബ്‌സ്‌ക്രൈബ് ചെയ്തിട്ടില്ലെങ്കിൽ അവ മാറ്റേണ്ട ആവശ്യമില്ലെന്ന് ഞാൻ മനസ്സിലാക്കി... മെസേജ് ഫിൽട്ടറിംഗ് സിസ്റ്റം എങ്ങനെയെങ്കിലും വ്യക്തമല്ലാത്ത രീതിയിൽ ഉണ്ടാക്കിയതാണ്, കൂടാതെ കോഡ് സൂക്ഷ്മമായി പരിശോധിച്ചതിന് ശേഷവും എനിക്ക് കഴിഞ്ഞു. ഇത് ആദ്യം ഈ രീതിയിൽ ഉദ്ദേശിച്ചിരുന്നോ അതോ അവിടെ ഒരു പിശക് ഉണ്ടോ എന്ന് മനസ്സിലാകുന്നില്ല.

ചാറ്റിൽ സമർപ്പിച്ച ലേഖനങ്ങളുടെ ഒരു ലിസ്‌റ്റും ഉണ്ടായിരുന്നില്ല; പകരം, അവ സ്വയം എഴുതാൻ നിർദ്ദേശിച്ചു. ഇത് എന്നെ ആശ്ചര്യപ്പെടുത്തി - പൊതുവേ, എല്ലാത്തരം കാര്യങ്ങളും പ്രോജക്റ്റിലേക്ക് വലിച്ചിടുന്നതിന് ഞാൻ എതിരല്ല, പക്ഷേ ഈ കാര്യങ്ങൾ കൊണ്ടുവന്ന് അവ സ്ക്രൂ ചെയ്തയാൾക്ക് ഇത് യുക്തിസഹമായിരിക്കും. എന്നാൽ ഇല്ല, രണ്ടാമത്തെ പങ്കാളി എല്ലാം ഉപേക്ഷിക്കുന്നതായി തോന്നുന്നു, പക്ഷേ ചാറ്റിനുള്ളിലെ ലിസ്റ്റ് ഒരു മോശം പരിഹാരമാണെന്ന് കരുതപ്പെടുന്നു, കൂടാതെ "ഒരു ലേഖനം y ഉപയോക്താവിന് x അയച്ചു" പോലുള്ള ഇവന്റുകൾ ഉപയോഗിച്ച് ഒരു അടയാളം ഉണ്ടാക്കേണ്ടത് അത്യാവശ്യമാണെന്നും പറഞ്ഞു. തുടർന്ന്, ഉപയോക്താവ് പുതിയ ലേഖനങ്ങൾ അയയ്‌ക്കാൻ അഭ്യർത്ഥിച്ചാൽ, ഡാറ്റാബേസിലേക്ക് ഒരു അഭ്യർത്ഥന അയയ്‌ക്കേണ്ടത് ആവശ്യമാണ്, അത് ഇവന്റുകളിൽ നിന്ന് ഉപയോക്താവുമായി ബന്ധപ്പെട്ട ഇവന്റുകൾ തിരഞ്ഞെടുക്കുകയും പുതിയ ലേഖനങ്ങളുടെ ഒരു ലിസ്റ്റ് നേടുകയും അവ ഫിൽട്ടർ ചെയ്യുകയും ഉപയോക്താവിന് അയയ്ക്കുകയും ചെയ്യും. ഇതിനെക്കുറിച്ചുള്ള ഇവന്റുകൾ ഡാറ്റാബേസിലേക്ക് തിരികെ എറിയുക.

രണ്ടാമത്തെ പങ്കാളിയെ അമൂർത്തതകളിലേക്ക് എവിടെയെങ്കിലും കൊണ്ടുപോയി, ബോട്ടിന് ഹബറിൽ നിന്ന് ലേഖനങ്ങൾ മാത്രമല്ല ലഭിക്കുകയും ടെലിഗ്രാമിലേക്ക് മാത്രമല്ല അയയ്ക്കുകയും ചെയ്യും.

സെപ്തംബർ രണ്ടാം പകുതിയിൽ ഒരു പ്രത്യേക ചിഹ്നത്തിന്റെ രൂപത്തിൽ ഞാൻ എങ്ങനെയെങ്കിലും ഇവന്റുകൾ നടപ്പിലാക്കി. ഇത് ഒപ്റ്റിമൽ അല്ല, പക്ഷേ കുറഞ്ഞത് ബോട്ട് പ്രവർത്തിക്കാൻ തുടങ്ങി, എനിക്ക് വീണ്ടും ലേഖനങ്ങൾ അയയ്ക്കാൻ തുടങ്ങി, കോഡിൽ എന്താണ് സംഭവിക്കുന്നതെന്ന് ഞാൻ പതുക്കെ കണ്ടെത്തി.

ഇപ്പോൾ നിങ്ങൾക്ക് തുടക്കത്തിലേക്ക് മടങ്ങാം, ശേഖരം യഥാർത്ഥത്തിൽ ഞാൻ സൃഷ്ടിച്ചതല്ലെന്ന് ഓർക്കുക. എന്തായിരിക്കാം ഇങ്ങനെ പോയത്? എന്റെ പിൻവലിക്കൽ അഭ്യർത്ഥന നിരസിക്കപ്പെട്ടു. എനിക്ക് റെഡ്‌നെക്ക് കോഡ് ഉണ്ടെന്നും ഒരു ടീമിൽ എങ്ങനെ പ്രവർത്തിക്കണമെന്ന് എനിക്കറിയില്ലെന്നും നിലവിലെ നടപ്പാക്കൽ കർവിലെ ബഗുകൾ പരിഹരിക്കേണ്ടതുണ്ടെന്നും അത് ഉപയോഗയോഗ്യമായ അവസ്ഥയിലേക്ക് പരിഷ്‌ക്കരിക്കരുതെന്നും മനസ്സിലായി.

ഞാൻ അസ്വസ്ഥനായി, കമ്മിറ്റ് ഹിസ്റ്ററിയും എഴുതിയ കോഡിന്റെ അളവും നോക്കി. ആദ്യം നന്നായി എഴുതിയതും പിന്നീട് തകർന്നതുമായ നിമിഷങ്ങളിലേക്ക് ഞാൻ നോക്കി...

F*rk it

ഞാൻ ലേഖനം ഓർത്തു നിങ്ങൾ Google അല്ല.

നടപ്പാക്കാതെ ആർക്കും ഒരു ആശയവും ആവശ്യമില്ലെന്ന് ഞാൻ കരുതി. ഒരു വർക്കിംഗ് ബോട്ട് വേണമെന്ന് ഞാൻ കരുതി, അത് ഒരു കമ്പ്യൂട്ടറിൽ ഒരു സിംപിൾ ജാവ പ്രോഗ്രാമായി ഒറ്റ പകർപ്പിൽ പ്രവർത്തിക്കും. പുനരാരംഭിക്കാതെ മാസങ്ങളോളം എന്റെ ബോട്ട് പ്രവർത്തിക്കുമെന്ന് എനിക്കറിയാം, കാരണം ഞാൻ മുമ്പ് അത്തരം ബോട്ടുകൾ എഴുതിയിട്ടുണ്ട്. അത് പെട്ടെന്ന് വീഴുകയും ഉപയോക്താവിന് മറ്റൊരു ലേഖനം അയയ്ക്കാതിരിക്കുകയും ചെയ്താൽ, ആകാശം നിലത്ത് വീഴില്ല, ദുരന്തം ഒന്നും സംഭവിക്കില്ല.

കോഡ് പ്രവർത്തിക്കുന്നില്ലെങ്കിൽ അല്ലെങ്കിൽ വക്രമായി പ്രവർത്തിക്കുന്നുണ്ടെങ്കിൽ എനിക്ക് എന്തിനാണ് ഡോക്കറും മോംഗോഡിബിയും മറ്റ് "ഗുരുതരമായ" സോഫ്റ്റ്‌വെയറിന്റെ മറ്റ് കാർഗോ കൾട്ടും വേണ്ടത്?

ഞാൻ പ്രോജക്റ്റ് ഉപേക്ഷിച്ചു, ഞാൻ ആഗ്രഹിച്ചതുപോലെ എല്ലാം ചെയ്തു.

ഏതാണ്ട് അതേ സമയം, ഞാൻ ജോലി മാറി, ഒഴിവു സമയം വളരെ കുറവായി. രാവിലെ ഞാൻ ട്രെയിനിൽ തന്നെ ഉണർന്നു, വൈകുന്നേരം ഞാൻ വൈകി മടങ്ങി, ഇനി ഒന്നും ചെയ്യാൻ ആഗ്രഹിച്ചില്ല. ഞാൻ കുറച്ച് സമയത്തേക്ക് ഒന്നും ചെയ്തില്ല, പിന്നെ ബോട്ട് പൂർത്തിയാക്കാനുള്ള ആഗ്രഹം എന്നെ കീഴടക്കി, രാവിലെ ജോലിക്ക് പോകുമ്പോൾ ഞാൻ കോഡ് പതുക്കെ വീണ്ടും എഴുതാൻ തുടങ്ങി. ഇത് ഉൽപ്പാദനക്ഷമമാണെന്ന് ഞാൻ പറയില്ല: നിങ്ങളുടെ മടിയിൽ ലാപ്‌ടോപ്പുമായി കുലുങ്ങുന്ന ട്രെയിനിൽ ഇരിക്കുന്നതും നിങ്ങളുടെ ഫോണിൽ നിന്നുള്ള സ്റ്റാക്ക് ഓവർഫ്ലോ നോക്കുന്നതും വളരെ സൗകര്യപ്രദമല്ല. എന്നിരുന്നാലും, കോഡ് എഴുതാൻ ചെലവഴിച്ച സമയം പൂർണ്ണമായും ശ്രദ്ധിക്കപ്പെടാതെ പറന്നു, പ്രോജക്റ്റ് പതുക്കെ പ്രവർത്തന നിലയിലേക്ക് നീങ്ങാൻ തുടങ്ങി.

എന്റെ മനസ്സിന്റെ പിന്നിൽ എവിടെയോ മോംഗോഡിബി ഉപയോഗിക്കാൻ ആഗ്രഹിക്കുന്ന ഒരു സംശയത്തിന്റെ പുഴു ഉണ്ടായിരുന്നു, പക്ഷേ “വിശ്വസനീയമായ” സംസ്ഥാന സംഭരണത്തിന്റെ ഗുണങ്ങൾക്ക് പുറമേ, ശ്രദ്ധേയമായ ദോഷങ്ങളുമുണ്ടെന്ന് ഞാൻ കരുതി:

• ഡാറ്റാബേസ് പരാജയത്തിന്റെ മറ്റൊരു പോയിന്റായി മാറുന്നു.
• കോഡ് കൂടുതൽ സങ്കീർണ്ണമായിക്കൊണ്ടിരിക്കുകയാണ്, അത് എഴുതാൻ എനിക്ക് കൂടുതൽ സമയമെടുക്കും.
• കോഡ് മന്ദഗതിയിലുള്ളതും കാര്യക്ഷമമല്ലാത്തതുമായിത്തീരുന്നു; മെമ്മറിയിൽ ഒരു ഒബ്ജക്റ്റ് മാറ്റുന്നതിനുപകരം, മാറ്റങ്ങൾ ഡാറ്റാബേസിലേക്ക് അയയ്ക്കുകയും ആവശ്യമെങ്കിൽ പിന്നോട്ട് വലിക്കുകയും ചെയ്യുന്നു.
• ഒരു പ്രത്യേക പട്ടികയിൽ ഇവന്റുകളുടെ സംഭരണത്തിന്റെ തരത്തിൽ നിയന്ത്രണങ്ങളുണ്ട്, അവ ഡാറ്റാബേസിന്റെ പ്രത്യേകതകളുമായി ബന്ധപ്പെട്ടിരിക്കുന്നു.
• മോംഗയുടെ ട്രയൽ പതിപ്പിന് ചില പരിമിതികളുണ്ട്, നിങ്ങൾ അവയിലേക്ക് ഓടിക്കുകയാണെങ്കിൽ, നിങ്ങൾ മോംഗയെ എന്തെങ്കിലും ലോഞ്ച് ചെയ്യുകയും കോൺഫിഗർ ചെയ്യുകയും വേണം.

ഞാൻ മോംഗ മുറിച്ചുമാറ്റി, ഇപ്പോൾ ബോട്ടിന്റെ അവസ്ഥ പ്രോഗ്രാമിന്റെ മെമ്മറിയിൽ സംഭരിക്കുകയും കാലാകാലങ്ങളിൽ json രൂപത്തിൽ ഒരു ഫയലിലേക്ക് സംരക്ഷിക്കുകയും ചെയ്യുന്നു. ഒരുപക്ഷേ അഭിപ്രായങ്ങളിൽ ഞാൻ തെറ്റാണെന്ന് അവർ എഴുതും, ഇവിടെയാണ് ഡാറ്റാബേസ് ഉപയോഗിക്കേണ്ടത് മുതലായവ. എന്നാൽ ഇത് എന്റെ പദ്ധതിയാണ്, ഫയലുമായുള്ള സമീപനം കഴിയുന്നത്ര ലളിതവും സുതാര്യമായ രീതിയിൽ പ്രവർത്തിക്കുന്നതുമാണ്.

-1 പോലുള്ള മാന്ത്രിക മൂല്യങ്ങൾ വലിച്ചെറിഞ്ഞ് സാധാരണ മൂല്യങ്ങൾ തിരികെ നൽകി Option, ചാറ്റ് വിവരങ്ങളുള്ള ഒബ്‌ജക്‌റ്റിലേക്ക് അയച്ച ലേഖനങ്ങളുള്ള ഒരു ഹാഷ് ടേബിളിന്റെ സംഭരണം ചേർത്തു. അഞ്ച് ദിവസത്തിലധികം പഴക്കമുള്ള ലേഖനങ്ങളെക്കുറിച്ചുള്ള വിവരങ്ങൾ ഇല്ലാതാക്കുന്നത് ചേർത്തു, അങ്ങനെ എല്ലാം സംഭരിക്കരുത്. ഞാൻ ലോഗിംഗ് ഒരു പ്രവർത്തന നിലയിലേക്ക് കൊണ്ടുവന്നു - ഫയലിലും കൺസോളിലും ലോഗുകൾ ന്യായമായ അളവിൽ എഴുതിയിരിക്കുന്നു. സംസ്ഥാനം സംരക്ഷിക്കുക അല്ലെങ്കിൽ ഉപയോക്താക്കളുടെയും ലേഖനങ്ങളുടെയും എണ്ണം പോലുള്ള സ്ഥിതിവിവരക്കണക്കുകൾ നേടുന്നത് പോലുള്ള നിരവധി അഡ്മിൻ കമാൻഡുകൾ ചേർത്തു.

ചെറിയ കാര്യങ്ങളുടെ ഒരു കൂട്ടം പരിഹരിച്ചു: ഉദാഹരണത്തിന്, ലേഖനങ്ങൾക്കായി, ഉപയോക്താവിന്റെ ഫിൽട്ടർ കടന്നുപോകുന്ന സമയത്തെ കാഴ്ചകൾ, ലൈക്കുകൾ, ഡിസ്‌ലൈക്കുകൾ, അഭിപ്രായങ്ങൾ എന്നിവയുടെ എണ്ണം ഇപ്പോൾ സൂചിപ്പിച്ചിരിക്കുന്നു. പൊതുവേ, എത്ര ചെറിയ കാര്യങ്ങൾ തിരുത്തേണ്ടി വന്നു എന്നത് ആശ്ചര്യകരമാണ്. ഞാൻ ഒരു ലിസ്റ്റ് സൂക്ഷിച്ചു, അവിടെയുള്ള എല്ലാ "ക്രമക്കേടുകളും" ശ്രദ്ധിക്കുകയും കഴിയുന്നിടത്തോളം അവ ശരിയാക്കുകയും ചെയ്തു.

ഉദാഹരണത്തിന്, ഒരു സന്ദേശത്തിൽ എല്ലാ ക്രമീകരണങ്ങളും നേരിട്ട് സജ്ജീകരിക്കാനുള്ള കഴിവ് ഞാൻ ചേർത്തു:

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

ഒപ്പം മറ്റൊരു ടീമും /settings ഈ രൂപത്തിൽ അവ കൃത്യമായി പ്രദർശിപ്പിക്കുന്നു, നിങ്ങൾക്ക് അതിൽ നിന്ന് വാചകം എടുത്ത് എല്ലാ ക്രമീകരണങ്ങളും ഒരു സുഹൃത്തിന് അയയ്ക്കാം.
ഇത് ഒരു ചെറിയ കാര്യമാണെന്ന് തോന്നുന്നു, പക്ഷേ സമാനമായ ഡസൻ കണക്കിന് സൂക്ഷ്മതകളുണ്ട്.

ലളിതമായ ലീനിയർ മോഡലിന്റെ രൂപത്തിൽ ലേഖനം ഫിൽട്ടറിംഗ് നടപ്പിലാക്കി - ഉപയോക്താവിന് രചയിതാക്കൾക്കും ടാഗുകൾക്കുമായി ഒരു അധിക റേറ്റിംഗും അതുപോലെ തന്നെ ഒരു പരിധി മൂല്യവും സജ്ജമാക്കാൻ കഴിയും. രചയിതാവിന്റെ റേറ്റിംഗിന്റെ ആകെത്തുക, ടാഗുകളുടെ ശരാശരി റേറ്റിംഗ്, ലേഖനത്തിന്റെ യഥാർത്ഥ റേറ്റിംഗ് എന്നിവ ത്രെഷോൾഡ് മൂല്യത്തേക്കാൾ കൂടുതലാണെങ്കിൽ, ലേഖനം ഉപയോക്താവിനെ കാണിക്കും. നിങ്ങൾക്ക് ഒന്നുകിൽ ബോട്ടിനോട് /പുതിയ കമാൻഡ് ഉപയോഗിച്ച് ലേഖനങ്ങൾ ആവശ്യപ്പെടാം, അല്ലെങ്കിൽ ബോട്ട് സബ്‌സ്‌ക്രൈബുചെയ്യുക, അത് ദിവസത്തിലെ ഏത് സമയത്തും ഒരു വ്യക്തിഗത സന്ദേശത്തിൽ ലേഖനങ്ങൾ അയയ്‌ക്കും.

പൊതുവായി പറഞ്ഞാൽ, ഓരോ ലേഖനത്തിനും കൂടുതൽ ഫീച്ചറുകൾ (ഹബുകൾ, കമന്റുകളുടെ എണ്ണം, ബുക്ക്‌മാർക്കുകൾ, റേറ്റിംഗ് മാറ്റങ്ങളുടെ ചലനാത്മകത, വാചകത്തിന്റെ അളവ്, ലേഖനത്തിലെ ചിത്രങ്ങളും കോഡുകളും, കീവേഡുകളും) പുറത്തെടുക്കാനും ഉപയോക്താവിനെ ശരി കാണിക്കാനും എനിക്ക് ഒരു ആശയം ഉണ്ടായിരുന്നു/ ശരിയല്ല, ഓരോ ലേഖനത്തിനും കീഴിൽ വോട്ട് ചെയ്യുകയും ഓരോ ഉപയോക്താവിനും ഒരു മാതൃക പരിശീലിപ്പിക്കുകയും ചെയ്യുക, പക്ഷേ ഞാൻ വളരെ മടിയനായിരുന്നു.

കൂടാതെ, ജോലിയുടെ യുക്തി അത്ര വ്യക്തമാകില്ല. ഇപ്പോൾ എനിക്ക് പേഷ്യന്റ് സീറോയ്‌ക്ക് +9000 റേറ്റിംഗ് സ്വമേധയാ സജ്ജീകരിക്കാൻ കഴിയും കൂടാതെ +20 എന്ന ത്രെഷോൾഡ് റേറ്റിംഗ് ഉപയോഗിച്ച് എനിക്ക് അദ്ദേഹത്തിന്റെ എല്ലാ ലേഖനങ്ങളും ലഭിക്കുമെന്ന് ഉറപ്പുനൽകുന്നു (തീർച്ചയായും, ഞാൻ ചില ടാഗുകൾക്ക് -100500 സജ്ജീകരിച്ചിട്ടില്ലെങ്കിൽ).

അവസാന വാസ്തുവിദ്യ വളരെ ലളിതമായി മാറി:

1. എല്ലാ ചാറ്റുകളുടെയും ലേഖനങ്ങളുടെയും അവസ്ഥ സംഭരിക്കുന്ന ഒരു നടൻ. ഇത് ഡിസ്കിലെ ഒരു ഫയലിൽ നിന്ന് അതിന്റെ അവസ്ഥ ലോഡ് ചെയ്യുകയും കാലാകാലങ്ങളിൽ ഓരോ തവണയും ഒരു പുതിയ ഫയലിലേക്ക് തിരികെ സംരക്ഷിക്കുകയും ചെയ്യുന്നു.
2. ആർഎസ്എസ് ഫീഡ് ഇടയ്ക്കിടെ സന്ദർശിക്കുകയും പുതിയ ലേഖനങ്ങളെ കുറിച്ച് പഠിക്കുകയും ലിങ്കുകൾ നോക്കുകയും പാഴ്‌സ് ചെയ്യുകയും ഈ ലേഖനങ്ങൾ ആദ്യത്തെ നടന് അയയ്ക്കുകയും ചെയ്യുന്ന ഒരു നടൻ. കൂടാതെ, ഇത് ചിലപ്പോൾ ആദ്യത്തെ നടനിൽ നിന്ന് ലേഖനങ്ങളുടെ ഒരു ലിസ്റ്റ് അഭ്യർത്ഥിക്കുകയും മൂന്ന് ദിവസത്തിൽ കൂടുതൽ പഴക്കമില്ലാത്തതും എന്നാൽ വളരെക്കാലമായി അപ്‌ഡേറ്റ് ചെയ്യാത്തതും തിരഞ്ഞെടുത്ത് അവ അപ്‌ഡേറ്റ് ചെയ്യുകയും ചെയ്യുന്നു.
3. ഒരു ടെലിഗ്രാം ഉപയോഗിച്ച് ആശയവിനിമയം നടത്തുന്ന ഒരു നടൻ. ഞാൻ ഇപ്പോഴും സന്ദേശം പാഴ്‌സിംഗ് പൂർണ്ണമായും ഇവിടെ കൊണ്ടുവന്നു. സൗഹാർദ്ദപരമായ രീതിയിൽ, അതിനെ രണ്ടായി വിഭജിക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു - അതിലൂടെ ഒരാൾ ഇൻകമിംഗ് സന്ദേശങ്ങൾ പാഴ്‌സ് ചെയ്യുന്നു, രണ്ടാമത്തേത് അയയ്‌ക്കാത്ത സന്ദേശങ്ങൾ വീണ്ടും അയയ്‌ക്കുന്നത് പോലുള്ള ഗതാഗത പ്രശ്‌നങ്ങൾ കൈകാര്യം ചെയ്യുന്നു. ഇപ്പോൾ വീണ്ടും അയയ്‌ക്കുന്നില്ല, ഒരു പിശക് കാരണം എത്താത്ത ഒരു സന്ദേശം നഷ്‌ടപ്പെടും (അത് ലോഗുകളിൽ രേഖപ്പെടുത്തിയിട്ടില്ലെങ്കിൽ), എന്നാൽ ഇതുവരെ ഇത് പ്രശ്‌നങ്ങളൊന്നും ഉണ്ടാക്കിയിട്ടില്ല. ഒരു കൂട്ടം ആളുകൾ ബോട്ട് സബ്‌സ്‌ക്രൈബുചെയ്യുകയും സന്ദേശങ്ങൾ അയയ്‌ക്കുന്നതിനുള്ള പരിധിയിൽ എത്തുകയും ചെയ്‌താൽ ഒരുപക്ഷേ പ്രശ്‌നങ്ങൾ ഉടലെടുക്കും).

2 ഉം 3 ഉം അഭിനേതാക്കളുടെ വീഴ്ചകൾ ബോട്ടിന്റെ പ്രകടനത്തെ പൊതുവെ ബാധിക്കാറില്ല എന്നതാണ് എനിക്ക് ഇഷ്ടപ്പെട്ടത്. ഒരുപക്ഷേ ചില ലേഖനങ്ങൾ കൃത്യസമയത്ത് അപ്‌ഡേറ്റ് ചെയ്തിട്ടില്ല അല്ലെങ്കിൽ ചില സന്ദേശങ്ങൾ ടെലിഗ്രാമിൽ എത്തിയില്ല, പക്ഷേ അക്കൗണ്ട് നടനെ പുനരാരംഭിക്കുകയും എല്ലാം പ്രവർത്തിക്കുകയും ചെയ്യുന്നു. സന്ദേശം അയച്ചു എന്ന് ടെലിഗ്രാം നടൻ പ്രതികരിക്കുമ്പോൾ മാത്രമാണ് ലേഖനം ഉപയോക്താവിനെ കാണിക്കുന്ന വിവരം ഞാൻ സംരക്ഷിക്കുന്നത്. എന്നെ ഭീഷണിപ്പെടുത്തുന്ന ഏറ്റവും മോശമായ കാര്യം, സന്ദേശം പലതവണ അയയ്ക്കുക എന്നതാണ് (അത് ഡെലിവർ ചെയ്താൽ, പക്ഷേ സ്ഥിരീകരണം എങ്ങനെയെങ്കിലും നഷ്ടപ്പെട്ടു). തത്വത്തിൽ, ആദ്യത്തെ നടൻ തന്റെ ഉള്ളിൽ സംസ്ഥാനം സംഭരിക്കുകയല്ല, മറിച്ച് ചില ഡാറ്റാബേസുമായി ആശയവിനിമയം നടത്തുകയാണെങ്കിൽ, അയാൾക്ക് അദൃശ്യമായി വീഴുകയും ജീവിതത്തിലേക്ക് മടങ്ങുകയും ചെയ്യാം. അഭിനേതാക്കളുടെ അവസ്ഥ പുനഃസ്ഥാപിക്കാൻ എനിക്ക് അക്കയുടെ സ്ഥിരോത്സാഹവും ശ്രമിക്കാം, എന്നാൽ നിലവിലെ നടപ്പാക്കൽ അതിന്റെ ലാളിത്യം കൊണ്ട് എനിക്ക് അനുയോജ്യമാണ്. എന്റെ കോഡ് പലപ്പോഴും തകരാറിലായിട്ടില്ല - നേരെമറിച്ച്, അത് അസാധ്യമാക്കുന്നതിന് ഞാൻ വളരെയധികം പരിശ്രമിച്ചു. പക്ഷേ, അത് സംഭവിക്കുന്നു, പ്രോഗ്രാമിനെ ഒറ്റപ്പെട്ട കഷണങ്ങളാക്കി മാറ്റാനുള്ള കഴിവ് എനിക്ക് വളരെ സൗകര്യപ്രദവും പ്രായോഗികവുമായി തോന്നി.

ഞാൻ സർക്കിൾ-സി ചേർത്തു, അതിനാൽ കോഡ് തകരാറിലാണെങ്കിൽ, നിങ്ങൾ അതിനെക്കുറിച്ച് ഉടൻ കണ്ടെത്തും. കുറഞ്ഞത്, കോഡ് കംപൈൽ ചെയ്യുന്നത് നിർത്തിയെന്നാണ് ഇതിനർത്ഥം. തുടക്കത്തിൽ ഞാൻ ട്രാവിസ് ചേർക്കാൻ ആഗ്രഹിച്ചു, പക്ഷേ അത് ഫോർക്കുകളില്ലാതെ എന്റെ പ്രോജക്റ്റുകൾ കാണിച്ചു. പൊതുവേ, ഈ രണ്ട് കാര്യങ്ങളും തുറന്ന ശേഖരണങ്ങളിൽ സ്വതന്ത്രമായി ഉപയോഗിക്കാൻ കഴിയും.

ഫലങ്ങൾ

ഇതിനകം നവംബറാണ്. ബോട്ട് എഴുതിയിരിക്കുന്നു, കഴിഞ്ഞ രണ്ടാഴ്ചയായി ഞാൻ ഇത് ഉപയോഗിക്കുന്നു, എനിക്ക് ഇത് ഇഷ്ടപ്പെട്ടു. നിങ്ങൾക്ക് മെച്ചപ്പെടുത്താനുള്ള ആശയങ്ങൾ ഉണ്ടെങ്കിൽ, എഴുതുക. ഇത് ധനസമ്പാദനം നടത്തുന്നതിൽ കാര്യമൊന്നും ഞാൻ കാണുന്നില്ല - ഇത് പ്രവർത്തിക്കുകയും രസകരമായ ലേഖനങ്ങൾ അയയ്ക്കുകയും ചെയ്യട്ടെ.

ബോട്ട് ലിങ്ക്: https://t.me/HabraFilterBot
ഗിത്തബ്: https://github.com/Kright/habrahabr_reader

ചെറിയ നിഗമനങ്ങൾ:

• ഒരു ചെറിയ പ്രോജക്റ്റ് പോലും വളരെയധികം സമയമെടുക്കും.
• നിങ്ങൾ Google അല്ല. പീരങ്കിയിൽ നിന്ന് കുരുവികളെ വെടിവെച്ചിട്ട് കാര്യമില്ല. ഒരു ലളിതമായ പരിഹാരം അതുപോലെ പ്രവർത്തിച്ചേക്കാം.
• പുതിയ സാങ്കേതികവിദ്യകൾ പരീക്ഷിക്കാൻ പെറ്റ് പ്രോജക്ടുകൾ വളരെ നല്ലതാണ്.
• ടെലിഗ്രാം ബോട്ടുകൾ വളരെ ലളിതമായി എഴുതിയിരിക്കുന്നു. "ടീം വർക്കിനും" സാങ്കേതികവിദ്യയുടെ പരീക്ഷണങ്ങൾക്കും വേണ്ടിയല്ലെങ്കിൽ, ബോട്ട് ഒന്നോ രണ്ടോ ആഴ്ചകൾക്കുള്ളിൽ എഴുതപ്പെടും.
• മൾട്ടി-ത്രെഡിംഗും തെറ്റ്-സഹിഷ്ണുതയുള്ള കോഡും നന്നായി യോജിക്കുന്ന ഒരു രസകരമായ സംഗതിയാണ് നടൻ മോഡൽ.
• ഓപ്പൺ സോഴ്‌സ് കമ്മ്യൂണിറ്റി ഫോർക്കുകളെ ഇഷ്ടപ്പെടുന്നത് എന്തുകൊണ്ടാണെന്ന് എനിക്ക് മനസ്സിലായി എന്ന് ഞാൻ കരുതുന്നു.
• ഡാറ്റാബേസുകൾ നല്ലതാണ്, കാരണം ആപ്ലിക്കേഷൻ ക്രാഷുകൾ/പുനരാരംഭിക്കൽ എന്നിവയെ അപേക്ഷിച്ച് നിലനിൽക്കില്ല, എന്നാൽ ഒരു ഡാറ്റാബേസിനൊപ്പം പ്രവർത്തിക്കുന്നത് കോഡിനെ സങ്കീർണ്ണമാക്കുകയും ഡാറ്റാ ഘടനയിൽ നിയന്ത്രണങ്ങൾ ഏർപ്പെടുത്തുകയും ചെയ്യുന്നു.

അവലംബം: www.habr.com