Splync v1.5 — প্রকল্প এবং বিভাগের জন্য কাস্টমাইজেবল স্প্লিট অনুপাত

১৬ সেপ্টেম্বর, ২০২৫ এ, Splync v1.5 রিলিজ হয়েছিল — আমাদের আন্তর্জাতিক বিবাহটি অবশেষে শহরের দ্বারা গৃহীত হওয়ার চার দিন পর। এই আপডেটের আগে Splync কোনোভাবেই স্প্লিট অনুপাত কাস্টমাইজ করতে পারত না; ডিফল্টভাবে প্রতিটি খরচ সমানভাবে ভাগ করা হতো। কিন্তু v1.5-এর সাথে ব্যবহারকারীরা এখন প্রকল্প এবং বিভাগের ভিত্তিতে কাস্টম অনুপাত সেট করতে পারে। এই পরিবর্তন দম্পতি এবং বন্ধুদের তাদের শেয়ার করা খরচ এমনভাবে ভাগ করতে সক্ষম করে যা তাদের বাস্তব জীবনের প্রতিফলন ঘটায়, শুধুমাত্র সাধারণ একটি ৫০:৫০ নয়। আপনি অক্টোবর থেকে দৈনন্দিন খরচের জন্য ৬০:৪০ স্প্লিট দিয়ে একটি নতুন অ্যাকাউন্টিং প্রকল্প শুরু করতে পারেন, আর যদি মনে হয় যে আপনাদের উভয়ের পক্ষে এটি ন্যায্য, তাহলে অ্যাপার্টমেন্টের ভাড়া সমান ৫০:৫০ রাখতে পারেন। যদি মুদি সামগ্রীর জন্য ৭০:৩০ এবং ইউটিলিটির জন্য ৬২:৩৮ বেশি সঠিক মনে হয়, তাহলে আপনি এখন এই অনুপাতগুলি পৃথকভাবে নির্ধারণ করতে পারেন — বিভাগ অনুযায়ী — একই প্রকল্পের মধ্যে।

v1.5-এর সবচেয়ে দৃশ্যমান পরিবর্তন হল নতুন সদস্য ও ডিফল্ট শেয়ার বিভাগ, যেখানে আপনি প্রকল্প সদস্য যোগ করতে পারেন এবং প্রতিটি ব্যক্তির জন্য একটি ডিফল্ট শেয়ার নির্ধারণ করতে পারেন। যদি একটি প্রকল্পে দুই সদস্য থাকে, অনুপাত হতে পারে ৫০:৫০, ৪০:৬০ অথবা যা ঠিক মনে হয়। তিন সদস্যের ক্ষেত্রে, হতে পারে ৩৩.৩৩:৩৩.৩৩:৩৩.৩৪, ৫০:২৫:২৫, অথবা আপনার পছন্দের যেকোনো সংমিশ্রণ। এটি প্রকল্পের ডিফল্ট স্প্লিট হয়ে যায়। তার নিচে আপনি স্ক্রোল করে প্রতিটি বিভাগের শেয়ার সামঞ্জস্য করতে পারেন যদি আপনি প্রকল্পের ডিফল্ট থেকে আলাদাভাবে করতে চান। যখন আপনি একটি বিভাগে কাস্টম অনুপাত নির্ধারণ করেন, এর নীল অনুপাত চিহ্ন কমলা হয়ে যায় — একটি ছোট ভিজ্যুয়াল সংকেত যে বিভাগটি নিজস্ব নিয়ম ব্যবহার করছে প্রকল্প জুড়ে নয়। যদিও এই পরিবর্তন প্রকল্প সেটিংসের মধ্যে আরও বেশি নমনীয়তা যোগ করে, এটি প্রকল্প তৈরির/সম্পাদনার দৃশ্যটিকে কিছুটা জটিল করে দেয়। এটি সহায়তার জন্য, আমি প্রতিটি বিভাগে তথ্য বোতাম যোগ করেছি যাতে আপনি ছোট প্রশ্নোত্তর সহায়ক দেখতে ক্লিক করতে পারেন।

এই পরিবর্তনটি বাস্তবায়ন করা আমার চেয়ে বেশি জটিল ছিল। 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 প্রকল্প এবং বিভাগের জন্য স্প্লিট কাস্টমাইজ করতে পারে, কিন্তু এখনও পর্যন্ত প্রতি-খরচের জন্য নয়। প্রতি-খরচের অনুপাত সমর্থন করার জন্য, আমাদের একটি নতুন কাঠামোগত স্তর প্রয়োজন — মূলত প্রত্যেক খরচ কীভাবে তার শেয়ার সংরক্ষণ করে এবং গণনা করে তার আরও গভীর পুনর্লিখন। এছাড়াও আমাদের সতর্ক থাকতে হবে যে শুধুমাত্র আরও ক্ষমতা যোগ করার জন্য অ্যাপের ইন্টারফেস হঠাৎ জটিল না হয়ে যায়। এটি যতটা শোনায় তার চেয়ে বড় আপগ্রেড। আমাদের সেখানে পৌঁছানোর জন্য একটু সময় দিন। এটি আমাদের দিগন্তে আছে — এবং আমরা সেখানে পৌঁছাব। ততক্ষণে, আসুন দেখি কিভাবে নতুন প্রতি-প্রকল্প এবং প্রতি-বিভাগের অনুপাতগুলি ইতিমধ্যেই শেয়ার করা খরচকে আরও নমনীয় করে তোলে।