👨🏽‍🏭 😈 ⬆️ कार्य प्रबंधन: दोहराव कार्यों को लागू करने के लिए कुछ विकल्प 👇🏿 💅🏿 👧🏾

हमारी "साइकिल" बनाने का एक उद्देश्य, अर्थात्। betasked.ru कार्य प्रबंधन प्रणाली दोहरावदार कार्यों के सबसे सुविधाजनक लेखांकन की आवश्यकता थी, क्योंकि Google ने हमें उपयुक्त समाधान नहीं दिया था। हमारे कार्यों की विशिष्टता यह है कि उनमें से कई हैं और अधिकांश भाग के लिए उन्हें आवधिकता की बदलती डिग्री के साथ दोहराया जाता है।

इंटरनेट पर कई महान वेब-आधारित कार्य प्रबंधन सेवाएं हैं। संभवतः हर दूसरा प्रोग्रामर जो अपनी आवश्यकताओं के अनुरूप कुछ विशेष चाहता है, कुछ उपयुक्त के लिए इंटरनेट पर खोज करता है और आदर्श को न पाकर, अपना स्वयं का संस्करण लिखता है। मास मार्केट के लिए आवेदन करने वाले कार्य प्रबंधन प्रणालियों की "मृत्यु दर" भी बहुत अधिक है। यह मुझे लगता है कि दो कारक हैं - बहुत अधिक प्रतियोगिता और एक बड़ा विभाजन - किसी को समूह के काम पर जोर देने की जरूरत है, किसी को नोट रखने की जरूरत है। नतीजतन, जो लोग हर किसी को खुश करना चाहते हैं, वे सब कुछ महसूस कर सकते हैं और यह पता चलता है कि परिणामस्वरूप राक्षस कड़ी मेहनत कर रहा है।

यह पोस्ट उन लोगों को दिखाने के उद्देश्य से लिखी गई थी जो जल्द या बाद में दोहराए जाने वाले कार्यों के कार्यान्वयन, संभावित कठिनाइयों (कम से कम हमारे द्वारा सामना किए गए) और विकल्पों को लेते हैं। पद का एक संक्षिप्त (और स्पष्ट रूप से, अक्सर भूल जाने वाला) निष्कर्ष: यह हमेशा "हेड-ऑन" समस्या को हल करने के लिए सार्थक नहीं है जब आप विकास कर रहे हैं, तो अक्सर रुकें और विश्लेषण करें कि आप क्या कर रहे हैं और आप वहां जा रहे हैं या नहीं।

आगे देखते हुए, मैं कहूंगा कि दोहराए जाने वाले कार्यों के कार्यान्वयन में बहुत समय और प्रयास लगा, लेकिन अंततः मुझे पूरी तरह से प्रयोग करने योग्य विकल्प में आने की अनुमति दी, साथ ही साथ कई अन्य कठिन मुद्दों को हल किया।

जिन प्रणालियों पर हमने उस समर्थित दोहराए गए कार्यों को देखा, उनमें कुछ कमियां थीं, जो कुछ महत्वहीन थीं, लेकिन हमारे लिए महत्वपूर्ण थीं:

या तो भविष्य के कार्यों को देखना असंभव था
या तो उनके विन्यास और उपयोग के लिए तंत्र बहुत बोझिल था

MyLifeOrganized कार्य पुनरावृत्ति के संदर्भ में सबसे उन्नत प्रणाली बन गई, लेकिन यह एक वेब एप्लिकेशन नहीं है। सी लीडटैस्क भी एक साथ विकसित नहीं हुआ, हालांकि इंटरफ़ेस के कई दृष्टिकोण खराब नहीं हैं।

इसलिए, कार्य को दोहरावदार बनाना था। ऐसा लगता है कि जटिल होगा? डेटाबेस डिजाइन के दृष्टिकोण से, विकल्पों में से एक को चुनने का सवाल था:

एक दोहराए जाने वाले कार्य का प्रत्येक उदाहरण एक अलग कार्य है और कार्य तालिका में एक अलग प्रविष्टि है
एक दोहराए जाने वाले कार्य के लिए एक टेम्पलेट को अलग से संग्रहीत किया जाता है, साथ ही ऐसे कार्य जिनके लिए फ़ील्ड बदल दिए गए हैं, उन्हें अलग से संग्रहीत किया जाता है। Google कैलेंडर में एक समान भंडारण तंत्र लागू किया जाता है - उदाहरण के लिए, जब किसी घटना के क्षेत्र को बदलते हैं, तो सवाल उठता है - पूरी श्रृंखला, केवल बाद की घटनाओं या केवल एक को बदलें।

