Baby Monitor Timmy ideia sinple batekin hasi zen: etxeko pribatutasuna errespetatzen duen haurtxoak zaintzeko monitore bat. Ez hodeian gordetako grabaziorik, ezta haurraren gelatik kanpora doan alferrikako datu-biderik ere. Jende askok ez dakiena da Timmy bakarkako proiektu gisa garatzen dudala Zurichen, eta GitHub Copilot nire programazio-bikote oso azkarra da.
Gizakiaren eta AAren arteko lan-fluxua
Banaketa argia da: funtzioak zehazten ditut, lehentasunak ezartzen ditut eta arkitekturako erabakiak hartzen ditut. Copilot-ek inplementazioan laguntzen du: kodea idazten, probak gehitzen, akatsen jatorria aurkitzen eta argitalpenerako urratsak prestatzen.
Niretzat, sprint arrunt batek gutxi gorabehera honela egiten du aurrera:
- Funtzioaren deskribapena: Funtzioak zer egin behar duen azaltzen dut, kasu bereziak eta mugak barne.
- Inplementazioa: Copilot-ek kodea proposatzen du eta proiektuak lehendik dituen arauei jarraitzen die.
- Probak: Muturretik muturrerako proba automatizatuak bi emuladorretan exekutatzen dira, eta haurraren eta gurasoaren arteko benetako konexioa egiaztatzen dute.
- Banaketa: Probak ondo ateratzen direnean, Android eta iOS bertsioak dagozkien dendetarako eta proba-kanaletarako prestatzen dira.
Ziklo hau funtzioetarako eta akats-konponketetarako errepikatzen da. Ez dut lerro bakoitza neuk idazten, baina nik erabakitzen dut zer garatzen den, zergatik garatzen den, eta proposamen bat Timmyrako egokia den ala ez.
Kontzeptutik WebRTC-ra
Hasieratik argi zegoen zeregin tekniko nagusia: denbora errealeko audioa eta bideoa bi telefonoren artean. WebRTC aukera begi-bistakoa zen, baina Flutterrekin integratzea ez da erraza: ICE hautagaiek, SDP negoziazioak, TURN ordezko bideak eta DataChannel-ek elkarrekin ordena egokian funtzionatu behar dute.
Copilot-ek pieza horiek pausoz pauso elkartzen lagundu zidan: parez pareko konexioa konfiguratu, ordena kritikoa zuzen mantendu (DataChannel offer-aren aurretik, onTrack setRemoteDescription-en aurretik), eta seinalizazioa Firebase Firestoren ezarri. Pieza bakoitzak bi emuladoretan funtzionatu behar zuen aurrera egin aurretik.
Parekatze segurua ECDHrekin
Ezaugarri kritikoenetako bat parekatze-sistema seguruazen. Bi gailuk elkarrenganako konfiantza ezarri behar dute, haien nortasuna bermatzeko zerbitzari zentral baten menpe egon gabe. Irtenbidea: Firebase bidezko ECDH P-256 gako-trukea, tarteko erasotzailearen erasoak detektatzen dituen ikusizko egiaztapen-zenbaki batekin (SAS) batera.
Copilot-ek kate kriptografikoa inplementatzen lagundu zuen: gakoak sortzea, gako publikoen trukea, sekretu partekatua eratortzea, SASa kalkulatzea eta ondorengo seinalizazio-datu guztietarako AES-256-GCM zifratzea. Ez dut parekatze-gakoa backend-era bidaltzen; haren SHA-256 hash-a bakarrik erabiltzen da Firestore dokumentuaren identifikatzaile gisa.
Segurtasun-auditoretza: ahulguneak aurkitu eta konpontzea
Niretzat, AArekin lagundutako garapena ez da soilik azkarrago idaztea. Akatsak sistematikoki bilatzen ere laguntzen du. Segurtasun-auditoretzako sprint zehatz batean, Copilot-ek kode-basea aztertu eta aurkitu zituen sei arazo konpondu behar nituenak:
- Seinalizazio-datuen sarrera-balidaziorik eza
- ICE hautagaiak kudeatzean egon litezkeen lasterketa-baldintzak
- Behar bezala garbitzen ez ziren saio-datu zaharkituak
- Baimen gehiegi ematen zituzten Firestoreko segurtasun-arauak
- Ziurtagiri-ainguraketari buruzko neurriak kontuan hartu ez izana
- TURN kredentzialen fluxuan errore-kudeaketa eskasa
Seiak sprint berean konpondu ziren. Horretan da bereziki ona Copilot: fitxategi asko irakurtzen, ereduak alderatzen eta sakonago aztertu behar ditudan lekuak markatzen.
Sprint iteratiboak: nola garatu zen aplikazioa
Timmy sprint azkar baina argi zehaztuen bidez hazi zen. Hona hemen mugarri batzuk:
- v1.8: Parekatze-sistemaren erabateko birdiseinua — 4 karaktereko kode batek eta Firebase bidezko ECDH P-256 gako-trukeak zuzeneko gakoan oinarritutako aurreko planteamendua ordezkatu zuten.
- v1.10: Segurtasuna indartzeko sprinta — sei ahulguneen auditoretza eta konponketa-zikloa.
- v1.11: Modu iluna pantaila guztietan, baita oraintxe irakurtzen ari zaren hasierako orrian eta blogean ere.
- v1.12: Gurasoaren pantailaren eraberritze handia, gaueko ikusmen-modua eta kameraren fotogramak aztertuz egindako mugimendu-detekzioa.
Sprint bakoitzak oinarrizko eredu bera jarraitzen du: helburua deskribatu, proposamenak berrikusi, automatikoki probatu, eta gero probatzaileei bidali.
Gailuen arteko E2E probak
Ezin da haurtxoak zaintzeko monitore bat behar bezala probatu gailu bakarrean. Haurraren aldeko gailu bat eta gurasoaren aldeko beste bat behar ditut. Proiektua aldi berean martxan zeuden Android-eko bi emuladorekin hasi zen, eta orain ziklo hori tokiko iOS simulagailuarekin eta benetako gailuetan egindako egiaztapenekin osatzen da. Android-eko proba-script automatizatuak honako hau egiten du oraindik:
- Aplikazioa bi emuladorretan instalatzen du
- Bi gailuetan parekatze-prozesuan zehar nabigatzen du
- Audio- eta bideo-konexioak ezarri direla egiaztatzen du
- Sakatu eta hitz egiteko funtzioa (push-to-talk), kameraren kontrola eta beste funtzio batzuk probatzen ditu
Bi emuladorrek IP helbide bera partekatzen dutenez (10.0.2.15), STUN bidezko parez pareko konexio zuzena ezinezkoa da. Proba guztiak Cloudflareren TURN bitartekari-zerbitzariaren bidez egin behar dira. Gogaikarria da, baina erabilgarria: konexio-biderik konplexuena aldiro probatzen da.
Ikasi dudana
AA programazio-bikote batekin aplikazio oso bat garatzeak hainbat gauza erakutsi dizkit:
- Arkitekturak inoiz baino garrantzi handiagoa du. Arau argiek eta ondo dokumentatutako kode-base batek AAri kode koherentea proposatzen laguntzen diote. Anbiguotasuna garestia bihurtzen da azkar.
- Probak ezinbestekoak dira. AAk sortutako kodeak gizakiek idatzitako kodearen proba zorrotz berberak behar ditu. E2E proba automatizatuek eskuz erraz oharkabean pasatuko liratekeen arazoak aurkitu zituzten.
- Gizakiak prozesuan jarraitzen du. Arkitekturako erabaki bakoitza, segurtasunaren inguruko konpromiso bakoitza eta produktuaren muga bakoitza nire esku geratzen da. AAk inplementazioa azkartzen du, baina ez du irizpidea ordezkatzen.
- Abiadurak kalitatea ahalbidetzen du. Funtzioak egunen ordez ordu gutxitan argitaratzen direnez, iterazio gehiago geratzen dira xehetasunak fintzeko eta akatsak konpontzeko. Azkar egiteak ez du berez ona denik esan nahi.
Aurrera begira
Baby Monitor Timmy garatzen jarraitzen du. iOSerako argitalpena gertu dago; ondoren, sentsore-funtzio gehiago eta segurtasuna etengabe indartzea etorriko dira. Lan-fluxuak antzekoa izaten jarraitzen du: nik norabidea eta mugak ezartzen ditut, eta Copilot-ek azkar inplementatzen eta egiaztatzen laguntzen du.
Segurtasunarekin lotutako oinarrizko osagaiak orain argi zehaztutako mugen barruan daude biltegi publiko honetan: baby-monitor-timmy-core. Han daude dokumentatuta parekatzeari, seinalizazioari eta backend-interfazeei buruzko arkitektura-erabakiak ere.