Habr ನಿಂದ ವೈಯಕ್ತಿಕಗೊಳಿಸಿದ ಲೇಖನಗಳ ಆಯ್ಕೆಗಾಗಿ ಟೆಲಿಗ್ರಾಮ್ ಬೋಟ್

"ಏಕೆ?" ಎಂಬಂತಹ ಪ್ರಶ್ನೆಗಳಿಗೆ ಹಳೆಯ ಲೇಖನವಿದೆ - ನ್ಯಾಚುರಲ್ ಗೀಕ್ಟೈಮ್ಸ್ - ಸ್ಪೇಸ್ ಕ್ಲೀನರ್ ಮಾಡುವುದು.

ಬಹಳಷ್ಟು ಲೇಖನಗಳಿವೆ, ವ್ಯಕ್ತಿನಿಷ್ಠ ಕಾರಣಗಳಿಗಾಗಿ ಅವುಗಳಲ್ಲಿ ಕೆಲವು ನನಗೆ ಇಷ್ಟವಿಲ್ಲ, ಮತ್ತು ಕೆಲವು, ಇದಕ್ಕೆ ವಿರುದ್ಧವಾಗಿ, ಬಿಟ್ಟುಬಿಡುವುದು ಕರುಣೆಯಾಗಿದೆ. ನಾನು ಈ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಅತ್ಯುತ್ತಮವಾಗಿಸಲು ಮತ್ತು ಸಮಯವನ್ನು ಉಳಿಸಲು ಬಯಸುತ್ತೇನೆ.

ಮೇಲಿನ ಲೇಖನವು ಬ್ರೌಸರ್‌ನಲ್ಲಿ ಸ್ಕ್ರಿಪ್ಟಿಂಗ್ ವಿಧಾನವನ್ನು ಸೂಚಿಸಿದೆ, ಆದರೆ ಈ ಕೆಳಗಿನ ಕಾರಣಗಳಿಗಾಗಿ ನಾನು ಅದನ್ನು ನಿಜವಾಗಿಯೂ ಇಷ್ಟಪಡಲಿಲ್ಲ (ನಾನು ಇದನ್ನು ಮೊದಲು ಬಳಸಿದ್ದರೂ ಸಹ):

• ನಿಮ್ಮ ಕಂಪ್ಯೂಟರ್/ಫೋನ್‌ನಲ್ಲಿರುವ ವಿವಿಧ ಬ್ರೌಸರ್‌ಗಳಿಗಾಗಿ, ಸಾಧ್ಯವಾದರೆ ನೀವು ಅದನ್ನು ಮತ್ತೆ ಕಾನ್ಫಿಗರ್ ಮಾಡಬೇಕು.
• ಲೇಖಕರಿಂದ ಕಟ್ಟುನಿಟ್ಟಾದ ಫಿಲ್ಟರಿಂಗ್ ಯಾವಾಗಲೂ ಅನುಕೂಲಕರವಾಗಿಲ್ಲ.
• ನೀವು ಕಳೆದುಕೊಳ್ಳಲು ಬಯಸದ ಲೇಖನಗಳನ್ನು ವರ್ಷಕ್ಕೊಮ್ಮೆ ಪ್ರಕಟಿಸಿದರೂ ಸಹ ಲೇಖಕರೊಂದಿಗಿನ ಸಮಸ್ಯೆಯು ಪರಿಹರಿಸಲ್ಪಟ್ಟಿಲ್ಲ.

ಲೇಖನದ ರೇಟಿಂಗ್‌ಗಳ ಆಧಾರದ ಮೇಲೆ ಸೈಟ್‌ನಲ್ಲಿ ನಿರ್ಮಿಸಲಾದ ಫಿಲ್ಟರಿಂಗ್ ಯಾವಾಗಲೂ ಅನುಕೂಲಕರವಾಗಿರುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಹೆಚ್ಚು ವಿಶೇಷವಾದ ಲೇಖನಗಳು, ಅವುಗಳ ಮೌಲ್ಯದ ಹೊರತಾಗಿಯೂ, ಸಾಧಾರಣ ರೇಟಿಂಗ್ ಅನ್ನು ಪಡೆಯಬಹುದು.

ಆರಂಭದಲ್ಲಿ, ನಾನು RSS ಫೀಡ್ ಅನ್ನು (ಅಥವಾ ಹಲವಾರು) ರಚಿಸಲು ಬಯಸಿದ್ದೆ, ಅಲ್ಲಿ ಆಸಕ್ತಿದಾಯಕ ವಿಷಯಗಳನ್ನು ಮಾತ್ರ ಬಿಟ್ಟುಬಿಡುತ್ತೇನೆ. ಆದರೆ ಕೊನೆಯಲ್ಲಿ, RSS ಅನ್ನು ಓದುವುದು ತುಂಬಾ ಅನುಕೂಲಕರವಲ್ಲ ಎಂದು ತೋರುತ್ತಿದೆ: ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ, ಲೇಖನಕ್ಕೆ ಕಾಮೆಂಟ್ ಮಾಡಲು / ಮತ ಚಲಾಯಿಸಲು / ನಿಮ್ಮ ಮೆಚ್ಚಿನವುಗಳಿಗೆ ಸೇರಿಸಲು, ನೀವು ಬ್ರೌಸರ್ ಮೂಲಕ ಹೋಗಬೇಕಾಗುತ್ತದೆ. ಅದಕ್ಕಾಗಿಯೇ ನಾನು ವೈಯಕ್ತಿಕ ಸಂದೇಶದಲ್ಲಿ ಆಸಕ್ತಿದಾಯಕ ಲೇಖನಗಳನ್ನು ಕಳುಹಿಸುವ ಟೆಲಿಗ್ರಾಮ್ ಬಾಟ್ ಅನ್ನು ಬರೆದಿದ್ದೇನೆ. ಟೆಲಿಗ್ರಾಮ್ ಸ್ವತಃ ಅವುಗಳಲ್ಲಿ ಸುಂದರವಾದ ಪೂರ್ವವೀಕ್ಷಣೆಗಳನ್ನು ಮಾಡುತ್ತದೆ, ಇದು ಲೇಖಕರು/ರೇಟಿಂಗ್/ವೀಕ್ಷಣೆಗಳ ಕುರಿತಾದ ಮಾಹಿತಿಯೊಂದಿಗೆ ಸೇರಿ ಸಾಕಷ್ಟು ತಿಳಿವಳಿಕೆಯನ್ನು ನೀಡುತ್ತದೆ.

ಕಟ್ ಕೆಳಗೆ ಕೆಲಸದ ವೈಶಿಷ್ಟ್ಯಗಳು, ಬರವಣಿಗೆಯ ಪ್ರಕ್ರಿಯೆ ಮತ್ತು ತಾಂತ್ರಿಕ ಪರಿಹಾರಗಳಂತಹ ವಿವರಗಳಿವೆ.

ಬೋಟ್ ಬಗ್ಗೆ ಸಂಕ್ಷಿಪ್ತವಾಗಿ

ಭಂಡಾರ: https://github.com/Kright/habrahabr_reader

ಟೆಲಿಗ್ರಾಂನಲ್ಲಿ ಬಾಟ್: https://t.me/HabraFilterBot

ಬಳಕೆದಾರರು ಟ್ಯಾಗ್‌ಗಳು ಮತ್ತು ಲೇಖಕರಿಗೆ ಹೆಚ್ಚುವರಿ ರೇಟಿಂಗ್ ಅನ್ನು ಹೊಂದಿಸುತ್ತಾರೆ. ಅದರ ನಂತರ, ಲೇಖನಗಳಿಗೆ ಫಿಲ್ಟರ್ ಅನ್ನು ಅನ್ವಯಿಸಲಾಗುತ್ತದೆ - ಹಬ್ರೆಯಲ್ಲಿನ ಲೇಖನದ ರೇಟಿಂಗ್, ಲೇಖಕರ ಬಳಕೆದಾರರ ರೇಟಿಂಗ್ ಮತ್ತು ಟ್ಯಾಗ್ ಮೂಲಕ ಬಳಕೆದಾರರ ರೇಟಿಂಗ್‌ಗಳ ಸರಾಸರಿಯನ್ನು ಸೇರಿಸಲಾಗುತ್ತದೆ. ಬಳಕೆದಾರ-ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಮಿತಿಗಿಂತ ಮೊತ್ತವು ಹೆಚ್ಚಿದ್ದರೆ, ಲೇಖನವು ಫಿಲ್ಟರ್ ಅನ್ನು ಹಾದುಹೋಗುತ್ತದೆ.