हमने दूसरे विकल्प को सबसे तार्किक और इष्टतम माना, लेकिन यह तभी इष्टतम है जब कार्य के लिए कुछ क्षेत्र (अच्छी तरह से, या पैरामीटर) हों, लेकिन यदि आपको तर्क को सही ढंग से बनाए रखने की आवश्यकता है, तो कोड की मात्रा, उदाहरण के लिए, डीबी ट्रिगर बहुत बड़ी है। उन्होंने लिखा और लिखा, समय में बंद कर दिया। पहला विकल्प बना रहा।

इसके नुकसान इस प्रकार थे:

कार्य तालिका में बड़ी मात्रा में प्रविष्टियाँ। उदाहरण के लिए, एक कार्य है, इसे हर सप्ताह दोहराया जाना चाहिए, इसलिए प्रत्येक रविवार के लिए एक अलग कार्य है। पुनरावृत्तियों की अंतिम तिथि तक उपयोगकर्ता के लिए कोई डिफ़ॉल्ट प्रतिबंध नहीं थे। यानी "कार्य शेड्यूल" बनाते समय, इसकी प्रतियां आगे वर्ष के लिए बनाई गई थीं। लेकिन यह वक्र का भी एक प्रकार है - किसी को अभी तक योजना बनाने की आवश्यकता नहीं है, और किसी के लिए यह पर्याप्त नहीं है। ठीक है, हमने उपयोगकर्ता को यह निर्धारित करने की क्षमता जोड़ी है कि कार्यों को अग्रिम में कब तक बनाया जाएगा।
इस दृष्टिकोण में, इस तथ्य से मिलकर कि प्रत्येक आवश्यक तिथि के लिए कार्य का एक अलग उदाहरण बनाया गया था, कभी-कभी अव्यावहारिक था। उदाहरण के लिए, अलग-अलग तिथियों के साथ एक ही प्रशिक्षण कार्यों के एक समूह को ध्यान में रखने के लिए उपयोगकर्ता को संग्रहीत करने और मजबूर करने के लिए परेशान क्यों करें?

इसके अलावा, उपयोगकर्ता और प्रोग्रामर दोनों के लिए दोहराए जाने वाले कार्यों की "चेन" सर्विसिंग की जटिलता के अनुरूप नहीं थी। उदाहरण के लिए, छोटे, लेकिन समय लेने वाले प्रश्न हैं:

कार्यों को हटाते समय, यह आवश्यक था कि श्रृंखला का पुनर्निर्माण करते समय (उदाहरण के लिए, यदि उपयोगकर्ता ने रिपीट सेटिंग्स को बदल दिया है), दूरस्थ कार्य को फिर से बनाया नहीं जाएगा। सभी संभावित विकल्पों के माध्यम से जाने के बाद, यह पता चला कि सबसे उपयुक्त एक अलग तालिका में दूरस्थ कार्यों के बारे में जानकारी संग्रहीत करना है। लेकिन अनुभव ने सुझाव दिया है कि इस जानकारी के लिए एक अलग तालिका का चयन एक गलत दृष्टिकोण का संकेत है और यह वापस आ जाएगा। परिणामस्वरूप, हमने उपयोगकर्ता को शेड्यूल में परिवर्तन को बचाने के लिए एक पैरामीटर बनाया - दूरस्थ कार्यों को फिर से बनाने या नहीं करने के लिए।
कार्य श्रृंखला में एक टेम्पलेट होना चाहिए, अर्थात एक कार्य, जिसका पुनरावृत्ति उपयोगकर्ता द्वारा कॉन्फ़िगर किया गया है और जो, संक्षेप में, सभी बनाए गए नए उदाहरणों के लिए कॉपी किया गया है। यह देखते हुए कि कार्य की तारीख एक वैकल्पिक पैरामीटर है, किसी कार्य को दोहराना संभव है, जिसकी कोई तिथि नहीं है, अर्थात्। एक टेम्प्लेट कार्य (एक तारीख के बिना) और उसके पुनरावृत्ति होंगे (उनके पास पहले से ही उनकी तारीखें हैं)। लेकिन इस का व्यावहारिक उपयोग बल्कि असुविधाजनक है, क्योंकि काम पर यह सब कुछ बोझिल लगता है - एक टेम्पलेट, कार्य उदाहरण। आप एक सहायता के बिना समझ नहीं पाएंगे।
कार्य सूचियों के वृक्ष जैसी प्रकृति को ध्यान में रखते हुए, मैं उपयोगकर्ता को सीमित नहीं करना चाहता और मुझे विभिन्न माता-पिता / कार्यों को दोहराए जाने वाले कार्यों के विभिन्न उदाहरणों को वितरित करने की अनुमति देता हूं। लेकिन फिर एक और समस्या सामने आई - उपयोगकर्ता पूरी श्रृंखला को कैसे देखेगा, या समस्या केवल यह नहीं थी, बल्कि यह तथ्य कि कार्य के ये भविष्य के उदाहरण मेरी राय में दिखाई दिए, न कि जहां उपयोगकर्ता यह अपेक्षा करता है।

