सेवा
कस्टम डेस्कटॉप एप्लिकेशन डेवलपमेंट
उस काम के लिए जो ब्राउज़र टैब ठीक से नहीं कर पाता।
डेस्कटॉप एक सोचा-समझा चुनाव है, पुरानेपन की निशानी नहीं। यह तब सही है जब काम ज़्यादा मात्रा वाली कीबोर्ड डेटा एंट्री हो, जब स्थानीय हार्डवेयर शामिल हो — तौल मशीनें, प्रिंटर, स्कैनर, बायोमेट्रिक रीडर — या जब सॉफ़्टवेयर को इंटरनेट बंद होने पर भी चलते रहना हो। Windows के लिए बनाया गया, क्योंकि यह काम ज़्यादातर वहीं होता है।
फ़ैसला
यह कब सही फ़ैसला है।
लगभग सब कुछ ब्राउज़र में चला गया है, और ज़्यादातर मामलों में यह सही भी है। तीन चीज़ें ठीक से नहीं गईं। पहली है सघन, कीबोर्ड-चालित डेटा एंट्री: दिन में चार सौ वाउचर भरने वाले ऑपरेटर को ऐसा टैब क्रम, कीबोर्ड शॉर्टकट और तुरंत प्रतिक्रिया चाहिए जो वेब फ़ॉर्म शायद ही कभी दे पाता है।
दूसरी वजह हार्डवेयर है। तौल मशीनें, लेबल और डॉट-मैट्रिक्स प्रिंटर, कीबोर्ड-वेज मोड वाले बारकोड स्कैनर, बायोमेट्रिक रीडर, COM-पोर्ट डिवाइस। ब्राउज़र से इन तक पहुँच या तो असंभव है या इतनी नाज़ुक कि सहायता टीम का ज़्यादातर समय उसी में जाता है।
तीसरी वजह बिना नेटवर्क के चलना है। जो काउंटर कनेक्शन टूटने पर बिल नहीं बना सकता, वह रुका हुआ काउंटर है, और बहुत से कारोबारों के लिए यह स्वीकार्य विफलता नहीं है। स्थानीय डेटा और बैकग्राउंड सिंक वाला डेस्कटॉप एप्लिकेशन बस चलता रहता है।
आपको क्या मिलता है
काम में क्या शामिल है।
कीबोर्ड-प्रथम डेटा एंट्री
टैब क्रम, शॉर्टकट और उसी जगह जाँच — ऐसे व्यक्ति के लिए बनाए गए जो माउस छूता ही नहीं और फ़ॉर्म उसे याद हो चुका है।
स्थानीय हार्डवेयर
तौल मशीनें, लेबल प्रिंटर, डॉट-मैट्रिक्स बिलिंग, स्कैनर और बायोमेट्रिक डिवाइस — ब्राउज़र की किसी परत के बजाय सीधे चलाए हुए।
बिना नेटवर्क के काम
एक स्थानीय डेटाबेस काम करने की जगह के रूप में, सर्वर तक पहुँच होने पर सिंक, और पहुँच न होने पर टकराव सुलझाने का स्पष्ट नियम।
मल्टी-ब्रांच सिंक
ऐसी शाखाएँ जो अलग-अलग चलती हैं और केंद्र में मिलान करती हैं, बिना हेड ऑफ़िस से स्थायी लिंक की ज़रूरत के।
सटीक गणना
पैसा हर जगह फ़िक्स्ड-पॉइंट दशमलव में। बिलिंग सिस्टम में फ़्लोटिंग पॉइंट यानी राउंडिंग का झगड़ा, जो मिलने का इंतज़ार कर रहा है।
प्रबंधित अपडेट
साइन किए, वर्ज़न वाले अपडेट, जो बिना किसी तकनीशियन के हर मशीन तक पहुँचकर लागू हो जाते हैं।
स्टैक
हम इसे किससे बनाते हैं।
हर प्रोजेक्ट के हिसाब से चुने हुए। यहाँ कुछ भी डिफ़ॉल्ट रूप से नहीं लगाया जाता, और जो टीम आगे इसे संभालेगी वह समस्या जितनी ही मायने रखती है।
एप्लिकेशन
.NET के साथ Windows के लिए WPF या WinUI, जो फ़ैशन नहीं, हार्डवेयर पहुँच और डिप्लॉयमेंट की परिपक्वता देखकर चुने गए।
स्थानीय डेटा
SQLite या SQL Server LocalDB, और ऐसा माइग्रेशन रास्ता जो ऑफ़लाइन मशीन पर स्कीमा बदलने के बाद भी टिके।
सिंक
वेब प्लेटफ़ॉर्म के साथ साझा एक API, ताकि डेस्कटॉप और ब्राउज़र क्लाइंट के कारोबारी नियम अलग-अलग न हो जाएँ।
हार्डवेयर
सीरियल, USB HID और वेंडर SDK, आपके फ़्लोर पर मौजूद असली डिवाइस पर जाँचे हुए।
डिप्लॉयमेंट
कोड-साइन किए इंस्टॉलर, अपने आप अपडेट, और ऐसा रोलबैक जो सचमुच काम करे।
तुलना
ब्राउज़र बनाम डेस्कटॉप क्लाइंट।
डेस्कटॉप कुछ ख़ास कामों के लिए सोचा-समझा चुनाव है। यहाँ देखिए किस काम में कौन सचमुच जीतता है।
| पहलू | ब्राउज़र | डेस्कटॉप क्लाइंट |
|---|---|---|
| डिप्लॉयमेंट | कुछ इंस्टॉल नहीं करना पड़ता; सब तुरंत मौजूदा वर्ज़न पर होते हैं | साइन किया हुआ इंस्टॉलर, अपने आप अपडेट, और ऐसा रोलबैक जो काम करे |
| सघन कीबोर्ड डेटा एंट्री | चल जाता है, पर शायद ही कभी उतना तेज़ जितना वह ऑपरेटर जिसे फ़ॉर्म याद हो चुका है | टैब क्रम, शॉर्टकट और तुरंत प्रतिक्रिया — दिन में चार सौ वाउचर भरने वाले के लिए बनाए गए |
| स्थानीय हार्डवेयर | तौल मशीनें, डॉट-मैट्रिक्स प्रिंटर और COM-पोर्ट डिवाइस या तो असंभव हैं या नाज़ुक | वेंडर SDK, सीरियल और USB HID के ज़रिए सीधे चलाए जाते हैं |
| जब नेटवर्क बंद हो तब भी काम | रुक जाता है, जब तक काफ़ी इंजीनियरिंग न जोड़ी जाए | स्थानीय डेटा पर चलता रहता है और लिंक लौटते ही मिलान कर लेता है |
| पहुँच | कोई भी डिवाइस, कहीं भी, फ़ोन सहित | वही मशीनें जिन पर आप इसे इंस्टॉल करते हैं, आमतौर पर Windows |
| किसके लिए सही जवाब | प्रबंधन, रिपोर्टिंग, और कोई भी मल्टी-डिवाइस या रिमोट काम | काउंटर, शॉप फ़्लोर, तौल की जगह |
यह कैसे चलता है
पहली बातचीत से लाइव होने तक।
इस तरह के काम के लिए अनुमानित। पायलट वैकल्पिक नहीं है — जब तक इस्तेमाल करने वाले यह न कहें कि यह टिकता है, कुछ भी स्विच नहीं किया जाता।
- 1 हफ़्ता
डिस्कवरी
हम असली डेटा एंट्री देखते हैं और हर उस डिवाइस की सूची बनाते हैं जिसे चलाना है। यही डिवाइस सूची अनुमान बनाती या बिगाड़ती है।
- 4-7 हफ़्ते
मुख्य निर्माण
पहले एंट्री का रास्ता और हार्डवेयर इंटीग्रेशन, और वे आपके फ़्लोर पर मौजूद डिवाइस पर जाँचे जाएँ, उनके समकक्षों पर नहीं।
- 2 हफ़्ते
काउंटर पायलट
एक काउंटर या एक मशीन इस पर चलती है जबकि मौजूदा प्रक्रिया भी चलती रहती है — तब तक, जब तक ऑपरेटर पुराने सिस्टम की ओर हाथ बढ़ाना बंद न कर दें।
- 1-3 हफ़्ते
रोलआउट
बाक़ी मशीनें, साइन किया ऑटो-अपडेट चालू, और वेब प्लेटफ़ॉर्म तक का सिंक रास्ता जानबूझकर नेटवर्क काटकर जाँचा हुआ।
लॉन्च के बाद
क्या बदलता है।
- ऑपरेटर को स्क्रीन का इंतज़ार नहीं करना पड़ता, और पूरे दिन में यही डेस्कटॉप के पक्ष की पूरी दलील है।
- कनेक्शन टूटने का मतलब काउंटर बंद होना नहीं रह जाता।
- जो हार्डवेयर पहले हाथ से चलता था, या बिल्कुल नहीं चलता था, वह रिकॉर्ड का हिस्सा बन जाता है।
- अपडेट हर मशीन तक पहुँचते हैं, बिना किसी तकनीशियन के हर जगह जाए।
जानबूझकर गुणात्मक रूप में बताया गया। हम ऐसे प्रतिशत सुधार प्रकाशित नहीं करते जिन्हें हम किसी नामित क्लाइंट से, उनकी सहमति के साथ, जोड़ न सकें।
सवाल
आम सवाल।
क्या डेस्कटॉप सॉफ़्टवेयर पुराना नहीं हो गया?
ज़्यादातर एप्लिकेशन के लिए हाँ, और हम वेब की ही सिफ़ारिश करेंगे। डेस्कटॉप सघन डेटा एंट्री, स्थानीय हार्डवेयर और बिना नेटवर्क के काम के लिए सही जवाब बना रहता है। इन वजहों से डेस्कटॉप चुनना एक इंजीनियरिंग फ़ैसला है, पुरानेपन की निशानी नहीं।
क्या यह हमारे वेब सिस्टम के साथ भी चल सकता है?
हाँ, और आमतौर पर होना भी चाहिए। आम तरीक़ा यह है कि काउंटर या शॉप फ़्लोर पर डेस्कटॉप क्लाइंट हो और प्रबंधन के लिए ब्राउज़र, दोनों एक ही API के विरुद्ध — ताकि नियम अलग-अलग न हो जाएँ।
macOS या Linux का क्या?
संभव है, और बात करने लायक़ है। इस काम की ज़्यादातर माँग Windows की है, क्योंकि हार्डवेयर ड्राइवर और मौजूदा मशीनें वहीं हैं।
अपडेट कैसे संभाले जाते हैं?
साइन किए अपडेट अपने आप पहुँचते हैं और रीस्टार्ट पर लागू होते हैं, वर्ज़न एप्लिकेशन में दिखता है, और रिलीज़ बिगड़ने पर वापस लौटने का रास्ता रहता है।
क्या डेस्कटॉप ऐप और वेब सिस्टम एक ही डेटाबेस साझा कर सकते हैं?
उन्हें डेटाबेस नहीं, एक API साझा करना चाहिए। दो क्लाइंट का सीधे एक ही टेबल में लिखना ही वह तरीक़ा है जिससे कारोबारी नियम अलग-अलग हो जाते हैं; बीच में एक API होने का मतलब है कि काउंटर और ब्राउज़र के नियम अलग हो ही नहीं सकते।
अगर कोई मशीन एक हफ़्ते से ऑफ़लाइन रही हो तो क्या होता है?
वह स्थानीय डेटा पर चलता रहता है और दोबारा जुड़ने पर मिलान कर लेता है — उस टकराव नियम के तहत जो डिस्कवरी में चुना गया था, न कि उस पर छोड़ दिया गया जो कोड डिफ़ॉल्ट रूप से करता है। जो कुछ भी सचमुच अस्पष्ट हो, वह चुपचाप सुलझाने के बजाय किसी व्यक्ति के सामने रखा जाता है।