ಬೋಟ್ ಬರೆಯುವ ಒಂದು ಬದಿಯ ಗುರಿ ವಿನೋದ ಮತ್ತು ಅನುಭವವನ್ನು ಪಡೆಯುವುದು. ಇದಲ್ಲದೆ, ನಾನು ಅದನ್ನು ನಿಯಮಿತವಾಗಿ ನೆನಪಿಸಿಕೊಳ್ಳುತ್ತೇನೆ ನಾನು ಗೂಗಲ್ ಅಲ್ಲ, ಮತ್ತು ಆದ್ದರಿಂದ ಅನೇಕ ಕೆಲಸಗಳನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಸರಳವಾಗಿ ಮತ್ತು ಪ್ರಾಚೀನವಾಗಿ ಮಾಡಲಾಗುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಇದು ಬೋಟ್ ಬರೆಯುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಮೂರು ತಿಂಗಳು ತೆಗೆದುಕೊಳ್ಳುವುದನ್ನು ತಡೆಯಲಿಲ್ಲ.

ಹೊರಗೆ ಬೇಸಿಗೆಯಾಗಿತ್ತು

Заканчивался июль, а я решил написать бота. И не в одиночку, а со знакомым, который осваивал scala и хотел что-нибудь написать на ней. Начало выглядело многообещающим — код будет пилиться «комадной», задача казалось нетрудной и я думал, что через пару недель или месяц бот будет готов.

ಕಳೆದ ಕೆಲವು ವರ್ಷಗಳಿಂದ ನಾನು ಕಾಲಕಾಲಕ್ಕೆ ಬಂಡೆಯ ಮೇಲೆ ಕೋಡ್ ಬರೆಯುತ್ತಿದ್ದೇನೆ ಎಂಬ ವಾಸ್ತವದ ಹೊರತಾಗಿಯೂ, ಯಾರೂ ಸಾಮಾನ್ಯವಾಗಿ ಈ ಕೋಡ್ ಅನ್ನು ನೋಡುವುದಿಲ್ಲ ಅಥವಾ ನೋಡುವುದಿಲ್ಲ: ಪಿಇಟಿ ಯೋಜನೆಗಳು, ಕೆಲವು ವಿಚಾರಗಳನ್ನು ಪರೀಕ್ಷಿಸುವುದು, ಡೇಟಾವನ್ನು ಪೂರ್ವಭಾವಿಯಾಗಿ ಸಂಸ್ಕರಿಸುವುದು, FP ಯಿಂದ ಕೆಲವು ಪರಿಕಲ್ಪನೆಗಳನ್ನು ಮಾಸ್ಟರಿಂಗ್ ಮಾಡುವುದು. ತಂಡದಲ್ಲಿ ಬರವಣಿಗೆಯ ಕೋಡ್ ಹೇಗಿರುತ್ತದೆ ಎಂಬುದರ ಬಗ್ಗೆ ನನಗೆ ನಿಜವಾಗಿಯೂ ಆಸಕ್ತಿ ಇತ್ತು, ಏಕೆಂದರೆ ರಾಕ್‌ನಲ್ಲಿ ಕೋಡ್ ಅನ್ನು ವಿಭಿನ್ನ ರೀತಿಯಲ್ಲಿ ಬರೆಯಬಹುದು.

ಏನು ಹೋಗಿರಬಹುದು ಆದ್ದರಿಂದ? ಆದಾಗ್ಯೂ, ವಿಷಯಗಳನ್ನು ಹೊರದಬ್ಬುವುದು ಬೇಡ.
ಬದ್ಧತೆಯ ಇತಿಹಾಸವನ್ನು ಬಳಸಿಕೊಂಡು ನಡೆಯುವ ಎಲ್ಲವನ್ನೂ ಟ್ರ್ಯಾಕ್ ಮಾಡಬಹುದು.

ಜುಲೈ 27 ರಂದು ಪರಿಚಯಸ್ಥರು ರೆಪೊಸಿಟರಿಯನ್ನು ರಚಿಸಿದರು, ಆದರೆ ಬೇರೆ ಏನನ್ನೂ ಮಾಡಲಿಲ್ಲ, ಆದ್ದರಿಂದ ನಾನು ಕೋಡ್ ಬರೆಯಲು ಪ್ರಾರಂಭಿಸಿದೆ.

30 ಜುಲೈ

ಸಂಕ್ಷಿಪ್ತವಾಗಿ: ನಾನು Habr ನ rss ಫೀಡ್‌ನ ಪಾರ್ಸಿಂಗ್ ಅನ್ನು ಬರೆದಿದ್ದೇನೆ.

• com.github.pureconfig ಟೈಪ್‌ಸೇಫ್ ಕಾನ್ಫಿಗರ್‌ಗಳನ್ನು ನೇರವಾಗಿ ಕೇಸ್ ತರಗತಿಗಳಿಗೆ ಓದಲು (ಇದು ತುಂಬಾ ಅನುಕೂಲಕರವಾಗಿದೆ)
• scala-xml xml ಓದಲು: ಆರಂಭದಲ್ಲಿ ನಾನು rss ಫೀಡ್‌ಗಾಗಿ ನನ್ನ ಸ್ವಂತ ಅನುಷ್ಠಾನವನ್ನು ಬರೆಯಲು ಬಯಸಿದ್ದೆ ಮತ್ತು rss ಫೀಡ್ xml ಸ್ವರೂಪದಲ್ಲಿದೆ, ನಾನು ಈ ಲೈಬ್ರರಿಯನ್ನು ಪಾರ್ಸಿಂಗ್ ಮಾಡಲು ಬಳಸಿದ್ದೇನೆ. ವಾಸ್ತವವಾಗಿ, RSS ಪಾರ್ಸಿಂಗ್ ಕೂಡ ಕಾಣಿಸಿಕೊಂಡಿತು.
• scalatest ಪರೀಕ್ಷೆಗಳಿಗೆ. ಸಣ್ಣ ಯೋಜನೆಗಳಿಗೆ ಸಹ, ಪರೀಕ್ಷೆಗಳನ್ನು ಬರೆಯುವುದು ಸಮಯವನ್ನು ಉಳಿಸುತ್ತದೆ - ಉದಾಹರಣೆಗೆ, xml ಪಾರ್ಸಿಂಗ್ ಅನ್ನು ಡೀಬಗ್ ಮಾಡುವಾಗ, ಅದನ್ನು ಫೈಲ್‌ಗೆ ಡೌನ್‌ಲೋಡ್ ಮಾಡುವುದು, ಪರೀಕ್ಷೆಗಳನ್ನು ಬರೆಯುವುದು ಮತ್ತು ದೋಷಗಳನ್ನು ಸರಿಪಡಿಸುವುದು ತುಂಬಾ ಸುಲಭ. ಅಮಾನ್ಯವಾದ utf-8 ಅಕ್ಷರಗಳೊಂದಿಗೆ ಕೆಲವು ವಿಚಿತ್ರ html ಅನ್ನು ಪಾರ್ಸಿಂಗ್ ಮಾಡುವುದರೊಂದಿಗೆ ದೋಷವು ನಂತರ ಕಾಣಿಸಿಕೊಂಡಾಗ, ಅದನ್ನು ಫೈಲ್‌ನಲ್ಲಿ ಇರಿಸಲು ಮತ್ತು ಪರೀಕ್ಷೆಯನ್ನು ಸೇರಿಸಲು ಇದು ಹೆಚ್ಚು ಅನುಕೂಲಕರವಾಗಿದೆ.
• ಅಕ್ಕನ ನಟರು. ವಸ್ತುನಿಷ್ಠವಾಗಿ, ಅವರು ಅಗತ್ಯವಿಲ್ಲ, ಆದರೆ ಯೋಜನೆಯನ್ನು ವಿನೋದಕ್ಕಾಗಿ ಬರೆಯಲಾಗಿದೆ, ನಾನು ಅವುಗಳನ್ನು ಪ್ರಯತ್ನಿಸಲು ಬಯಸುತ್ತೇನೆ. ಪರಿಣಾಮವಾಗಿ, ನಾನು ಅದನ್ನು ಇಷ್ಟಪಟ್ಟಿದ್ದೇನೆ ಎಂದು ಹೇಳಲು ನಾನು ಸಿದ್ಧನಿದ್ದೇನೆ. OOP ಯ ಕಲ್ಪನೆಯನ್ನು ಇನ್ನೊಂದು ಬದಿಯಿಂದ ನೋಡಬಹುದು - ಸಂದೇಶಗಳನ್ನು ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳುವ ನಟರು ಇದ್ದಾರೆ. ಹೆಚ್ಚು ಆಸಕ್ತಿದಾಯಕ ವಿಷಯವೆಂದರೆ ಸಂದೇಶವು ಬರದಿರುವ ಅಥವಾ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸದಿರುವ ರೀತಿಯಲ್ಲಿ ನೀವು ಕೋಡ್ ಅನ್ನು ಬರೆಯಬಹುದು (ಮತ್ತು ಮಾಡಬೇಕು) (ಸಾಮಾನ್ಯವಾಗಿ ಹೇಳುವುದಾದರೆ, ಖಾತೆಯು ಒಂದೇ ಕಂಪ್ಯೂಟರ್‌ನಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವಾಗ, ಸಂದೇಶಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳಬಾರದು). ಮೊದಲಿಗೆ ನಾನು ನನ್ನ ತಲೆಯನ್ನು ಸ್ಕ್ರಾಚ್ ಮಾಡುತ್ತಿದ್ದೆ ಮತ್ತು ನಟರು ಪರಸ್ಪರ ಚಂದಾದಾರರಾಗುವುದರೊಂದಿಗೆ ಕೋಡ್ನಲ್ಲಿ ಕಸವು ಇತ್ತು, ಆದರೆ ಕೊನೆಯಲ್ಲಿ ನಾನು ಸರಳ ಮತ್ತು ಸೊಗಸಾದ ವಾಸ್ತುಶಿಲ್ಪದೊಂದಿಗೆ ಬರಲು ನಿರ್ವಹಿಸುತ್ತಿದ್ದೆ. ಪ್ರತಿ ನಟನ ಒಳಗಿನ ಕೋಡ್ ಅನ್ನು ಏಕ-ಥ್ರೆಡ್ ಎಂದು ಪರಿಗಣಿಸಬಹುದು; ಒಬ್ಬ ನಟ ಕ್ರ್ಯಾಶ್ ಮಾಡಿದಾಗ, ಅಕ್ಕಾ ಅದನ್ನು ಮರುಪ್ರಾರಂಭಿಸುತ್ತದೆ - ಫಲಿತಾಂಶವು ಸಾಕಷ್ಟು ದೋಷ-ಸಹಿಷ್ಣು ವ್ಯವಸ್ಥೆಯಾಗಿದೆ.

