Splync v1.9 Maaari nang Mag-set ng Custom Sharing Ratios para sa Bawat Gastos

Mga isa't kalahating buwan pagkatapos ilabas ang Splync v1.5 — ang update na sa wakas ay pumayag sa custom split ratios per project at per category — isang bagong alon ng feedback ang dumating. Ang update na v1.5 ay nangangailangan ng malaking pagbabago sa server-side, kaya noong panahong iyon, akala ko sapat na ang granularity para sa karamihan ng mga kaso. Pagkatapos ay may ilang bagong user na nagtanong ng isang simple, at makatwirang tanong: “Maaari ba kaming mag-set ng custom sharing ratios bawat indibidwal na gastos?” May mga pagkakataon sa kanilang trip project na dalawa lang ang kailangang maghati ng isang partikular na gastos, at may iba pang pagkakataon na lahat ng tatlo ay gustong maghati. Sa ilalim ng Splync v1.8, ang sagot sa kasamaang-palad ay hindi. Ipinaliwanag ko na maaari silang lumikha ng karagdagang mga kategorya na may mga custom ratios na angkop para sa mga partikular na kaso — isang workaround, hindi isang tunay na solusyon.

Nakaka-overwhelm alalahanin kung gaano karaming trabaho ang napunta sa v1.5. Una, kailangan kong payagan ang mga proyekto na magkaroon ng kanilang sariling split ratios. Pagkatapos ang mga kategorya ay nangangailangan din ng kanilang sariling custom ratios. Sa puntong iyon, akala ko natakpan ko na ang buong puno — nakuha ang bawat bunga mula sa bawat sanga. Ngunit ang pagtatrabaho sa per-expense ratios ay iba. Parang tuwing pumipitas ako ng prutas, may bagong puno na sumisibol mula sa mismong lugar na iyon. Hindi isang walang katapusang fractal na kagubatan, kundi isang malinaw na dalawang-palapag na istraktura: isang layer ang naglalarawan sa susunod. Sa lohika ng v1.5, ang isang gastos ay una munang nagmana ng ratio ng proyekto. Kung ang kategorya nito ay may custom ratios, iyon ang papalit sa mga halaga ng proyekto. Kaya't kapag nagdaragdag ng per-expense ratios, natagpuan ko ang sarili kong sinusubukang magdagdag ng isa pang overwrite sa ibabaw ng overwrite na iyon. Ang istraktura ay naging isang hagdanan ng mga overrides — teknikal na tama, ngunit mental na magulo. Mahirap bigyang-katwiran ang pagtatayo ng isa pang layer ng patchwork logic.

Ang tagumpay ay nagmula sa pagbaligtad ng istraktura. Sa halip na gawin ang “project → category → expense” at pag-overwrite ng bawat layer sa susunod, bakit hindi isipin sa kabaligtaran? Per-expense shares → per-category shares → per-project shares. Ang ayos na ito ay sumasalamin sa kung paano maaaring mag-isip ang mga tao: kung ang isang partikular na gastos ay may sarili nitong mga patakaran, dapat itong sundin. Kung wala, ang pattern ng kategorya ang may katuturan. Kung kahit iyon ay mabigo, bumalik sa default ng proyekto. Wala nang hagdanan ng overrides — isang malinis na herarkiya ng priyoridad. Kapag nakita ko ang istraktura sa ganitong paraan, ang fog ng pseudo-fractal forest ay agad na lumiwanag. Ang landas ng implementasyon ay naging malinaw: “Ang bawat gastos ay sinusuri para sa per-expense na custom shares. Kung mayroon, gamitin ito. Kung wala, tingnan ang per-category shares. Kung wala, gamitin ang default ng proyekto.”

Ang bagong lohika ay naramdaman na simple, predictable, at matematikal na tama. Upang suportahan ang sistemang priyoridad na ito, nagdagdag kami ng isang dedikadong MariaDB table para sa per-expense splits, na parang salamin ng table para sa per-category splits. Ang detalye ng mga gastos na table ay kailangan ding palawakin, gaya ng ginawa sa category details table noong v1.5. Sa sandaling naging malinaw ang “two-story” na disenyo, ang natira ay maingat na coding — pareho sa app at sa server. Gayunpaman, parang mapanganib ang landas sa ilang mga bahagi, tulad ng paglalakad sa isang madilim na kagubatan na walang mapa. Gusto kong linisin ang isip ko kaya lumabas ako. Ang hangin ay matalim at malinis. Habang naglalakad sa aking mga kapitbahayan, nakita ko ang Mt. Fuji na tumataas sa malayo, crystal blue sa ilalim ng perpektong asul na langit. Halos 100 km ang layo, ngunit parang napakalapit upang hawakan. Ang sandali ay parang paalala: kahit na iniisip ko na naglalakad ako sa kagubatan, talagang naglalakad ako sa ilalim ng bukas na langit.

Ang Splync v1.9 ay isinilang mula sa sandali ng kalinawan. Umuwi ako, tinapos ang pagtatali ng mga bagong endpoints, inihanda ang bagong server logic, inayos ang mga kaugnay na interface, isinumite ang v1.9 sa Apple, at sa wakas ay nakatulog. Natapos ang pagsusuri na mas maaga kaysa sa dati. Nang magising ako, na-approve na ang Splync v1.9 at awtomatikong nailabas sa App Store. Mula sa bersyong ito, nagiging mas flexible ang paghahati. Kung naglalakbay ka kasama sina John at Kate, maaari mong paghatian nang pantay-pantay ang mga pangunahing gastos sa inyong tatlo. Ngunit para sa pagkain, maaari kang lumipat sa “25% : 50% : 25%” na hati dahil si John ay karaniwang kumakain ng dalawang beses na mas marami. At kung si John ay lumiban sa isang hapunan—sabi natin, sa isang oyster restaurant—maaari mong itakda ang partikular na pagkain sa “50% : 0% : 50%” para hindi siya magbayad para sa hindi niya kinain. Sa v1.9, sinusuportahan na ngayon ng Splync ang per-project, per-category, at per-expense ratios sa isang unified logic. Ang pundasyon ay matatag at matematikal na tama. Ang susunod na hamon ay ang interface: ang ibang mga apps sa paghahati ay nag-aalok ng mas makinis, mas istiladong paraan upang ayusin ang mga ratios. Ang Splync ay may likod ng lakas upang suportahan ang mga ganitong pagpapabuti. Tatrabahuhin namin ito ng paisa-isa.