Splync v1.5 ले परियोजना र श्रेणी अनुसार विभाजन अनुपात अनुकूलन गर्न सक्छ
१६ सेप्टेम्बर २०२५ मा, Splync v1.5 रिलिज गरियो — हाम्रो अन्तर्राष्ट्रिय विवाहलाई सहरले अन्ततः स्वीकार गरेको चार दिनपछि। यस अपडेटभन्दा अघि, Splync विभाजन अनुपात अनुकूलन गर्न असमर्थ थियो; हरेक खर्च स्वतः बराबरीमा बाँडिन्थ्यो। v1.5 संग, प्रयोगकर्ताहरूले अब परियोजना र श्रेणी अनुसार अनुकूलन अनुपात सेट गर्न सक्छन्। यस परिवर्तनले जोडीहरू र साथीहरूलाई आफ्नो साझा खर्चहरूलाई उनीहरूको वास्तविक जीवनसँग बढी मेल खाने तरिकामा बाँड्न अनुमति दिन्छ, केवल सरल ५०:५० मात्र होइन। तपाईले अक्टुबरदेखि दैनन्दिन खर्चको लागि ६०:४० विभाजनको साथ नयाँ लेखा परियोजना सुरु गर्न सक्नुहुन्छ, जबकि तपाईंको अपार्टमेन्ट भाडा दुवैको लागि उचित लागेमा समान ५०:५० मा राख्न। र यदि खाद्य पदार्थहरूलाई ७०:३० मा बढी सन्तुलित लाग्छ भने युटिलिटी ६२:३८ मा राम्रो लाग्छ भने, तपाईले ती अनुपातहरूलाई परियोजना भित्र श्रेणी अनुसार छुट्टाछुट्टै रूपमा अब असाइन गर्न सक्नुहुन्छ।
अनुकूलन अनुपात कसरी सेट गर्ने
v1.5 मा सबभन्दा स्पष्ट परिवर्तन नयाँ सदस्य र पूर्वनिर्धारित शेयरहरू खण्ड हो, जहाँ तपाईं परियोजना सदस्यहरू थप्न सक्नुहुन्छ र प्रत्येक व्यक्तिलाई पूर्वनिर्धारित शेयर असाइन गर्न सक्नुहुन्छ। यदि कुनै परियोजनामा दुई सदस्य छन् भने, अनुपात ५०:५०, ४०:६०, वा तपाईंलाई सही लाग्छ त्यस्तै हुन सक्छ। तीन सदस्यहरू भएमा, यो ३३.३३:३३.३३:३३.३४, ५०:२५:२५ वा तपाईंले चाहेको कुनै संयोजन हुन सक्छ। यो परियोजनाको पूर्वनिर्धारित विभाजन हुन्छ। त्यसको तल, तपाईं परियोजनाको पूर्वनिर्धारितबाट फरक हुन चाहनुहुन्छ भने हरेक श्रेणीको शेयर अनुकूलन गर्न तल स्क्रोल गर्न सक्नुहुन्छ। जब तपाईं कुनै श्रेणीमा अनुकूलन अनुपात असाइन गर्नुहुन्छ, यसको निलो अनुपात चिह्न सुन्तला हुन्छ — परियोजना-व्यापी नियमको सट्टा श्रेणीको आफ्नै नियम प्रयोग गरिरहेको एक सानो दृश्य संकेत। यस परिवर्तनले परियोजना सेटिङहरूमा धेरै अधिक लचकता थप्छ, तर यसले परियोजना सिर्जना/सम्पादन दृश्यलाई केही जटिल पनि बनाउँछ। यसमा मद्दत गर्न, मैले प्रत्येक खण्डमा जानकारी बटनहरू थपें ताकि तपाईं तिनीहरूलाई थिचेर साना प्रश्नोत्तर सहायकहरू देख्न सक्नुहुन्छ।
Splync ले अनुकूलन अनुपात कसरी कार्यान्वयन गर्दछ
यस परिवर्तनलाई कार्यान्वयन गर्नु मेरो अपेक्षाभन्दा कठिन थियो। Splync ले सधैं सफा ५०:५० विश्व मान्यताको थियो — एक संख्या, हरेक ठाउँमा लागू गरिन्थ्यो, र गणित पूरा हुन्थ्यो। मैले अनुकूलन अनुपातको समर्थन गर्ने निर्णय गरेपछि, पूरै आन्तरिक संरचना पुनःविचार गर्नुपर्ने भयो। अब कुनै परियोजनाले एकल साझा प्रतिशतमा निर्भर गर्न सक्दैन। प्रत्येक श्रेणीलाई आफ्नै अनुपात आवश्यक थियो, र हरेक खर्चले परियोजना-स्तरको पूर्वनिर्धारित र श्रेणी-स्तरको ओभरराइड दुबैलाई सन्दर्भ गर्नुपर्ने भयो। यसलाई काम गर्न, मैले आधारदेखि गणना तर्कलाई पुनःलेखन गरें। अब हरेक खर्चसँग एउटा सानो निर्णय रुख हुन्छ: “के यस श्रेणीको आफ्नै अनुपात छ? यदि हो भने, त्यसलाई प्रयोग गर्नुहोस्। होइन भने, परियोजना अनुपातमा फर्कनुहोस्।” यो व्याख्या गर्दा सरल सुनिन्छ, तर एप्पभरको डेटा मोडललाई सुसंगत राख्नु — iOS दृश्यहरू, FastAPI ब्याकएन्ड, र MariaDB स्कीमाहरू — मेरो अपेक्षाभन्दा बढी सावधानीपूर्वक ट्युनिङ आवश्यक थियो।
सर्वरमा परिवर्तन गर्नु
सर्वर पक्षलाई छुनु पर्ने कुनै पनि अपडेटलाई अत्यन्त ध्यानपूर्वक ह्यान्डल गर्नुपर्छ। यदि तपाईंले गल्तीले विद्यमान सर्वर कोड परिमार्जन गर्नुभयो भने, v1.4 मा रहेका प्रयोगकर्ताहरूले तुरुन्तै बगहरू वा प्रणाली त्रुटिहरूमा सामना गर्छन्। उदाहरणका लागि, v1.5 को लागि सर्वर प्रोग्रामले परियोजना सेटिङहरूमा अनुपात डाटा समावेश गर्न अपेक्षा गर्दछ, तर v1.4 एपले कुनै अनुपात नहुने परियोजना सेटिङहरू पठाउँछ। ती दुई संस्करणहरू सन्देश गर्न खोज्ने क्षणमा नै, अनुरोध फेल हुन्छ — केवल तिनीहरू अलिकति फरक “भाषाहरू” बोल्छन्। विकासकर्ताहरूले, अवश्य पनि, परीक्षण वातावरणमा सुरक्षित रूपमा परिवर्तनहरू गर्न सक्छन्। चुनौतीपूर्ण भाग नयाँ संस्करणलाई एप्पलको समीक्षाको लागि बुझाएपछि सुरु हुन्छ जब अहिलेको प्रयोगकर्ताहरू अझै v1.4 मा छन्। बुझाउनेदेखि रिलिजसम्मको सम्पूर्ण अवधिमा, सर्वरले दुवै संस्करणलाई एकै समयमा समर्थन गर्नुपर्छ ताकि एप्पल समीक्षकहरूले v1.5 परीक्षण गर्न सकून् र विद्यमान प्रयोगकर्ताहरूले v1.4 बिना अवरोध प्रयोग गर्न जारी राख्न सकून्।
संस्करण अपडेटहरूमा अन्त बिन्दुहरू व्यवस्थापन गर्नु
एप विकासमा, “अन्त बिन्दु” भनेको एपले सर्वरमा आफ्नो अनुरोधहरू पठाउने स्थान मात्र हो — यो सहर कार्यालयको विशिष्ट काउन्टर जस्तै हो। एक काउन्टरले विवाह दर्ता ह्यान्डल गर्छ, अर्कोले आवासीय अभिलेख, र अर्कोले पासपोर्ट। एपहरू पनि यस्तै काम गर्छन्: प्रत्येक अन्त बिन्दु एक समर्पित झ्याल हो जहाँ सर्वरले लगइन, परियोजना सिर्जना, खर्च सम्पादन, मित्र अनुरोध जस्ता विशिष्ट प्रकारका अनुरोधहरू स्वीकार्छ। जब Splync v1.4 ले अनुरोध पठाउँछ, यो “पुरानो” झ्यालमा जान्छ जसले पुरानो ढाँचालाई बुझ्दछ। Splync v1.5 ले आफ्नो अनुरोध “नयाँ” झ्यालमा पठाउँछ जसले अनुपात डाटा बुझ्दछ। यदि सर्वरले पुरानो झ्याललाई चाँडै बन्द गर्यो भने, v1.4 प्रयोगकर्ताहरूको “डाटा बुझाउन” को लागि कुनै ठाँउ रहने छैन। त्यसैले, एक अपडेटको समयमा, सर्वरले दुवै झ्यालहरू खुला राख्नुपर्छ — दुवै अन्त बिन्दुहरू — जबसम्म हरेक प्रयोगकर्ता सुरक्षित रूपमा नयाँ संस्करणमा सरेका छैनन्। इमानदार बन्नु पर्दा, यी दुई झ्यालहरू एकै समयमा व्यवस्थापन गर्नु अर्को आयाममा सोच्न जस्तो लाग्थ्यो।
प्रति-खर्च विभाजनको के हुन्छ
Splync v1.5 ले परियोजना र श्रेणी अनुसार विभाजनलाई अनुकूलन गर्न सक्छ, तर अझै प्रति खर्च गर्न सकेको छैन। प्रति-खर्च अनुपात समर्थन गर्नको लागि, हामीलाई अर्को संरचनात्मक तह आवश्यक छ — प्रत्येक खर्चले आफ्नो शेयरहरू कसरी भण्डारण र गणना गर्दछ भन्ने कुराको गहिरो पुनःलेखन। हामीलाई एपको इन्टरफेसलाई अचानक जटिल नबनाउन पनि ध्यान दिनुपर्छ, केवल थप शक्ति थप्नको लागि। यो सुन्दा भन्दा ठूलो अपग्रेड हो। कृपया हामीलाई त्यहाँ पुग्न अलिकति समय दिनुहोस्। यो हाम्रो दृष्टिकोणमा छ — र हामी त्यहाँ पुग्नेछौं। तबसम्म, नयाँ परियोजना र श्रेणी अनुपातहरूले साझा खर्चहरूलाई धेरै लचकता प्रदान गरेका छन् भन्ने कुरा अन्वेषण गरौं।