कस्टम डेवलपमेंट
कुछ समस्याएँ वेबसाइट में फ़िट नहीं बैठतीं। जब काम कोई टूल हो, कोई ऐप हो, कोई इंटीग्रेशन हो, या कोई ऐसी प्रक्रिया हो जिसे अब हाथ से करना ठीक नहीं, तो हम इसकी जगह वही बनाते हैं।
छोटी टीम, अनुभवी, और स्कोप को लेकर ईमानदार। अगर कोई मौजूदा प्रोडक्ट आपकी समस्या हल कर सकता है, तो हम यह साफ़ बता देंगे, बजाय इसके कि उसे दोबारा बनाने का बिल थमा दें।
रजिस्टर
हम किस तरह का काम लेते हैं
कस्टम सॉफ़्टवेयर को समझने का एक अच्छा तरीका है, उस समस्या से जिसे वह हटाता है। ये वे पैटर्न हैं जो सबसे ज़्यादा सामने आते हैं, और जो हम अक्सर बनाकर देते हैं।
| समस्या | हम क्या बनाते हैं |
|---|---|
| एक ही मैनुअल काम, हर दिन, ऐसे व्यक्ति द्वारा जो इसके लिए बहुत अनुभवी है | एक इंटरनल टूल जिसमें सारे स्टेप्स एक बार तय हो जाते हैं: एक फ़ॉर्म, एक क्यू, एक साफ़ ऑडिट ट्रेल, और ऐसी परमिशन जो टीम के असली काम करने के तरीके से मेल खाती हों। |
| दो सिस्टम जो आपस में बात नहीं करते | एक इंटीग्रेशन जो उनके बीच की मैपिंग संभालता है, एक तरफ़ के डाउन होने पर सुरक्षित तरीके से दोबारा कोशिश करता है, और बताता है कि कब किसी इंसान की ज़रूरत है। |
| बिज़नेस एक ऐसी स्प्रेडशीट पर चल रहा है जिसे कोई छूने की हिम्मत नहीं करता | एक छोटा वेब एप्लिकेशन जिसके पीछे एक असली डेटा मॉडल हो, ताकि दो लोग एक साथ काम कर सकें और पिछली तिमाही के आँकड़े गलती से ओवरराइट न हों। |
| एक रिपोर्ट जिसे हर हफ़्ते कोई हाथ से तैयार करता है | एक शेड्यूल्ड जॉब जो डेटा जुटाती है, उसे जाँचती है, और ज़रूरतमंद लोगों तक रिपोर्ट पहुँचाती है, हर रन का रिकॉर्ड रखते हुए। |
| ऐसा काम जो डेस्क से दूर होता है: फ़ोन पर, किसी वैन में, या दुकान के फ़र्श पर | सिस्टम के बाक़ी हिस्से जैसी ही नींव पर बना एक मोबाइल ऐप, जो उसी डेटा मॉडल, उसी समीक्षा मानक और उन्हीं ऑटोमेटेड जाँच को साझा करता है, ताकि फ़ोन और डेस्कटॉप कभी तथ्यों को लेकर असहमत न हों। |
| एक ग्राहक वर्कफ़्लो जो मार्केटिंग साइट से जोड़ा गया, जब तक कि वह टूट न गया | अपने ही पते पर एक ठीक-ठाक एप्लिकेशन, जो साइट के डिज़ाइन सिस्टम को साझा करती है ताकि सब कुछ एक ही कंपनी जैसा महसूस हो। |
| कुछ ऐसा जिसकी कोई कीमत नहीं लगा सकता क्योंकि किसी ने उसका स्कोप तय ही नहीं किया | एक छोटा डिस्कवरी चरण: सबसे छोटा काम करने वाला वर्ज़न लिखित रूप में तय किया जाता है, साथ ही वे हिस्से भी साफ़-साफ़ बताए जाते हैं जिन्हें हम नहीं बनाएँगे। |
निर्णय
हम क्या बनाना है यह कैसे तय करते हैं
- पहले वह सबसे छोटी चीज़ जो काम करे। प्रोडक्शन में एक संकरा सा टूल दो हफ़्तों में उतना सिखा देता है जितना एक पूरा स्पेसिफ़िकेशन एक तिमाही में भी नहीं सिखाता, और जब पता चल जाए कि कौन सा हिस्सा मायने रखता है, तो इसे आगे बढ़ाया जा सकता है।
- जानबूझकर 'बोरिंग' टेक्नोलॉजी। हम दिलचस्प विकल्प की बजाय आज़माया-परखा विकल्प चुनते हैं। कस्टम सॉफ़्टवेयर की परख उस दिन होती है जब किसी को इसे बदलना पड़े, लॉन्च वाले दिन नहीं।
- डेटा मॉडल शुरू में ही ठीक कर लें। इंटरफ़ेस को फिर से बनाना सस्ता है, पर डेटा की बनावट बदलना महँगा, इसलिए स्क्रीन तय होने से पहले डेटा की बनावट तय की जाती है।
- बनाने से पहले खरीदने पर विचार। अगर कोई लाइसेंस्ड प्रोडक्ट आपकी ज़रूरत पूरी करता है, तो ईमानदार सलाह यही है कि उसे इस्तेमाल करें। हम उसे दोबारा बनाने का बिल थमाने की बजाय, उसे जोड़ने वाला छोटा हिस्सा बनाना पसंद करेंगे।
- दूसरे डेवलपर के लिए डिज़ाइन। पढ़ने लायक कोड, डॉक्यूमेंटेड सेटअप, ऐसे टेस्ट जो मक़सद बताएँ। काम की असली कसौटी यह है कि क्या कोई और इसे सुरक्षित तरीके से बदल सकता है।
स्टैक
हम असल में जिस तकनीक का इस्तेमाल करते हैं
इसे नाम देना स्कोप को लेकर ईमानदार होने का हिस्सा है। एक तकनीकी ख़रीदार को एक ही स्क्रीन में यह पता चल जाना चाहिए कि हम सही स्टूडियो हैं या नहीं, और एक ग़ैर-तकनीकी ख़रीदार इस सेक्शन को अपने डेवलपर को सौंपकर सीधा जवाब पा सके।
TypeScript, शुरू से आख़िर तक
Astro, सादा HTML और CSS, जहाँ किसी ऐप को ज़रूरत हो वहाँ React, और साथ ही मोबाइल ऐप
Node और Cloudflare Workers
Postgres-compatible डेटाबेस, वर्ज़न वाली SQL माइग्रेशन
Cloudflare Pages, Workers, ऑब्जेक्ट स्टोरेज, शेड्यूल्ड ट्रिगर
Playwright, Vitest, स्टैटिक टाइप्स, ऑटोमेटेड सुगम्यता ऑडिट
- पूरे सिस्टम में एक ही भाषा। इंटरफ़ेस, API, शेड्यूल्ड जॉब और टेस्ट, सबके लिए TypeScript, हर बदलाव पर टाइप-चेक के साथ। एक भाषा मतलब एक ही टूलचेन और एक ही समीक्षा मानक, और ब्राउज़र और उसके पीछे की सर्विस के बीच कोई ट्रांसलेशन लेयर नहीं।
- रेंडरिंग, हर काम के हिसाब से चुनी गई। कंटेंट स्टैटिक HTML में कंपाइल होता है। जिस इंटरफ़ेस को सच में क्लाइंट-साइड स्टेट चाहिए, उसे एक कॉम्पोनेंट फ़्रेमवर्क मिलता है, स्क्रीन के उसी हिस्से तक सीमित जिसे इसकी ज़रूरत है, न कि हर उस कंटेंट के इर्द-गिर्द लिपटा हुआ फ़्रेमवर्क जो कभी बदलता ही नहीं।
- मोबाइल ऐप, उसी अनुशासन के साथ। जहाँ काम ब्राउज़र टैब की बजाय किसी के हाथ में होना चाहिए, वहाँ हम ऐप को बाक़ी हर चीज़ जैसे ही स्तर पर बनाते हैं: वही TypeScript-पहले टूलचेन, वही समीक्षा मानक, वही ऑटोमेटेड जाँच, और पीछे की सर्विस जैसा ही डेटा मॉडल, न कि सच्चाई का एक दूसरा वर्ज़न। किसी ख़ास ऐप के लिए कौन सा स्टैक इस्तेमाल हो, यह फ़ैसला हम स्कोप लिखे जाने के दौरान आपके साथ मिलकर लेते हैं, हर प्रोजेक्ट पर थोपी गई कोई घर की पसंद नहीं।
- एक रिलेशनल डेटाबेस, दस्तावेज़ों का ढेर नहीं। एक Postgres-compatible डेटाबेस, एक टाइप्ड क्वेरी लेयर के साथ, और स्कीमा बदलाव जो समीक्षा किए जाते हैं, क्रम में लागू होते हैं और पलटे जा सकते हैं। कोई भी प्रोडक्शन स्कीमा को हाथ से एडिट नहीं करता।
- डिफ़ॉल्ट रूप से सर्वरलेस, क्योंकि भूलने के लिए कोई सर्वर ही नहीं है। कोड Cloudflare के एज प्लेटफ़ॉर्म पर चलता है, फ़ाइलों के लिए ऑब्जेक्ट स्टोरेज और समय पर चलने वाले किसी भी काम के लिए शेड्यूल्ड वर्कर के साथ। आधी रात को पैबंद लगाने के लिए आपकी कोई मशीन नहीं, और अंदाज़े से तय होने वाली कोई क्षमता नहीं।
- दस्तावेज़ीकृत इंटरफ़ेस के ज़रिए इंटीग्रेशन। दूसरे सिस्टम तक उनके API और वेबहुक के ज़रिए पहुँचा जाता है, रीट्राई, आइडेम्पोटेंसी और हर कॉल के रिकॉर्ड के साथ। जहाँ किसी प्रोवाइडर के पास कोई API न हो, वहाँ एक शेड्यूल्ड फ़ाइल या डेटा फ़ीड जानबूझकर लिया गया विकल्प है, कभी स्क्रीन स्क्रैपिंग नहीं जो अगली तिमाही टूट जाए।
- एनवायरनमेंट और सीक्रेट, कॉन्फ़िगरेशन के रूप में, कभी अनकही परंपरा के रूप में नहीं। इंफ्रास्ट्रक्चर रिपॉज़िटरी में घोषित है, क्रेडेंशियल एक सीक्रेट स्टोर में रहते हैं और चलती हुई सर्विस तक एनवायरनमेंट वैल्यू के रूप में पहुँचते हैं, और कोई नई मशीन उसी दोपहर तक प्रोजेक्ट चला सकती है।
- आपका स्टैक, अगर आपके पास पहले से एक है। अगर आपकी टीम पहले से कुछ ठीक-ठाक मेंटेन करती है, तो सही जवाब अक्सर यही है कि उसी के भीतर काम किया जाए, बजाय हर चीज़ करने का एक दूसरा तरीका शुरू करने के। और अगर आपके पास जो है वही असली समस्या है, तो यह भी आपको साफ़ बता दिया जाएगा।
मानक
वेबसाइट जैसा ही इंजीनियरिंग स्तर
दोनों सर्विस लाइनों के बीच यह स्तर नहीं बदलता, क्योंकि किसी इंटरनल टूल को सालों तक वे लोग इस्तेमाल करते हैं जिनके पास कोई और विकल्प नहीं होता। पूरे इतिहास वाली एक रिपॉज़िटरी में स्टैंडर्ड कोड, लाल डिप्लॉय को रोकने वाली ऑटोमेटेड जाँच, एक क़दम में पलटे जा सकने वाले एक-कमांड रिलीज़, सुगम्य इंटरफ़ेस (स्टाफ़ भी वही मानक पाने के हक़दार हैं जो ग्राहकों को मिलता है), कोड से बाहर रखे गए सीक्रेट, और इस सबके नीचे कोई मालिकाना प्लेटफ़ॉर्म नहीं। यह सब कॉर्पोरेट वेबसाइट के तहत विस्तार से बताया गया है, यहाँ दोहराया नहीं जा रहा।
सॉफ़्टवेयर में दो चीज़ें साइट से कहीं ज़्यादा मायने रखती हैं, और इन्हें अलग से नाम देना ज़रूरी है।
डेटा, कोड से ज़्यादा टिकता है
इंटरफ़ेस बदल दिए जाते हैं; रिकॉर्ड बने रहते हैं। इसलिए स्कीमा बदलाव रिपॉज़िटरी में माइग्रेशन के रूप में होते हैं, क्रम में लागू होते हैं और पलटे जा सकते हैं, बैकअप किसी एक बार लिखी स्क्रिप्ट का नहीं बल्कि प्लेटफ़ॉर्म का काम है, और आपका डेटा ऐसे फ़ॉर्मैट में एक्सपोर्ट किया जा सकता है जिसे कहीं और भी लोड किया जा सके।
चलता हुआ सिस्टम देखा जाना चाहिए
जो भी बिना किसी की नज़र के होता है, वह एक रिकॉर्ड छोड़ता है: क्या चला, कब, किसे छुआ और कहाँ फ़ेल हुआ। जो शेड्यूल्ड जॉब चुपचाप काम करना बंद कर दे, वह हमें बता देती है, बजाय इसके कि महीने भर बाद कोई यह सोचते हुए इसे ढूँढे कि उसकी रिपोर्ट कहाँ गई।
स्कोप
हम कहाँ रुकते हैं
अपनी सीमाओं के बारे में साफ़ रहना भरोसेमंद होने का ही एक हिस्सा है। हम एक छोटी, अनुभवी टीम हैं, इसलिए हम वही काम लेते हैं जो अच्छी तरह कर सकें, और जो नहीं कर सकते उसे मना कर देते हैं।
हम लाइसेंस्ड प्लेटफ़ॉर्म दोबारा नहीं बेचते, ऐसे प्रोजेक्ट में स्टाफ़ नहीं लगाते जिसे हम खुद नहीं बना रहे, और बिना स्कोप तय किए किसी समस्या की कीमत नहीं बताते। जहाँ काम का कोई हिस्सा किसी विशेषज्ञ का काम हो, हम आपको साफ़ बता देंगे, बजाय इसके कि यह बात आपकी क़ीमत पर पता चले।
तकनीकी सीमाएँ भी उतनी ही स्पष्ट हैं:
- किसी मॉडल का इस्तेमाल हाँ, डेटा साइंस नहीं। हम आपके एप्लिकेशन से किसी होस्टेड मॉडल या मौजूदा सर्विस को कॉल करेंगे और उसके इर्द-गिर्द इंटरफ़ेस और मशीनरी बनाएँगे। मॉडल ट्रेनिंग, सांख्यिकीय विश्लेषण और वेयरहाउस-स्तर की डेटा पाइपलाइन हमारा काम नहीं है।
- मैनेज्ड प्लेटफ़ॉर्म हाँ, आपके अपने सर्वर नहीं। हम मैनेज्ड एज और सर्वरलेस प्लेटफ़ॉर्म पर डिप्लॉय करते हैं। अगर काम आपके डेटा सेंटर में, या आपके संभाले हुए मशीनों पर चलना ही है, तो हम ग़लत स्टूडियो हैं और यह हम पहली ही कॉल पर बता देंगे।
- सर्टिफ़ाइड नियमों के लिए हमारे साथ एक विशेषज्ञ चाहिए। हम हमेशा असली सिक्योरिटी इंजीनियरिंग लागू करते हैं, पर किसी नामित नियम के ख़िलाफ़ औपचारिक ऑडिट हमारी विशेषज्ञता नहीं है। अगर आपके प्रोजेक्ट को इसकी ज़रूरत है, तो हम यह साइन करने से पहले बता देंगे, बाद में नहीं।
- फ़र्मवेयर, और दोबारा बेचना। एम्बेडेड फ़र्मवेयर हमारा विषय नहीं है, और न ही कुछ भी जिसकी वैल्यू किसी दोबारा बेचे गए लाइसेंस में हो, न कि हमारे किए गए काम में।
इसे चलाना
इसके बाद इसे कौन चलाता रहता है
कस्टम सॉफ़्टवेयर लॉन्च होते ही ख़त्म नहीं होता। इसे इस्तेमाल किया जाता है, और फिर इसे बदलना पड़ता है। इसे कौन चलाता है और कौन बदलता है, यह शुरुआत के स्कोप में ही तय हो जाना चाहिए, छह महीने बाद किसी अजीब ईमेल में नहीं।
हम इसे होस्ट करते हैं और चलाते रहते हैं
यही डिफ़ॉल्ट है: हम सिस्टम को एक मासिक शुल्क पर होस्ट और संचालित करते हैं, और लॉन्च के बाद के बदलाव भी बिल्ड जैसे ही क्रम से गुज़रते हैं, यानी एक ब्रांच, एक प्रीव्यू, जाँच का पूरा सेट, और एक ऐसा डिप्लॉय जो एक क़दम में पलटा जा सके। जिन लोगों ने इसे लिखा, वही इसे प्रोडक्शन में देखते भी रहते हैं, और यही अक्सर एक शांत फ़िक्स और यह तय करने वाली लंबी बहस के बीच का फ़र्क़ होता है कि समस्या किसकी है।
छोटी, अनुभवी टीम होने की एक क़ीमत है और हम इसे साफ़ बताना पसंद करेंगे: हम कोई 24 घंटे की ऑन-कॉल रोटेशन नहीं चलाते और मिनटों में मापा गया कोई गारंटीशुदा जवाब नहीं बेचते। अगर आप जो बना रहे हैं उसे सच में इसकी ज़रूरत है, तो जल्दी बता दीजिए और हम ईमानदारी से बताएँगे कि क्या हम इसे पूरा कर सकते हैं।
या आपकी अपनी टीम इसे संभाल ले
जहाँ आपके अनुबंध में यह शामिल हो, वहाँ सॉफ़्टवेयर आपकी अपनी होस्टिंग और आपके अपने डेवलपर के पास जा सकता है: स्टैंडर्ड कोड, टेस्ट, दस्तावेज़ीकृत सेटअप, और एक ऐसा डिप्लॉय जो सिर्फ़ एक कमांड है। यही असल में ऊपर बताए गए "दूसरे डेवलपर के लिए डिज़ाइन" का मक़सद है। जब आप चाहें तो हम इसे लिखित रूप में एक विकल्प के तौर पर देते हैं, यह डिफ़ॉल्ट व्यवस्था नहीं है।
यहाँ भी प्लेटफ़ॉर्म मदद करता है। एक स्टैटिक साइट और एक सर्वरलेस सर्विस के पास पैबंद लगाने के लिए कोई सर्वर नहीं होता, इसलिए जो बचता है वह है डिपेंडेंसी और प्लेटफ़ॉर्म अपडेट: एक शेड्यूल्ड, जाँची जा सकने वाली तब्दीली, न कि कोई इमरजेंसी।
शुरू करने के लिए किसी स्पेसिफ़िकेशन की ज़रूरत नहीं। हमसे संपर्क फ़ॉर्म या sales@wwi.dev पर संपर्क करें और काम को सीधी भाषा में बताएँ।