प्रयोज्य का मुद्दा एक अलग मुद्दा बन गया है - तिथि को छोड़कर, कार्य के विभिन्न उदाहरणों की पहचान कैसे करें? यानी कार्य सूची में, हमारे पास समान कार्यों का एक समूह है जो केवल तिथि में भिन्न होते हैं। यह स्पष्ट रूप से पोस्ट के शीर्षक चित्र में देखा जा सकता है।

यह स्पष्ट हो गया कि उपयोगकर्ता को कार्य के प्रत्येक उदाहरण के नाम को संपादित करने की अनुमति देना आवश्यक है। पहले, इसे प्रतिबंधित कर दिया गया था, क्योंकि जैसा कि आप इसे नाम देते हैं - तब शैतान यह पता लगाएगा कि पुनरावृत्ति कहां है। हमने समस्या के अधिकांश मुख्य क्षेत्रों के लिए ऐसा अवसर (अलग परिवर्तन) जोड़ा है। लेकिन यह भी वास्तव में प्रयोज्य में सुधार नहीं करता है।
हमने फैसला किया कि कार्यों को अधिक दृश्य बनाने के लिए सबसे अच्छा समाधान ऑटो-प्रतिस्थापन के साथ विकल्प होगा। अर्थात्, कार्य नाम में संकेत, उदाहरण के लिए, "%% this.date.month %%", इस अभिव्यक्ति को स्क्रीन पर प्रदर्शित होने पर महीने के नाम से बदल दिया जाएगा। यदि हम कार्य को "एटीपी एलएलसी की रिपोर्टिंग %% के लिए टैक्स के लिए कहते हैं। इस तिमाही में।%% प्रति qv %% यह। Date.month.prev.year %% g", हमें निम्न चित्र मिलता है:

यह पहले से ही एक पूर्ण निर्णय था। संभावित अभिव्यक्तियों के लिए विकल्पों का एक गुच्छा तैयार करने के बाद, हमने महसूस किया कि यह केवल शुरुआत थी। ऑटो-प्रतिस्थापन को हर जगह काम करना चाहिए, जब स्क्रीन पर, भेजे गए सूचनाओं में प्रदर्शित किया जाता है, इसलिए उन्होंने इस "हैक" के कार्यान्वयन पर एक महीने से अधिक समय तक मार डाला। हमने इसे लगभग हर जगह ध्यान में रखा। लेकिन फिर भी, कार्य पुनरावृत्ति फ़ंक्शन के लिए सेटिंग्स की संख्या बहुत बड़ी थी। हर हफ्ते बस "प्रशिक्षण" कार्य को दोहराने के लिए बहुत सारे जोड़तोड़ की आवश्यकता होती है।

संक्षेप में, यह किसी प्रकार का राक्षसी तंत्र निकला, जिसे बनाए रखना मुश्किल था और मदद के बिना उपयोगकर्ता के लिए समझ से बाहर था।

इसलिए, हमने इस तंत्र को छोड़ने का फैसला किया, और ट्रिगर के माध्यम से कार्यों की पुनरावृत्ति को लागू करने का प्रयास किया, क्योंकि यह अधिक दिलचस्प था। इसमें क्रांतिकारी कुछ भी नहीं था, क्योंकि संबंध में ट्रिगर और न केवल डेटाबेस लंबे समय से मौजूद हैं, लेकिन मैं यह देखना चाहता था कि इसके बारे में क्या आया था।