9 ಆಗಸ್ಟ್

ನಾನು ಯೋಜನೆಗೆ ಸೇರಿಸಿದೆ scala-scrapper Habr ನಿಂದ html ಪುಟಗಳನ್ನು ಪಾರ್ಸಿಂಗ್ ಮಾಡಲು (ಲೇಖನ ರೇಟಿಂಗ್, ಬುಕ್‌ಮಾರ್ಕ್‌ಗಳ ಸಂಖ್ಯೆ, ಇತ್ಯಾದಿಗಳಂತಹ ಮಾಹಿತಿಯನ್ನು ಹೊರತೆಗೆಯಲು).

ಮತ್ತು ಬೆಕ್ಕುಗಳು. ಬಂಡೆಯಲ್ಲಿರುವವರು.

ನಾನು ನಂತರ ವಿತರಿಸಿದ ಡೇಟಾಬೇಸ್‌ಗಳ ಬಗ್ಗೆ ಪುಸ್ತಕವನ್ನು ಓದಿದ್ದೇನೆ, ನಾನು CRDT (ಸಂಘರ್ಷ-ಮುಕ್ತ ಪುನರಾವರ್ತಿತ ಡೇಟಾ ಪ್ರಕಾರ) ಕಲ್ಪನೆಯನ್ನು ಇಷ್ಟಪಟ್ಟೆ. https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type, ಹಬ್ರ್), ಹಾಗಾಗಿ ಹಬ್ರೆಯಲ್ಲಿನ ಲೇಖನದ ಬಗ್ಗೆ ಮಾಹಿತಿಗಾಗಿ ನಾನು ಕಮ್ಯುಟೇಟಿವ್ ಸೆಮಿಗ್ರೂಪ್‌ನ ಪ್ರಕಾರದ ವರ್ಗವನ್ನು ಪೋಸ್ಟ್ ಮಾಡಿದ್ದೇನೆ.

ವಾಸ್ತವವಾಗಿ, ಕಲ್ಪನೆಯು ತುಂಬಾ ಸರಳವಾಗಿದೆ - ನಾವು ಏಕತಾನತೆಯಿಂದ ಬದಲಾಗುವ ಕೌಂಟರ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಪ್ರಚಾರಗಳ ಸಂಖ್ಯೆಯು ಕ್ರಮೇಣವಾಗಿ ಬೆಳೆಯುತ್ತಿದೆ, ಜೊತೆಗೆ ಪ್ಲಸಸ್ ಸಂಖ್ಯೆ (ಹಾಗೆಯೇ ಮೈನಸ್ಗಳ ಸಂಖ್ಯೆ). ನಾನು ಲೇಖನದ ಬಗ್ಗೆ ಎರಡು ಆವೃತ್ತಿಗಳ ಮಾಹಿತಿಯನ್ನು ಹೊಂದಿದ್ದರೆ, ನಂತರ ನಾನು "ಅವುಗಳನ್ನು ಒಂದಕ್ಕೆ ವಿಲೀನಗೊಳಿಸಬಹುದು" - ದೊಡ್ಡದಾದ ಕೌಂಟರ್ನ ಸ್ಥಿತಿಯನ್ನು ಹೆಚ್ಚು ಪ್ರಸ್ತುತವೆಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ.

ಸೆಮಿಗ್ರೂಪ್ ಎಂದರೆ ಲೇಖನದ ಬಗ್ಗೆ ಮಾಹಿತಿ ಹೊಂದಿರುವ ಎರಡು ವಸ್ತುಗಳನ್ನು ಒಂದಕ್ಕೆ ವಿಲೀನಗೊಳಿಸಬಹುದು. ಕಮ್ಯುಟೇಟಿವ್ ಎಂದರೆ ನೀವು ಎ + ಬಿ ಮತ್ತು ಬಿ + ಎ ಎರಡನ್ನೂ ವಿಲೀನಗೊಳಿಸಬಹುದು, ಫಲಿತಾಂಶವು ಆದೇಶವನ್ನು ಅವಲಂಬಿಸಿರುವುದಿಲ್ಲ ಮತ್ತು ಕೊನೆಯಲ್ಲಿ ಹೊಸ ಆವೃತ್ತಿಯು ಉಳಿಯುತ್ತದೆ. ಅಂದಹಾಗೆ, ಇಲ್ಲಿ ಸಹಭಾಗಿತ್ವವೂ ಇದೆ.

ಉದಾಹರಣೆಗೆ, ಯೋಜಿಸಿದಂತೆ, ಪಾರ್ಸಿಂಗ್ ನಂತರ ಆರ್ಎಸ್ಎಸ್ ಲೇಖನದ ಬಗ್ಗೆ ಸ್ವಲ್ಪ ದುರ್ಬಲ ಮಾಹಿತಿಯನ್ನು ಒದಗಿಸಿದೆ - ವೀಕ್ಷಣೆಗಳ ಸಂಖ್ಯೆಯಂತಹ ಮೆಟ್ರಿಕ್‌ಗಳಿಲ್ಲದೆ. ನಂತರ ವಿಶೇಷ ನಟರೊಬ್ಬರು ಲೇಖನಗಳ ಬಗ್ಗೆ ಮಾಹಿತಿ ಪಡೆದರು ಮತ್ತು ಅದನ್ನು ನವೀಕರಿಸಲು ಮತ್ತು ಹಳೆಯ ಆವೃತ್ತಿಯೊಂದಿಗೆ ವಿಲೀನಗೊಳಿಸಲು html ಪುಟಗಳಿಗೆ ಓಡಿದರು.

