Baby Monitor Timmy ആരംഭിച്ചത് ലളിതമായ ഒരു ആശയത്തോടെയാണ്: വീട്ടിലെ സ്വകാര്യതയെ മാനിക്കുന്ന ഒരു ബേബി മോണിറ്റർ. ക്ലൗഡിൽ റെക്കോർഡിംഗുകളില്ല, കുഞ്ഞിന്റെ മുറിയിൽ നിന്ന് പുറത്തേക്കുള്ള അനാവശ്യ ഡാറ്റാ വഴികളുമില്ല. പലർക്കും കാണാത്ത ഒരു കാര്യമുണ്ട്: സൂറിച്ചിൽ ഞാൻ ഒറ്റയ്ക്കാണ് Timmy നിർമ്മിക്കുന്നത്, കൂടാതെ GitHub Copilot എന്റെ വളരെ വേഗതയുള്ള പേയർ പ്രോഗ്രാമറാണ്.
മനുഷ്യൻ–AI പ്രവൃത്തി രീതി
വിഭജനം വ്യക്തമാണ്: ഫീച്ചറുകൾ നിർവചിക്കുന്നതും മുൻഗണനകൾ നിശ്ചയിക്കുന്നതും ആർക്കിടെക്ചർ തീരുമാനങ്ങൾ എടുക്കുന്നതും ഞാൻ ആണ്. കോഡ് എഴുതൽ, ടെസ്റ്റുകൾ ചേർക്കൽ, ബഗുകളുടെ കാരണം കണ്ടെത്തൽ, റിലീസ് ഘട്ടങ്ങൾ ഒരുക്കൽ തുടങ്ങിയ നടപ്പാക്കലിൽ Copilot സഹായിക്കുന്നു.
എനിക്ക് സാധാരണ ഒരു സ്പ്രിന്റ് ഏകദേശം ഇങ്ങനെയാണ്:
- ഫീച്ചർ വിവരണം: എഡ്ജ് കേസുകളും നിയന്ത്രണങ്ങളും ഉൾപ്പെടെ, ഫീച്ചർ എന്ത് ചെയ്യണമെന്ന് ഞാൻ വിവരിക്കുന്നു.
- നടപ്പാക്കൽ: Copilot കോഡ് നിർദേശിക്കുകയും പ്രോജക്റ്റിലെ നിലവിലെ ചട്ടങ്ങൾ പിന്തുടരുകയും ചെയ്യുന്നു.
- ടെസ്റ്റിംഗ്: രണ്ട് എമുലേറ്ററുകളിൽ ഓട്ടോമേറ്റഡ് എൻഡ്-ടു-എൻഡ് ടെസ്റ്റുകൾ ഓടി, യഥാർത്ഥ കുഞ്ഞ്/രക്ഷിതാവ് കണക്ഷൻ പരിശോധിക്കുന്നു.
- വിതരണം: ടെസ്റ്റുകൾ വിജയിച്ചാൽ, ശരിയായ സ്റ്റോറിനും ടെസ്റ്റിംഗ് ട്രാക്കുകൾക്കുമായി Android, iOS ബിൽഡുകൾ തയ്യാറാക്കുന്നു.
ഫീച്ചറുകൾക്കും ബഗ് പരിഹാരങ്ങൾക്കും ഈ ചക്രം ആവർത്തിക്കുന്നു. എല്ലാ വരിയും ഞാൻ തന്നെ എഴുതുന്നില്ല, പക്ഷേ എന്താണ് നിർമ്മിക്കപ്പെടുന്നത്, എന്തുകൊണ്ടാണ് അത് നിർമ്മിക്കുന്നത്, ഒരു നിർദേശം Timmy-യ്ക്ക് യോജിക്കുന്നുണ്ടോ എന്നിവ ഞാൻ തീരുമാനിക്കുന്നു.
ആശയത്തിൽ നിന്ന് WebRTC വരെ
ആരംഭം മുതൽ തന്നെ പ്രധാന സാങ്കേതിക ദൗത്യം വ്യക്തമായിരുന്നു: രണ്ട് ഫോണുകൾക്കിടയിൽ തത്സമയ ഓഡിയോയും വീഡിയോയും. WebRTC സ്വാഭാവികമായ തിരഞ്ഞെടുപ്പായിരുന്നു, എന്നാൽ Flutter-ൽ അത് കൂട്ടിച്ചേർക്കുന്നത് എളുപ്പമല്ല: ICE candidates, SDP negotiation, TURN fallback, DataChannels എന്നിവ ശരിയായ ക്രമത്തിൽ ഒരുമിച്ച് പ്രവർത്തിക്കണം.
ആ ഘടകങ്ങൾ ഓരോന്നായി ചേർത്ത് പ്രവർത്തിപ്പിക്കാൻ Copilot എന്നെ സഹായിച്ചു: peer connection സജ്ജമാക്കുക, നിർണായകമായ ക്രമം ശരിയായി നിലനിർത്തുക (offer-ന് മുമ്പ് DataChannel, setRemoteDescription-ന് മുമ്പ് onTrack), signaling Firebase Firestore-ലാക്കുക. അടുത്ത ഘട്ടത്തിലേക്ക് പോകുന്നതിന് മുമ്പ് ഓരോ ഭാഗവും രണ്ട് എമുലേറ്ററുകളിൽ പ്രവർത്തിക്കേണ്ടതുണ്ടായിരുന്നു.
ECDH ഉപയോഗിച്ചുള്ള സുരക്ഷിത പെയറിംഗ്
ഏറ്റവും നിർണായകമായ ഫീച്ചറുകളിൽ ഒന്ന് സുരക്ഷിത പെയറിംഗ് സംവിധാനം ആയിരുന്നു. രണ്ട് ഉപകരണങ്ങൾക്കും, അവരുടെ ഐഡന്റിറ്റിക്ക് ഉറപ്പ് നൽകാൻ ഒരു കേന്ദ്ര സർവറിനെ ആശ്രയിക്കാതെ, പരസ്പര വിശ്വാസം സ്ഥാപിക്കണം. പരിഹാരം: Firebase വഴി ECDH P-256 കീ എക്സ്ചേഞ്ച്, കൂടാതെ man-in-the-middle ആക്രമണങ്ങൾ കണ്ടെത്തുന്ന ദൃശ്യ പരിശോധനാ നമ്പർ (SAS).
ക്രിപ്റ്റോഗ്രാഫിക് ശൃംഖല നടപ്പാക്കാൻ Copilot സഹായിച്ചു: കീ സൃഷ്ടിക്കൽ, പബ്ലിക് കീ കൈമാറ്റം, പങ്കിട്ട രഹസ്യം കണ്ടെത്തൽ, SAS കണക്കാക്കൽ, പിന്നീട് വരുന്ന എല്ലാ signaling ഡാറ്റയ്ക്കുമുള്ള AES-256-GCM എൻക്രിപ്ഷൻ. പെയറിംഗ് കീ ഞാൻ backend-ലേക്ക് അയക്കുന്നില്ല; അതിന്റെ SHA-256 hash മാത്രമാണ് Firestore document identifier ആയി ഉപയോഗിക്കുന്നത്.
സുരക്ഷാ ഓഡിറ്റ്: ദുർബലതകൾ കണ്ടെത്തലും പരിഹാരവും
AI സഹായത്തോടെയുള്ള വികസനം എനിക്ക് വേഗത്തിൽ ടൈപ്പ് ചെയ്യുക മാത്രമല്ല. ക്രമബദ്ധമായി ബഗുകൾ കണ്ടെത്താനും ഇത് സഹായിക്കുന്നു. കേന്ദ്രീകൃതമായ ഒരു സുരക്ഷാ ഓഡിറ്റ് സ്പ്രിന്റിൽ, Copilot കോഡ്ബേസ് വിശകലനം ചെയ്ത് ആറ് പ്രശ്നങ്ങൾ ഞാൻ പരിഹരിക്കേണ്ടതായി കണ്ടെത്തി:
- signaling ഡാറ്റയിൽ ഇൻപുട്ട് വാലിഡേഷൻ ഇല്ലാത്തത്
- ICE candidate കൈകാര്യം ചെയ്യുന്നതിലെ സാധ്യതയുള്ള race conditions
- ശരിയായി വൃത്തിയാക്കാത്ത പഴയ session ഡാറ്റ
- അമിതമായി അനുമതി നൽകിയ Firestore സുരക്ഷാ നിയമങ്ങൾ
- certificate pinning സംബന്ധിച്ച പരിഗണനകൾ ഇല്ലാത്തത്
- TURN credential flow-യിൽ മതിയായ error handling ഇല്ലാത്തത്
ആറു പ്രശ്നങ്ങളും അതേ സ്പ്രിന്റിൽ പരിഹരിച്ചു. ഇവിടെ Copilot മികവ് കാണിക്കുന്നു: ഒട്ടേറെ ഫയലുകൾ വായിക്കുക, പാറ്റേണുകൾ താരതമ്യം ചെയ്യുക, ഞാൻ കൂടുതൽ സൂക്ഷ്മമായി പരിശോധിക്കേണ്ട ഇടങ്ങൾ അടയാളപ്പെടുത്തുക.
ആവർത്തിച്ചുള്ള സ്പ്രിന്റുകൾ: ആപ്പ് എങ്ങനെ വളർന്നു
വേഗതയേറിയതെങ്കിലും വ്യക്തമായ പരിധികളുള്ള സ്പ്രിന്റുകളിലൂടെയാണ് Timmy വളർന്നത്. ചില നാഴികക്കല്ലുകൾ:
- v1.8: പൂർണമായ പെയറിംഗ് പുനർരൂപകൽപ്പന — പഴയ direct-key രീതിക്ക് പകരം 4 പ്രതീകങ്ങളുള്ള കോഡും Firebase വഴിയുള്ള ECDH P-256-ഉം.
- v1.10: സുരക്ഷ ശക്തിപ്പെടുത്തൽ സ്പ്രിന്റ് — ആറ് ദുർബലതകളുടെ ഓഡിറ്റും പരിഹാര ചക്രവും.
- v1.11: എല്ലാ സ്ക്രീനുകളിലും ഡാർക്ക് മോഡ്, കൂടാതെ നിങ്ങൾ ഇപ്പോൾ വായിക്കുന്ന ഹോംപേജും ബ്ലോഗും.
- v1.12: രക്ഷിതാക്കളുടെ സ്ക്രീനിൽ വലിയ മാറ്റം, നൈറ്റ് വിഷൻ മോഡ്, ക്യാമറ ഫ്രെയിം വിശകലനത്തിലൂടെ ചലനം കണ്ടെത്തൽ.
ഓരോ സ്പ്രിന്റും ഒരേ അടിസ്ഥാന രീതിയാണ് പിന്തുടരുന്നത്: ലക്ഷ്യം വിവരിക്കുക, നിർദേശങ്ങൾ അവലോകനം ചെയ്യുക, സ്വയമേവ ടെസ്റ്റ് ചെയ്യുക, പിന്നെ ടെസ്റ്റർമാർക്ക് നൽകുക.
ഉപകരണങ്ങൾക്കിടയിലെ E2E ടെസ്റ്റിംഗ്
ഒരു ഉപകരണത്തിൽ ഒരു ബേബി മോണിറ്റർ ശരിയായി ടെസ്റ്റ് ചെയ്യാനാവില്ല. എനിക്ക് ഒരു കുഞ്ഞിന്റെ ഉപകരണവും ഒരു രക്ഷിതാവിന്റെ ഉപകരണവും വേണം. ഒരേസമയം പ്രവർത്തിക്കുന്ന രണ്ട് Android എമുലേറ്ററുകളിലൂടെയാണ് പ്രോജക്റ്റ് തുടങ്ങിയത്; ഇപ്പോൾ അതിനൊപ്പം ലോക്കൽ iOS സിമുലേറ്ററിലും യഥാർത്ഥ ഉപകരണങ്ങളിലും പരിശോധനകൾ നടത്തുന്നുണ്ട്. ഓട്ടോമേറ്റഡ് Android ടെസ്റ്റ് സ്ക്രിപ്റ്റ് ഇപ്പോഴും:
- രണ്ട് എമുലേറ്ററുകളിലും ആപ്പ് ഇൻസ്റ്റാൾ ചെയ്യുന്നു
- രണ്ട് ഉപകരണങ്ങളിലും പെയറിംഗ് ഘട്ടങ്ങളിലൂടെ പോകുന്നു
- ഓഡിയോ, വീഡിയോ കണക്ഷനുകൾ സ്ഥാപിച്ചിട്ടുണ്ടെന്ന് ഉറപ്പാക്കുന്നു
- push-to-talk, ക്യാമറ നിയന്ത്രണം, മറ്റ് ഫീച്ചറുകൾ എന്നിവ ടെസ്റ്റ് ചെയ്യുന്നു
രണ്ട് എമുലേറ്ററുകളും ഒരേ IP വിലാസം പങ്കിടുന്നതിനാൽ (10.0.2.15), STUN വഴിയുള്ള നേരിട്ടുള്ള peer-to-peer കണക്ഷൻ അസാധ്യമാണ്. ഓരോ ടെസ്റ്റ് റണ്ണും Cloudflare TURN relay വഴിയാകണം. അത് ബുദ്ധിമുട്ടാണെങ്കിലും പ്രയോജനകരമാണ്: ഏറ്റവും സങ്കീർണമായ കണക്ഷൻ പാത ഓരോ തവണയും ടെസ്റ്റ് ചെയ്യപ്പെടുന്നു.
ഞാൻ പഠിച്ച കാര്യങ്ങൾ
AI പേയർ പ്രോഗ്രാമറോടൊപ്പം പൂർണമായ ഒരു ആപ്പ് നിർമ്മിച്ചത് എന്നെ ചില കാര്യങ്ങൾ പഠിപ്പിച്ചു:
- ആർക്കിടെക്ചറിന് മുമ്പത്തേക്കാൾ കൂടുതൽ പ്രാധാന്യമുണ്ട്. വ്യക്തമായ ചട്ടങ്ങളും നന്നായി രേഖപ്പെടുത്തിയ കോഡ്ബേസും AI-യ്ക്ക് സ്ഥിരതയുള്ള കോഡ് നിർദേശിക്കാൻ സഹായിക്കുന്നു. അവ്യക്തത പെട്ടെന്ന് ചെലവേറിയതാകുന്നു.
- ടെസ്റ്റിംഗ് വിട്ടുവീഴ്ച ചെയ്യാനാവാത്തതാണ്. AI സൃഷ്ടിച്ച കോഡിനും മനുഷ്യർ എഴുതിയ കോഡിനുള്ളതുപോലെ തന്നെ കർശനമായ ടെസ്റ്റിംഗ് വേണം. കൈകൊണ്ട് ടെസ്റ്റ് ചെയ്യുമ്പോൾ എളുപ്പം വിട്ടുപോകാവുന്ന പ്രശ്നങ്ങൾ ഓട്ടോമേറ്റഡ് E2E ടെസ്റ്റുകൾ കണ്ടെത്തി.
- മനുഷ്യൻ ഈ പ്രക്രിയയിൽ തുടരും. ഓരോ ആർക്കിടെക്ചർ തീരുമാനവും, ഓരോ സുരക്ഷാ വിട്ടുവീഴ്ചയും, ഓരോ ഉൽപ്പന്ന പരിധിയും എന്റേതാണ്. AI നടപ്പാക്കൽ വേഗത്തിലാക്കുന്നു, പക്ഷേ വിവേചനശേഷിയെ പകരംവെയ്ക്കുന്നില്ല.
- വേഗത ഗുണമേന്മ സാധ്യമാക്കുന്നു. ഫീച്ചറുകൾ ദിവസങ്ങൾക്കുപകരം മണിക്കൂറുകൾക്കുള്ളിൽ പുറത്തിറങ്ങുന്നതിനാൽ, മിനുക്കലിനും ബഗ് പരിഹാരങ്ങൾക്കും കൂടുതൽ ആവർത്തനങ്ങൾ ലഭിക്കുന്നു. വേഗത എന്നത് സ്വയം നല്ലതാണെന്നല്ല.
മുന്നോട്ടുള്ള വഴി
Baby Monitor Timmy തുടർന്നും വികസിച്ചുകൊണ്ടിരിക്കുന്നു. iOS റിലീസ് അടുത്താണ്; അതിന് ശേഷം കൂടുതൽ സെൻസർ ഫീച്ചറുകളും തുടർച്ചയായ സുരക്ഷ ശക്തിപ്പെടുത്തലും വരും. പ്രവൃത്തി രീതി സമാനമായിരിക്കും: ദിശയും പരിധികളും ഞാൻ നിശ്ചയിക്കും, വേഗത്തിൽ നടപ്പാക്കാനും പരിശോധിക്കാനും Copilot സഹായിക്കും.
സുരക്ഷയുമായി ബന്ധപ്പെട്ട നിർമ്മാണ ഘടകങ്ങൾ ഇപ്പോൾ വ്യക്തമായി നിർവചിച്ച പരിധികളോടെ പൊതുവായി ലഭ്യമായ baby-monitor-timmy-core റിപ്പോസിറ്ററിയിലാണ്. പെയറിംഗ്, സിഗ്നലിംഗ്, ബാക്ക്എൻഡ് ഇന്റർഫേസുകൾ എന്നിവയുമായി ബന്ധപ്പെട്ട ആർക്കിടെക്ചർ തീരുമാനങ്ങൾ രേഖപ്പെടുത്തിയിരിക്കുന്നതും അവിടെയാണ്.