हमने इस तरह का कार्यान्वयन करने का फैसला किया - भले ही प्रत्येक विशिष्ट उपयोगकर्ता ऑपरेशन के लिए एक कार्य के साथ एक विशिष्ट कार्रवाई स्वचालित रूप से की जाएगी। यह है कि, प्रत्येक के साथ:

कार्य निर्माण
एक कार्य पूरा करना
किसी कार्य को हटाना

हम अनुकूलित कर सकते हैं

कार्य निर्माण (यह फ़ंक्शन अस्थायी रूप से अक्षम था)
कार्य को पूर्ण के रूप में चिह्नित करना
कार्य को बकाया के रूप में चिह्नित करना
कार्य हटाएँ

ठीक दोहराव को लागू करने के लिए, कार्रवाई के निष्पादन में एक अनुकूलन योग्य देरी करना आवश्यक था, उदाहरण के लिए, 10 दिनों के बाद कार्य पूरा करने के बाद, फिर से इसे अधूरा करना।

अब यह निश्चित अवधि के माध्यम से कार्य की पुनरावृत्ति का एहसास करने के लिए निकला, जो पिछले निष्पादन के क्षण से गिना गया था। यह स्पष्ट हो गया कि ट्रिगर्स के साथ विकल्प बहुत अधिक लचीला है, इसलिए निम्नलिखित "सुविधाएँ" जोड़ी गईं:

एक विशिष्ट समय पर ट्रिगर। यानी नियमित अंतराल पर ट्रिगर किया गया। प्रत्यक्ष उद्देश्य एक निश्चित आवधिकता के साथ कार्यों को "पुनर्स्थापित" करना है। उदाहरण के लिए, प्रत्येक शनिवार को "पिकनिक के लिए खरीदारी" कार्य को अधूरा बनाने के लिए
कार्य दिनांक या नियत दिनांक (कार्य पूर्ण होने की तारीख) के समय आग लगने वाली ट्रिगर को। इसका मुख्य उद्देश्य सूचनाओं के लिए पाया गया (उस समय तक हमने सूचनाओं के कार्यान्वयन को नहीं लिया था, और यह बहुत उपयोगी था), एक कस्टम देरी के साथ मिलकर, इसने प्रत्येक कार्य के लिए कई सूचनाएं देना संभव बना दिया, उदाहरण के लिए, जब एक ई-मेल के साथ आ रहा था। आवधिकता की डिग्री
प्रत्येक ट्रिगर के लिए, कार्य "मूव टास्क डेट" संभव हो गए थे। यह उन कार्यों के लिए अनुमति देता है जिनके लिए तिथि महत्वपूर्ण है, प्रत्येक पुनरावृत्ति के साथ इसे स्थानांतरित करने के लिए। हमने "कार्य अवधि" क्षेत्र के साथ भी ऐसा ही किया।

नतीजतन, हमें एक काफी लचीला और अनुकूलन योग्य सिस्टम मिला, लेकिन फिर से उसी समस्या पर लौट आया - उपयोगकर्ता को इसे बहुत लंबे समय तक कॉन्फ़िगर करना होगा। एक साधारण साप्ताहिक पुनरावृत्ति स्थापित करने के लिए, बहुत सारे हेरफेर करने पड़े।

इस समस्या को हल करने के लिए, हमने ट्रिगर को तुरंत स्थापित करने की क्षमता जोड़ी:

सभी उपयोगकर्ता कार्य
एक विशिष्ट सूची से सभी कार्य
एक विशिष्ट लेबल के साथ सभी कार्य

और यह ठीक एक निश्चित लेबल के साथ कार्यों पर ट्रिगर स्थापित करने की संभावना थी जिसने हमारे लिए जीवन को बहुत आसान बना दिया। अब, एक विशिष्ट कार्य की पुनरावृत्ति को कम कर दिया गया:

एक विशिष्ट लेबल पर ट्रिगर सेट करना। यानी लेबल "साप्ताहिक शनिवार को" बनाया गया था, इसके लिए एक ट्रिगर कॉन्फ़िगर किया गया था, जिसने इस लेबल के साथ सभी कार्यों को चिह्नित किया था जो शनिवार को पूरा नहीं हुए थे। यह सेटिंग्स में एक बार या अधिक चढ़ने के बाद कभी भी किया जा सकता है।
वांछित कार्यों के लिए इस लेबल को सेट करें।