ಸಾಮಾನ್ಯವಾಗಿ ಹೇಳುವುದಾದರೆ, ಅಕ್ಕನಂತೆ, ಇದರ ಅಗತ್ಯವಿಲ್ಲ, ನೀವು ಲೇಖನಕ್ಕಾಗಿ ನವೀಕರಣ ದಿನಾಂಕವನ್ನು ಸಂಗ್ರಹಿಸಬಹುದು ಮತ್ತು ಯಾವುದೇ ವಿಲೀನವಿಲ್ಲದೆ ಹೊಸದನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು, ಆದರೆ ಸಾಹಸದ ಹಾದಿಯು ನನ್ನನ್ನು ಮುನ್ನಡೆಸಿತು.

12 ಆಗಸ್ಟ್

ನಾನು ಸ್ವತಂತ್ರವಾಗಿ ಅನುಭವಿಸಲು ಪ್ರಾರಂಭಿಸಿದೆ ಮತ್ತು ಕೇವಲ ವಿನೋದಕ್ಕಾಗಿ, ನಾನು ಪ್ರತಿಯೊಬ್ಬ ಚಾಟ್ ಅನ್ನು ಪ್ರತ್ಯೇಕ ನಟನನ್ನಾಗಿ ಮಾಡಿದೆ. ಸೈದ್ಧಾಂತಿಕವಾಗಿ, ಒಬ್ಬ ನಟ ಸ್ವತಃ ಸುಮಾರು 300 ಬೈಟ್‌ಗಳನ್ನು ತೂಗುತ್ತದೆ ಮತ್ತು ಅವುಗಳನ್ನು ಮಿಲಿಯನ್‌ಗಳಲ್ಲಿ ರಚಿಸಬಹುದು, ಆದ್ದರಿಂದ ಇದು ಸಂಪೂರ್ಣವಾಗಿ ಸಾಮಾನ್ಯ ವಿಧಾನವಾಗಿದೆ. ಪರಿಹಾರವು ಸಾಕಷ್ಟು ಆಸಕ್ತಿದಾಯಕವಾಗಿದೆ ಎಂದು ನನಗೆ ತೋರುತ್ತದೆ:

ಒಬ್ಬ ನಟ ಅಕ್ಕನ ಟೆಲಿಗ್ರಾಮ್ ಸರ್ವರ್ ಮತ್ತು ಸಂದೇಶ ವ್ಯವಸ್ಥೆಯ ನಡುವೆ ಸೇತುವೆಯಾಗಿದ್ದರು. ಅವರು ಕೇವಲ ಸಂದೇಶಗಳನ್ನು ಸ್ವೀಕರಿಸಿದರು ಮತ್ತು ಬಯಸಿದ ಚಾಟ್ ನಟನಿಗೆ ಕಳುಹಿಸಿದರು. ಚಾಟ್ ನಟನು ಪ್ರತಿಕ್ರಿಯೆಯಾಗಿ ಏನನ್ನಾದರೂ ಹಿಂತಿರುಗಿಸಬಹುದು - ಮತ್ತು ಅದನ್ನು ಟೆಲಿಗ್ರಾಮ್‌ಗೆ ಹಿಂತಿರುಗಿಸಲಾಗುತ್ತದೆ. ತುಂಬಾ ಅನುಕೂಲಕರವಾದ ಸಂಗತಿಯೆಂದರೆ, ಈ ನಟ ಸಾಧ್ಯವಾದಷ್ಟು ಸರಳವಾಗಿ ಹೊರಹೊಮ್ಮಿದರು ಮತ್ತು ಸಂದೇಶಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುವ ತರ್ಕವನ್ನು ಮಾತ್ರ ಹೊಂದಿದ್ದರು. ಮೂಲಕ, ಹೊಸ ಲೇಖನಗಳ ಬಗ್ಗೆ ಮಾಹಿತಿಯು ಪ್ರತಿ ಚಾಟ್‌ಗೆ ಬಂದಿತು, ಆದರೆ ಮತ್ತೆ ನಾನು ಇದರಲ್ಲಿ ಯಾವುದೇ ಸಮಸ್ಯೆಗಳನ್ನು ಕಾಣುವುದಿಲ್ಲ.

ಸಾಮಾನ್ಯವಾಗಿ, ಬೋಟ್ ಈಗಾಗಲೇ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ, ಸಂದೇಶಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತಿದೆ, ಬಳಕೆದಾರರಿಗೆ ಕಳುಹಿಸಲಾದ ಲೇಖನಗಳ ಪಟ್ಟಿಯನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ ಮತ್ತು ಬೋಟ್ ಬಹುತೇಕ ಸಿದ್ಧವಾಗಿದೆ ಎಂದು ನಾನು ಈಗಾಗಲೇ ಯೋಚಿಸುತ್ತಿದ್ದೆ. ಲೇಖಕರ ಹೆಸರುಗಳು ಮತ್ತು ಟ್ಯಾಗ್‌ಗಳನ್ನು ಸಾಮಾನ್ಯೀಕರಿಸುವಂತಹ ಸಣ್ಣ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ನಾನು ನಿಧಾನವಾಗಿ ಸೇರಿಸಿದ್ದೇನೆ ("sd f" ಅನ್ನು "s_d_f" ನೊಂದಿಗೆ ಬದಲಾಯಿಸುವುದು).

ಒಂದೇ ಒಂದು ವಿಷಯ ಉಳಿದಿತ್ತು ಸಣ್ಣ ಆದರೆ - ರಾಜ್ಯವನ್ನು ಎಲ್ಲಿಯೂ ಉಳಿಸಲಾಗಿಲ್ಲ.

ಎಲ್ಲವೂ ತಪ್ಪಾಗಿದೆ

ನಾನು ಬೋಟ್ ಅನ್ನು ಹೆಚ್ಚಾಗಿ ಒಬ್ಬರೇ ಬರೆದಿರುವುದನ್ನು ನೀವು ಗಮನಿಸಿರಬಹುದು. ಆದ್ದರಿಂದ, ಎರಡನೇ ಭಾಗವಹಿಸುವವರು ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ತೊಡಗಿಸಿಕೊಂಡರು, ಮತ್ತು ಈ ಕೆಳಗಿನ ಬದಲಾವಣೆಗಳು ಕೋಡ್‌ನಲ್ಲಿ ಕಾಣಿಸಿಕೊಂಡವು:

• MongoDB ರಾಜ್ಯವನ್ನು ಸಂಗ್ರಹಿಸಲು ಕಾಣಿಸಿಕೊಂಡಿದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಪ್ರಾಜೆಕ್ಟ್‌ನಲ್ಲಿನ ಲಾಗ್‌ಗಳು ಮುರಿದುಹೋಗಿವೆ, ಏಕೆಂದರೆ ಕೆಲವು ಕಾರಣಗಳಿಂದ ಮೊಂಗಾ ಅವುಗಳನ್ನು ಸ್ಪ್ಯಾಮ್ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದರು ಮತ್ತು ಕೆಲವು ಜನರು ಅವುಗಳನ್ನು ಜಾಗತಿಕವಾಗಿ ಆಫ್ ಮಾಡಿದ್ದಾರೆ.
• ಟೆಲಿಗ್ರಾಮ್‌ನಲ್ಲಿನ ಸೇತುವೆ ನಟ ಗುರುತಿಸಲಾಗದಷ್ಟು ರೂಪಾಂತರಗೊಂಡರು ಮತ್ತು ಸ್ವತಃ ಸಂದೇಶಗಳನ್ನು ಪಾರ್ಸಿಂಗ್ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದರು.
• ಚಾಟ್‌ಗಳಿಗಾಗಿ ನಟರನ್ನು ನಿರ್ದಯವಾಗಿ ಕತ್ತರಿಸಲಾಯಿತು ಮತ್ತು ಬದಲಿಗೆ ಎಲ್ಲಾ ಚಾಟ್‌ಗಳ ಬಗ್ಗೆ ಎಲ್ಲಾ ಮಾಹಿತಿಯನ್ನು ಒಂದೇ ಬಾರಿಗೆ ಮರೆಮಾಡಿದ ನಟರಿಂದ ಅವರನ್ನು ಬದಲಾಯಿಸಲಾಯಿತು. ಪ್ರತಿ ಸೀನಿಗೂ ಈ ನಟ ಸಂಕಷ್ಟಕ್ಕೆ ಸಿಲುಕಿದ. ಸರಿ, ಹೌದು, ಲೇಖನದ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ನವೀಕರಿಸುವಾಗ, ಅದನ್ನು ಎಲ್ಲಾ ಚಾಟ್ ನಟರಿಗೆ ಕಳುಹಿಸುವುದು ಕಷ್ಟ (ನಾವು Google ನಂತೆ, ಲಕ್ಷಾಂತರ ಬಳಕೆದಾರರು ಪ್ರತಿಯೊಂದಕ್ಕೂ ಚಾಟ್‌ನಲ್ಲಿ ಮಿಲಿಯನ್ ಲೇಖನಗಳಿಗಾಗಿ ಕಾಯುತ್ತಿದ್ದಾರೆ), ಆದರೆ ಪ್ರತಿ ಬಾರಿ ಚಾಟ್ ಅನ್ನು ನವೀಕರಿಸಲಾಗುತ್ತದೆ, ಮೊಂಗಾಗೆ ಹೋಗುವುದು ಸಹಜ. ನಾನು ಬಹಳ ನಂತರ ಅರಿತುಕೊಂಡಂತೆ, ಚಾಟ್‌ಗಳ ಕೆಲಸದ ತರ್ಕವನ್ನು ಸಹ ಸಂಪೂರ್ಣವಾಗಿ ಕತ್ತರಿಸಲಾಯಿತು ಮತ್ತು ಅದರ ಸ್ಥಳದಲ್ಲಿ ಕೆಲಸ ಮಾಡದ ಏನಾದರೂ ಕಾಣಿಸಿಕೊಂಡಿತು.
• ಪ್ರಕಾರದ ವರ್ಗಗಳ ಯಾವುದೇ ಕುರುಹು ಉಳಿದಿಲ್ಲ.
• ಕೆಲವು ಅನಾರೋಗ್ಯಕರ ತರ್ಕವು ನಟರಲ್ಲಿ ಪರಸ್ಪರ ಚಂದಾದಾರಿಕೆಯೊಂದಿಗೆ ಕಾಣಿಸಿಕೊಂಡಿದೆ, ಇದು ಜನಾಂಗದ ಸ್ಥಿತಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ.
• ಪ್ರಕಾರದ ಕ್ಷೇತ್ರಗಳೊಂದಿಗೆ ಡೇಟಾ ರಚನೆಗಳು Option[Int] -1 ನಂತಹ ಮಾಂತ್ರಿಕ ಡೀಫಾಲ್ಟ್ ಮೌಲ್ಯಗಳೊಂದಿಗೆ ಇಂಟ್ ಆಗಿ ಮಾರ್ಪಟ್ಟಿದೆ. ಮೊಂಗೊಡಿಬಿ json ಅನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಅಲ್ಲಿ ಸಂಗ್ರಹಿಸುವುದರಲ್ಲಿ ಯಾವುದೇ ತಪ್ಪಿಲ್ಲ ಎಂದು ನಂತರ ನಾನು ಅರಿತುಕೊಂಡೆ Option ಸರಿ, ಅಥವಾ ಕನಿಷ್ಠ -1 ಅನ್ನು ಯಾವುದೂ ಇಲ್ಲ ಎಂದು ಪಾರ್ಸ್ ಮಾಡಿ, ಆದರೆ ಆ ಸಮಯದಲ್ಲಿ ನನಗೆ ಇದು ತಿಳಿದಿರಲಿಲ್ಲ ಮತ್ತು "ಹಾಗೆಯೇ ಇರಬೇಕು" ಎಂದು ನನ್ನ ಮಾತನ್ನು ತೆಗೆದುಕೊಂಡೆ. ನಾನು ಆ ಕೋಡ್ ಅನ್ನು ಬರೆಯಲಿಲ್ಲ ಮತ್ತು ಸದ್ಯಕ್ಕೆ ಅದನ್ನು ಬದಲಾಯಿಸಲು ನಾನು ಚಿಂತಿಸಲಿಲ್ಲ.
• ನನ್ನ ಸಾರ್ವಜನಿಕ IP ವಿಳಾಸವು ಬದಲಾಗುತ್ತಿದೆ ಎಂದು ನಾನು ಕಂಡುಕೊಂಡಿದ್ದೇನೆ ಮತ್ತು ಪ್ರತಿ ಬಾರಿ ನಾನು ಅದನ್ನು ಮೊಂಗೋನ ಶ್ವೇತಪಟ್ಟಿಗೆ ಸೇರಿಸಬೇಕಾಗಿತ್ತು. ನಾನು ಸ್ಥಳೀಯವಾಗಿ ಬೋಟ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಿದೆ, ಮೊಂಗಾ ಕಂಪನಿಯಾಗಿ ಮೊಂಗಾದ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಎಲ್ಲೋ ಇತ್ತು.
• ಇದ್ದಕ್ಕಿದ್ದಂತೆ, ಟ್ಯಾಗ್‌ಗಳ ಸಾಮಾನ್ಯೀಕರಣ ಮತ್ತು ಟೆಲಿಗ್ರಾಮ್‌ಗಳಿಗಾಗಿ ಸಂದೇಶ ಫಾರ್ಮ್ಯಾಟಿಂಗ್ ಕಣ್ಮರೆಯಾಯಿತು. (ಹ್ಮ್, ಅದು ಏಕೆ?)
• Мне понравилось, что состояние бота хранится во внешней БД, и при перезапуске он продолжает работать как ни в чём ни бывало. Впрочем, это был единственный плюс.

ಎರಡನೆಯ ವ್ಯಕ್ತಿಗೆ ಯಾವುದೇ ನಿರ್ದಿಷ್ಟ ಆತುರವಿಲ್ಲ, ಮತ್ತು ಈ ಎಲ್ಲಾ ಬದಲಾವಣೆಗಳು ಈಗಾಗಲೇ ಸೆಪ್ಟೆಂಬರ್ ಆರಂಭದಲ್ಲಿ ಒಂದು ದೊಡ್ಡ ರಾಶಿಯಲ್ಲಿ ಕಾಣಿಸಿಕೊಂಡವು. ಪರಿಣಾಮವಾಗಿ ಉಂಟಾಗುವ ವಿನಾಶದ ಪ್ರಮಾಣವನ್ನು ನಾನು ತಕ್ಷಣವೇ ಪ್ರಶಂಸಿಸಲಿಲ್ಲ ಮತ್ತು ಡೇಟಾಬೇಸ್ನ ಕೆಲಸವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸಿದೆ, ಏಕೆಂದರೆ ... ನಾನು ಮೊದಲು ಅವರೊಂದಿಗೆ ವ್ಯವಹರಿಸಿಲ್ಲ. ಎಷ್ಟು ವರ್ಕಿಂಗ್ ಕೋಡ್ ಅನ್ನು ಕಡಿತಗೊಳಿಸಲಾಗಿದೆ ಮತ್ತು ಅದರ ಸ್ಥಳದಲ್ಲಿ ಎಷ್ಟು ದೋಷಗಳನ್ನು ಸೇರಿಸಲಾಗಿದೆ ಎಂದು ನಾನು ನಂತರವೇ ಅರಿತುಕೊಂಡೆ.

ಸೆಪ್ಟೆಂಬರ್

ಮೊದಮೊದಲು ಮೊಂಗವನ್ನು ಕರಗತ ಮಾಡಿಕೊಂಡು ಚೆನ್ನಾಗಿ ಮಾಡಿದರೆ ಉಪಯೋಗವಾಗುತ್ತದೆ ಎಂದುಕೊಂಡೆ. ಡೇಟಾಬೇಸ್‌ನೊಂದಿಗೆ ಸಂವಹನವನ್ನು ಸಂಘಟಿಸುವುದು ಸಹ ಒಂದು ಕಲೆ ಎಂದು ನಾನು ನಿಧಾನವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸಿದೆ, ಇದರಲ್ಲಿ ನೀವು ಬಹಳಷ್ಟು ರೇಸ್‌ಗಳನ್ನು ಮಾಡಬಹುದು ಮತ್ತು ತಪ್ಪುಗಳನ್ನು ಮಾಡಬಹುದು. ಉದಾಹರಣೆಗೆ, ಬಳಕೆದಾರರು ಎರಡು ಸಂದೇಶಗಳನ್ನು ಸ್ವೀಕರಿಸಿದರೆ /subscribe - ಮತ್ತು ಪ್ರತಿಯೊಂದಕ್ಕೂ ಪ್ರತಿಕ್ರಿಯೆಯಾಗಿ ನಾವು ಟೇಬಲ್‌ನಲ್ಲಿ ನಮೂದನ್ನು ರಚಿಸುತ್ತೇವೆ, ಏಕೆಂದರೆ ಆ ಸಂದೇಶಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವ ಸಮಯದಲ್ಲಿ ಬಳಕೆದಾರರು ಚಂದಾದಾರರಾಗಿಲ್ಲ. ಮೊಂಗಾದೊಂದಿಗೆ ಅದರ ಪ್ರಸ್ತುತ ರೂಪದಲ್ಲಿ ಸಂವಹನವು ಉತ್ತಮ ರೀತಿಯಲ್ಲಿ ಬರೆಯಲ್ಪಟ್ಟಿಲ್ಲ ಎಂದು ನನಗೆ ಅನುಮಾನವಿದೆ. ಉದಾಹರಣೆಗೆ, ಅವರು ಸೈನ್ ಅಪ್ ಮಾಡಿದ ಕ್ಷಣದಲ್ಲಿ ಬಳಕೆದಾರರ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ರಚಿಸಲಾಗಿದೆ. ಚಂದಾದಾರಿಕೆಯ ಸತ್ಯದ ಮೊದಲು ಅವರು ಅವುಗಳನ್ನು ಬದಲಾಯಿಸಲು ಪ್ರಯತ್ನಿಸಿದರೆ ... ಬೋಟ್ ಏನನ್ನೂ ಪ್ರತಿಕ್ರಿಯಿಸಲಿಲ್ಲ, ಏಕೆಂದರೆ ನಟನಲ್ಲಿರುವ ಕೋಡ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳಿಗಾಗಿ ಡೇಟಾಬೇಸ್‌ಗೆ ಹೋಯಿತು, ಅದನ್ನು ಕಂಡುಹಿಡಿಯಲಿಲ್ಲ ಮತ್ತು ಕ್ರ್ಯಾಶ್ ಆಗಲಿಲ್ಲ. ಅಗತ್ಯವಿರುವಂತೆ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಏಕೆ ರಚಿಸಬಾರದು ಎಂದು ಕೇಳಿದಾಗ, ಬಳಕೆದಾರರು ಚಂದಾದಾರರಾಗಿಲ್ಲದಿದ್ದರೆ ಅವುಗಳನ್ನು ಬದಲಾಯಿಸುವ ಅಗತ್ಯವಿಲ್ಲ ಎಂದು ನಾನು ಕಲಿತಿದ್ದೇನೆ... ಸಂದೇಶ ಫಿಲ್ಟರಿಂಗ್ ವ್ಯವಸ್ಥೆಯನ್ನು ಹೇಗಾದರೂ ನಿಸ್ಸಂಶಯವಾಗಿ ಮಾಡಲಾಗಿದೆ, ಮತ್ತು ಕೋಡ್ ಅನ್ನು ಹತ್ತಿರದಿಂದ ನೋಡಿದ ನಂತರವೂ ನಾನು ಸಾಧ್ಯವಾಯಿತು ಇದನ್ನು ಆರಂಭದಲ್ಲಿ ಈ ರೀತಿ ಉದ್ದೇಶಿಸಲಾಗಿದೆಯೇ ಅಥವಾ ದೋಷವಿದೆಯೇ ಎಂದು ಅರ್ಥವಾಗುತ್ತಿಲ್ಲ.

ಚಾಟ್‌ಗೆ ಸಲ್ಲಿಸಿದ ಯಾವುದೇ ಲೇಖನಗಳ ಪಟ್ಟಿ ಇಲ್ಲ; ಬದಲಿಗೆ, ನಾನೇ ಬರೆಯುವಂತೆ ಸೂಚಿಸಲಾಗಿದೆ. ಇದು ನನಗೆ ಆಶ್ಚರ್ಯವನ್ನುಂಟು ಮಾಡಿತು - ಸಾಮಾನ್ಯವಾಗಿ, ನಾನು ಎಲ್ಲಾ ರೀತಿಯ ವಿಷಯಗಳನ್ನು ಯೋಜನೆಗೆ ಎಳೆಯುವುದನ್ನು ವಿರೋಧಿಸಲಿಲ್ಲ, ಆದರೆ ಈ ವಿಷಯಗಳನ್ನು ತಂದು ಅವುಗಳನ್ನು ತಿರುಗಿಸಿದವರಿಗೆ ಇದು ತಾರ್ಕಿಕವಾಗಿರುತ್ತದೆ. ಆದರೆ ಇಲ್ಲ, ಎರಡನೇ ಭಾಗವಹಿಸುವವರು ಎಲ್ಲವನ್ನೂ ಬಿಟ್ಟುಕೊಡುವಂತೆ ತೋರುತ್ತಿದೆ, ಆದರೆ ಚಾಟ್‌ನೊಳಗಿನ ಪಟ್ಟಿಯು ಕೆಟ್ಟ ಪರಿಹಾರವಾಗಿದೆ ಎಂದು ಹೇಳಿದರು ಮತ್ತು "ಬಳಕೆದಾರ x ಗೆ ಲೇಖನ y ಅನ್ನು ಕಳುಹಿಸಲಾಗಿದೆ" ನಂತಹ ಈವೆಂಟ್‌ಗಳೊಂದಿಗೆ ಸೈನ್ ಮಾಡುವುದು ಅವಶ್ಯಕ ಎಂದು ಹೇಳಿದರು. ನಂತರ, ಬಳಕೆದಾರರು ಹೊಸ ಲೇಖನಗಳನ್ನು ಕಳುಹಿಸಲು ವಿನಂತಿಸಿದರೆ, ಡೇಟಾಬೇಸ್‌ಗೆ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸುವುದು ಅಗತ್ಯವಾಗಿತ್ತು, ಅದು ಈವೆಂಟ್‌ಗಳಿಂದ ಬಳಕೆದಾರರಿಗೆ ಸಂಬಂಧಿಸಿದ ಘಟನೆಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ, ಹೊಸ ಲೇಖನಗಳ ಪಟ್ಟಿಯನ್ನು ಸಹ ಪಡೆಯುತ್ತದೆ, ಅವುಗಳನ್ನು ಫಿಲ್ಟರ್ ಮಾಡಿ, ಬಳಕೆದಾರರಿಗೆ ಕಳುಹಿಸಿ ಮತ್ತು ಈ ಕುರಿತು ಘಟನೆಗಳನ್ನು ಮತ್ತೆ ಡೇಟಾಬೇಸ್‌ಗೆ ಎಸೆಯಿರಿ.

ಎರಡನೇ ಪಾಲ್ಗೊಳ್ಳುವವರನ್ನು ಅಮೂರ್ತತೆಯ ಕಡೆಗೆ ಎಲ್ಲೋ ಒಯ್ಯಲಾಯಿತು, ಆಗ ಬೋಟ್ ಹಬರ್‌ನಿಂದ ಲೇಖನಗಳನ್ನು ಮಾತ್ರ ಸ್ವೀಕರಿಸುವುದಿಲ್ಲ ಮತ್ತು ಟೆಲಿಗ್ರಾಮ್‌ಗೆ ಮಾತ್ರ ಕಳುಹಿಸಲಾಗುವುದಿಲ್ಲ.

ನಾನು ಹೇಗಾದರೂ ಸೆಪ್ಟೆಂಬರ್ ದ್ವಿತೀಯಾರ್ಧದಲ್ಲಿ ಪ್ರತ್ಯೇಕ ಚಿಹ್ನೆಯ ರೂಪದಲ್ಲಿ ಘಟನೆಗಳನ್ನು ಜಾರಿಗೆ ತಂದಿದ್ದೇನೆ. ಇದು ಸೂಕ್ತವಲ್ಲ, ಆದರೆ ಕನಿಷ್ಠ ಬೋಟ್ ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿತು ಮತ್ತು ಮತ್ತೆ ನನಗೆ ಲೇಖನಗಳನ್ನು ಕಳುಹಿಸಲು ಪ್ರಾರಂಭಿಸಿತು, ಮತ್ತು ಕೋಡ್‌ನಲ್ಲಿ ಏನಾಗುತ್ತಿದೆ ಎಂದು ನಾನು ನಿಧಾನವಾಗಿ ಕಂಡುಕೊಂಡೆ.

ಈಗ ನೀವು ಪ್ರಾರಂಭಕ್ಕೆ ಹಿಂತಿರುಗಬಹುದು ಮತ್ತು ರೆಪೊಸಿಟರಿಯನ್ನು ಮೂಲತಃ ನನ್ನಿಂದ ರಚಿಸಲಾಗಿಲ್ಲ ಎಂದು ನೆನಪಿಡಿ. ಏನು ಹೀಗೆ ಹೋಗಿರಬಹುದು? ನನ್ನ ಪುಲ್ ವಿನಂತಿಯನ್ನು ತಿರಸ್ಕರಿಸಲಾಗಿದೆ. ನಾನು ರೆಡ್‌ನೆಕ್ ಕೋಡ್ ಅನ್ನು ಹೊಂದಿದ್ದೇನೆ, ತಂಡದಲ್ಲಿ ಹೇಗೆ ಕೆಲಸ ಮಾಡಬೇಕೆಂದು ನನಗೆ ತಿಳಿದಿಲ್ಲ, ಮತ್ತು ಪ್ರಸ್ತುತ ಅನುಷ್ಠಾನದ ರೇಖೆಯಲ್ಲಿ ನಾನು ದೋಷಗಳನ್ನು ಸರಿಪಡಿಸಬೇಕಾಗಿತ್ತು ಮತ್ತು ಅದನ್ನು ಬಳಸಬಹುದಾದ ಸ್ಥಿತಿಗೆ ಪರಿಷ್ಕರಿಸಲಿಲ್ಲ.

ನಾನು ಅಸಮಾಧಾನಗೊಂಡಿದ್ದೇನೆ ಮತ್ತು ಕಮಿಟ್ ಇತಿಹಾಸ ಮತ್ತು ಬರೆದ ಕೋಡ್ ಮೊತ್ತವನ್ನು ನೋಡಿದೆ. ನಾನು ಮೂಲತಃ ಚೆನ್ನಾಗಿ ಬರೆದ ಕ್ಷಣಗಳನ್ನು ನೋಡಿದೆ, ಮತ್ತು ನಂತರ ಮುರಿದುಬಿತ್ತು...

ಅದನ್ನು ಎಫ್*ಆರ್ಕ್ ಮಾಡಿ

ನನಗೆ ಲೇಖನ ನೆನಪಾಯಿತು ನೀವು 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. ಕಾಲಕಾಲಕ್ಕೆ RSS ಫೀಡ್‌ಗೆ ಭೇಟಿ ನೀಡುವ ನಟ, ಹೊಸ ಲೇಖನಗಳ ಬಗ್ಗೆ ತಿಳಿದುಕೊಳ್ಳುತ್ತಾನೆ, ಲಿಂಕ್‌ಗಳನ್ನು ನೋಡುತ್ತಾನೆ, ಪಾರ್ಸ್ ಮಾಡುತ್ತಾನೆ ಮತ್ತು ಈ ಲೇಖನಗಳನ್ನು ಮೊದಲ ನಟನಿಗೆ ಕಳುಹಿಸುತ್ತಾನೆ. ಜೊತೆಗೆ, ಇದು ಕೆಲವೊಮ್ಮೆ ಮೊದಲ ನಟನಿಂದ ಲೇಖನಗಳ ಪಟ್ಟಿಯನ್ನು ವಿನಂತಿಸುತ್ತದೆ, ಮೂರು ದಿನಗಳಿಗಿಂತ ಹಳೆಯದನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ, ಆದರೆ ದೀರ್ಘಕಾಲದವರೆಗೆ ನವೀಕರಿಸಲಾಗಿಲ್ಲ ಮತ್ತು ಅವುಗಳನ್ನು ನವೀಕರಿಸುತ್ತದೆ.
3. ಟೆಲಿಗ್ರಾಮ್‌ನೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುವ ನಟ. ನಾನು ಇನ್ನೂ ಸಂದೇಶವನ್ನು ಪಾರ್ಸಿಂಗ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಇಲ್ಲಿಗೆ ತಂದಿದ್ದೇನೆ. ಸೌಹಾರ್ದಯುತ ರೀತಿಯಲ್ಲಿ, ನಾನು ಅದನ್ನು ಎರಡಾಗಿ ವಿಂಗಡಿಸಲು ಬಯಸುತ್ತೇನೆ - ಇದರಿಂದ ಒಬ್ಬರು ಒಳಬರುವ ಸಂದೇಶಗಳನ್ನು ಪಾರ್ಸ್ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ಎರಡನೆಯದು ಕಳುಹಿಸದ ಸಂದೇಶಗಳನ್ನು ಮರು-ಕಳುಹಿಸುವಂತಹ ಸಾರಿಗೆ ಸಮಸ್ಯೆಗಳೊಂದಿಗೆ ವ್ಯವಹರಿಸುತ್ತದೆ. ಈಗ ಯಾವುದೇ ಮರು-ಕಳುಹಿಸುವಿಕೆ ಇಲ್ಲ, ಮತ್ತು ದೋಷದಿಂದಾಗಿ ಬರದ ಸಂದೇಶವು ಸರಳವಾಗಿ ಕಳೆದುಹೋಗುತ್ತದೆ (ಅದನ್ನು ಲಾಗ್‌ಗಳಲ್ಲಿ ಗಮನಿಸದ ಹೊರತು), ಆದರೆ ಇಲ್ಲಿಯವರೆಗೆ ಇದು ಯಾವುದೇ ಸಮಸ್ಯೆಗಳನ್ನು ಉಂಟುಮಾಡಿಲ್ಲ. ಒಂದು ಗುಂಪಿನ ಜನರು ಬೋಟ್‌ಗೆ ಚಂದಾದಾರರಾಗಿದ್ದರೆ ಮತ್ತು ನಾನು ಸಂದೇಶಗಳನ್ನು ಕಳುಹಿಸುವ ಮಿತಿಯನ್ನು ತಲುಪಿದರೆ ಬಹುಶಃ ಸಮಸ್ಯೆಗಳು ಉದ್ಭವಿಸಬಹುದು).

ನಾನು ಇಷ್ಟಪಟ್ಟದ್ದು ಅಕ್ಕನಿಗೆ ಧನ್ಯವಾದಗಳು, ನಟರು 2 ಮತ್ತು 3 ರ ಫಾಲ್ಸ್ ಸಾಮಾನ್ಯವಾಗಿ ಬೋಟ್ನ ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ. ಬಹುಶಃ ಕೆಲವು ಲೇಖನಗಳನ್ನು ಸಮಯಕ್ಕೆ ನವೀಕರಿಸಲಾಗಿಲ್ಲ ಅಥವಾ ಕೆಲವು ಸಂದೇಶಗಳು ಟೆಲಿಗ್ರಾಮ್ ಅನ್ನು ತಲುಪುವುದಿಲ್ಲ, ಆದರೆ ಖಾತೆಯು ನಟನನ್ನು ಮರುಪ್ರಾರಂಭಿಸುತ್ತದೆ ಮತ್ತು ಎಲ್ಲವೂ ಕೆಲಸ ಮಾಡುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತದೆ. ಟೆಲಿಗ್ರಾಂ ನಟರು ಸಂದೇಶವನ್ನು ಯಶಸ್ವಿಯಾಗಿ ತಲುಪಿಸಿದ್ದಾರೆ ಎಂದು ಪ್ರತಿಕ್ರಿಯಿಸಿದಾಗ ಮಾತ್ರ ಲೇಖನವನ್ನು ಬಳಕೆದಾರರಿಗೆ ತೋರಿಸಲಾಗುತ್ತದೆ ಎಂಬ ಮಾಹಿತಿಯನ್ನು ನಾನು ಉಳಿಸುತ್ತೇನೆ. ನನಗೆ ಬೆದರಿಕೆ ಹಾಕುವ ಕೆಟ್ಟ ವಿಷಯವೆಂದರೆ ಸಂದೇಶವನ್ನು ಹಲವಾರು ಬಾರಿ ಕಳುಹಿಸುವುದು (ಅದನ್ನು ತಲುಪಿಸಿದರೆ, ಆದರೆ ದೃಢೀಕರಣವು ಹೇಗಾದರೂ ಕಳೆದುಹೋಗಿದೆ). ತಾತ್ವಿಕವಾಗಿ, ಮೊದಲ ನಟನು ತನ್ನೊಳಗೆ ರಾಜ್ಯವನ್ನು ಸಂಗ್ರಹಿಸದಿದ್ದರೆ, ಆದರೆ ಕೆಲವು ಡೇಟಾಬೇಸ್ನೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸಿದರೆ, ಅವನು ಅಗ್ರಾಹ್ಯವಾಗಿ ಬೀಳಬಹುದು ಮತ್ತು ಜೀವನಕ್ಕೆ ಮರಳಬಹುದು. ನಟರ ಸ್ಥಿತಿಯನ್ನು ಪುನಃಸ್ಥಾಪಿಸಲು ನಾನು ಅಕ್ಕನ ನಿರಂತರತೆಯನ್ನು ಪ್ರಯತ್ನಿಸಬಹುದು, ಆದರೆ ಪ್ರಸ್ತುತ ಅನುಷ್ಠಾನವು ಅದರ ಸರಳತೆಯಿಂದ ನನಗೆ ಸರಿಹೊಂದುತ್ತದೆ. ನನ್ನ ಕೋಡ್ ಆಗಾಗ್ಗೆ ಕ್ರ್ಯಾಶ್ ಆಗುವುದಿಲ್ಲ - ಇದಕ್ಕೆ ವಿರುದ್ಧವಾಗಿ, ಅದನ್ನು ಅಸಾಧ್ಯವಾಗಿಸುವಲ್ಲಿ ನಾನು ಸಾಕಷ್ಟು ಪ್ರಯತ್ನಗಳನ್ನು ಮಾಡಿದ್ದೇನೆ. ಆದರೆ ಶಿಟ್ ಸಂಭವಿಸುತ್ತದೆ, ಮತ್ತು ಪ್ರೋಗ್ರಾಂ ಅನ್ನು ಪ್ರತ್ಯೇಕ ತುಣುಕುಗಳಾಗಿ ಮುರಿಯುವ ಸಾಮರ್ಥ್ಯವು ನನಗೆ ನಿಜವಾಗಿಯೂ ಅನುಕೂಲಕರ ಮತ್ತು ಪ್ರಾಯೋಗಿಕವಾಗಿ ಕಾಣುತ್ತದೆ.

ನಾನು ವಲಯ-ci ಅನ್ನು ಸೇರಿಸಿದ್ದೇನೆ ಆದ್ದರಿಂದ ಕೋಡ್ ಮುರಿದರೆ, ನೀವು ಅದರ ಬಗ್ಗೆ ತಕ್ಷಣವೇ ಕಂಡುಕೊಳ್ಳುವಿರಿ. ಕನಿಷ್ಠ, ಕೋಡ್ ಕಂಪೈಲ್ ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸಿದೆ ಎಂದರ್ಥ. ಆರಂಭದಲ್ಲಿ ನಾನು ಟ್ರಾವಿಸ್ ಅನ್ನು ಸೇರಿಸಲು ಬಯಸಿದ್ದೆ, ಆದರೆ ಇದು ಫೋರ್ಕ್ಸ್ ಇಲ್ಲದೆ ನನ್ನ ಯೋಜನೆಗಳನ್ನು ಮಾತ್ರ ತೋರಿಸಿದೆ. ಸಾಮಾನ್ಯವಾಗಿ, ಈ ಎರಡೂ ವಿಷಯಗಳನ್ನು ಮುಕ್ತ ರೆಪೊಸಿಟರಿಗಳಲ್ಲಿ ಮುಕ್ತವಾಗಿ ಬಳಸಬಹುದು.

ಫಲಿತಾಂಶಗಳು

ಈಗಾಗಲೇ ನವೆಂಬರ್ ಆಗಿದೆ. ಬೋಟ್ ಬರೆಯಲಾಗಿದೆ, ನಾನು ಅದನ್ನು ಕಳೆದ ಎರಡು ವಾರಗಳಿಂದ ಬಳಸುತ್ತಿದ್ದೇನೆ ಮತ್ತು ನಾನು ಅದನ್ನು ಇಷ್ಟಪಟ್ಟೆ. ನೀವು ಸುಧಾರಣೆಗೆ ಆಲೋಚನೆಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಬರೆಯಿರಿ. ಅದನ್ನು ಹಣಗಳಿಸುವಲ್ಲಿ ನನಗೆ ಅರ್ಥವಿಲ್ಲ - ಅದು ಕೆಲಸ ಮಾಡಲಿ ಮತ್ತು ಆಸಕ್ತಿದಾಯಕ ಲೇಖನಗಳನ್ನು ಕಳುಹಿಸಲಿ.

ಬಾಟ್ ಲಿಂಕ್: https://t.me/HabraFilterBot
ಗಿಥಬ್: https://github.com/Kright/habrahabr_reader

ಸಣ್ಣ ತೀರ್ಮಾನಗಳು:

• ಸಣ್ಣ ಪ್ರಾಜೆಕ್ಟ್ ಕೂಡ ಸಾಕಷ್ಟು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳಬಹುದು.
• ನೀವು Google ಅಲ್ಲ. ಗುಬ್ಬಚ್ಚಿಗಳನ್ನು ಫಿರಂಗಿಯಿಂದ ಶೂಟ್ ಮಾಡುವುದರಲ್ಲಿ ಅರ್ಥವಿಲ್ಲ. ಒಂದು ಸರಳ ಪರಿಹಾರವು ಹಾಗೆಯೇ ಕೆಲಸ ಮಾಡಬಹುದು.
• ಹೊಸ ತಂತ್ರಜ್ಞಾನಗಳನ್ನು ಪ್ರಯೋಗಿಸಲು ಸಾಕುಪ್ರಾಣಿ ಯೋಜನೆಗಳು ತುಂಬಾ ಒಳ್ಳೆಯದು.
• ಟೆಲಿಗ್ರಾಮ್ ಬಾಟ್ಗಳನ್ನು ಸರಳವಾಗಿ ಬರೆಯಲಾಗಿದೆ. ಇದು "ಟೀಮ್ವರ್ಕ್" ಮತ್ತು ತಂತ್ರಜ್ಞಾನದ ಪ್ರಯೋಗಗಳಿಗೆ ಇಲ್ಲದಿದ್ದರೆ, ಬೋಟ್ ಅನ್ನು ಒಂದು ವಾರ ಅಥವಾ ಎರಡು ದಿನಗಳಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ.
• ನಟ ಮಾದರಿಯು ಬಹು-ಥ್ರೆಡಿಂಗ್ ಮತ್ತು ದೋಷ-ಸಹಿಷ್ಣು ಕೋಡ್‌ನೊಂದಿಗೆ ಉತ್ತಮವಾಗಿ ಹೊಂದಿಕೊಳ್ಳುವ ಆಸಕ್ತಿದಾಯಕ ವಿಷಯವಾಗಿದೆ.
• ಓಪನ್ ಸೋರ್ಸ್ ಸಮುದಾಯವು ಫೋರ್ಕ್‌ಗಳನ್ನು ಏಕೆ ಪ್ರೀತಿಸುತ್ತದೆ ಎಂಬುದರ ರುಚಿಯನ್ನು ನಾನು ಪಡೆದುಕೊಂಡಿದ್ದೇನೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ.
• ಡೇಟಾಬೇಸ್‌ಗಳು ಉತ್ತಮವಾಗಿವೆ ಏಕೆಂದರೆ ಅಪ್ಲಿಕೇಶನ್ ಸ್ಥಿತಿಯು ಇನ್ನು ಮುಂದೆ ಅಪ್ಲಿಕೇಶನ್ ಕ್ರ್ಯಾಶ್‌ಗಳು/ಮರುಪ್ರಾರಂಭಗಳ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುವುದಿಲ್ಲ, ಆದರೆ ಡೇಟಾಬೇಸ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವುದು ಕೋಡ್ ಅನ್ನು ಸಂಕೀರ್ಣಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಡೇಟಾ ರಚನೆಯ ಮೇಲೆ ನಿರ್ಬಂಧಗಳನ್ನು ಹೇರುತ್ತದೆ.

ಮೂಲ: www.habr.com