वह सब है। एक बार और पुनरावृत्ति के सभी आवश्यक सिद्धांतों के लिए खुद को स्थापित करने के बाद ("मासिक पर 20," "8 मार्च को वार्षिक रूप से," सोमवार "), तो आप बस इन लेबल के साथ आवश्यक कार्यों को चिह्नित कर सकते हैं और सभी पुनरावृत्ति नियम उन पर लागू होते हैं।

बेशक, कई अनसुलझे मुद्दे बने रहे, कुछ पूरी तरह से लागू नहीं किया गया था (उदाहरण के लिए, पुनरावृत्ति अवधि का लचीला समायोजन), लेकिन अधिकांश व्यावहारिक कार्यों के लिए यह पहले से ही पर्याप्त था, उसी समय, कार्यों की प्रस्तुति बहुत अधिक दृश्य बन गई। हां, आरंभिक सेटिंग्स के लिए, आपको थोड़ा समझने की जरूरत है, लेबल के लिए संपादन ट्रिगर्स सेटिंग मेनू - ग्लोबल ट्रिगर या इस लेबल के साथ किसी भी कार्य के लिए ट्रिगर संदर्भ मेनू आइटम के माध्यम से उपलब्ध है। भविष्य में, हम नए उपयोगकर्ताओं के लिए आवधिक कार्यों के लिए पूर्व-कॉन्फ़िगर लेबल के साथ जीवन को आसान बना देंगे।

उन 1-2 उपयोगकर्ताओं के लिए जिन्हें ट्रिगर्स के कार्यान्वयन और आवधिक पुनरावृत्ति स्थापित करने के बारे में व्यावहारिक जानकारी की आवश्यकता है (और इसकी आवश्यकता न केवल कार्य प्रबंधन में हो सकती है, बल्कि शेड्यूलिंग में भी हो सकती है, उदाहरण के लिए), मैं योजनाबद्ध रूप से तकनीकी पक्ष का वर्णन करूंगा।

कार्यान्वयन के बारे में संक्षेप में

हैरानी की बात है, हमारे सिस्टम में ट्रिगर्स का कार्यान्वयन पोस्टग्रेक्यूएल डेटाबेस ट्रिगर्स पर आधारित है। PostgreSQL ट्रिगर्स और प्रक्रियाओं के स्रोत को पोस्ट करने से शायद कोई मतलब नहीं है (इसके अलावा उनमें से बहुत सारे हैं), क्योंकि मुख्य मूल्य डेटाबेस संरचना है, कम से कम मेरे लिए, इस व्यवसाय को लिखने के लिए खरोंच से नीचे बैठकर, यह सबसे महत्वपूर्ण होगा और बहुत समय बचाएगा।

तालिका ट्रिगर्स_टाइप करती है । यह केवल संभावित प्रकार के ट्रिगर्स के बारे में जानकारी संग्रहीत करता है ("जब कार्य पूरा हो जाता है", "जब कार्य नियत होता है", "जब कार्य नियत हो", ...)।

तालिका क्रियाएँ । यह ट्रिगर के ट्रिगर होने पर संभावित प्रकार की क्रियाओं के बारे में जानकारी संग्रहीत करता है ("कार्य हटाएं", "मार्क पूरा हुआ", "कार्य पूरा होने की तारीख को स्थानांतरित करें" ...)।

टेबल ट्रिगर । कॉन्फ़िगर किए गए ट्रिगर के विवरण शामिल हैं, अर्थात्:
- ट्रिगर_आईडी uuid - पहचानकर्ता
- trig_obj uuid - ऑब्जेक्ट के लिए लिंक (कार्य, सूची, उपयोगकर्ता, ...)
- trig_action varchar - क्रिया का प्रकार
- ट्रिगर_परम 1, ट्रिगर_परम 2 - अतिरिक्त मापदंडों के लिए फ़ील्ड (उदाहरण के लिए, अधिसूचना पर विषय और संदेश पाठ)
- trig_type varchar - ट्रिगर प्रकार, अर्थात्। क्या काम करता है
- trig_dparam1, trig_dparam2 - अतिरिक्त मापदंडों के लिए पूर्णांक फ़ील्ड
- ट्रिगर_नाम - कस्टम नाम
- trig_chk पूर्णांक - मापदंडों का चेकसम
- trig_descr - उपयोगकर्ता विवरण
- trig_offset_count पूर्णांक, ट्रिगर_offset_item - निष्पादन देरी पैरामीटर
- trig_user uuid - उपयोगकर्ता आईडी
- अंतिम जांच की तारीख ट्रिगर (3) - ट्रिगर_recreated
- trig_sch_date1, trig_sch_date2 - पुनरावृत्ति की शुरुआत और समाप्ति की तारीख ("अनुसूचित" ट्रिगर के लिए)
- trig_sch_period, trig_sch_interval, trig_sch_count - पुनरावृत्ति आवृत्ति के लिए सेटिंग्स ("अनुसूचित" ट्रिगर के लिए)

सरल ट्रिगर्स (निष्पादन में देरी के बिना) को लागू करने के लिए, बस ट्रिगर्स टेबल पर्याप्त होगी। यही है, कुछ घटनाओं को रोकना (एक कार्य बनाना, समय की शुरुआत, एक कार्य पूरा करना), हम बस इस तालिका में उपयुक्त ट्रिगर्स के माध्यम से खोज करते हैं और क्रियाएं करते हैं।

विलंबित ट्रिगर का उपयोग करने के लिए, अर्थात विलंब के साथ क्रियाएं करना, हमें एक अलग तालिका एक्शन_की आवश्यकता होती है, जिसमें समय, ऑब्जेक्ट (कार्य, सूची, ...) का लिंक और प्रदर्शन करने की आवश्यकता वाली कार्रवाई शामिल होती है। हर 5 मिनट में, क्रोन अपने किए गए कार्यों का ध्यान रखता है।

लेकिन ट्रिगर्स के साथ "जब कार्य नियत होता है" और "जब कार्य नियत होता है", विशेष रूप से सेट देरी के साथ, कार्य अधिक जटिल है। इसे हल करने के लिए, आपको एक अलग तालिका (हमारे पास ट्रिगर्स_टेबल ) भी चाहिए, जहां ऐसी सभी तिथियों के बारे में रिकॉर्ड संग्रहीत किया जाएगा, अर्थात। प्रत्येक कार्य के लिए कार्य तिथि के लिए एक अलग प्रविष्टि और कार्य अवधि के लिए एक अलग प्रविष्टि होगी। यह आवश्यक था क्योंकि एक साथ कई कार्यों पर ट्रिगर लगाए जा सकते हैं, इसलिए नियमित रूप से उन कार्यों की गणना करके सिस्टम को लोड नहीं करना है, जिसके लिए ट्रिगर को काम करना चाहिए (और लंबित ट्रिगर को ध्यान में रखते हुए, अर्थात्, एक अतिरिक्त समय बदलाव, प्लस समय क्षेत्र को ध्यान में रखते हुए, जिसे उपयोगकर्ता किसी भी समय बदल सकता है - यह एक संसाधन-गहन कार्य है), इस जानकारी को एक अलग कार्य में रखना आसान है। ठीक है, जब आप कुछ मापदंडों को बदलते हैं तो इसे ऑटो-अपडेट पर सेट करना न भूलें - ट्रिगर की सेटिंग्स, कार्य तिथियां, समय क्षेत्र।

समय क्षेत्र के बारे में। प्रत्येक उपयोगकर्ता का अपना समय क्षेत्र होता है (स्क्रीन पर प्रदर्शित होने पर सभी कार्यों को पुन: संयोजित किया जाता है), कार्यों की प्रत्येक सूची का अपना समय क्षेत्र भी हो सकता है। मुख्य कार्य तालिका (घटनाओं में, हमारे मामले में), समय क्षेत्र को निर्दिष्ट किए बिना समय को स्टोर करना बेहतर है, इससे कार्य वृक्ष के उत्पादन में महत्वपूर्ण रूप से बचत होगी। लेकिन अन्य सभी तालिकाओं में, विशेषकर ट्रिगर्स से संबंधित, यूटीसी में समय स्टोर करना बेहतर है।

कार्य प्रबंधन: दोहराव कार्यों को लागू करने के लिए कुछ विकल्प

More articles: