Baby Monitor Timmy ເລີ່ມຈາກແນວຄິດງ່າຍໆ: ເຄື່ອງເບິ່ງແຍງລູກນ້ອຍທີ່ເຄົາລົບຄວາມເປັນສ່ວນຕົວຢູ່ເຮືອນ. ບໍ່ມີການບັນທຶກໄວ້ໃນຄລາວ, ບໍ່ມີເສັ້ນທາງຂໍ້ມູນທີ່ບໍ່ຈຳເປັນອອກຈາກຫ້ອງລູກ. ສິ່ງທີ່ຫຼາຍຄົນບໍ່ເຫັນ: ຂ້ອຍສ້າງ Timmy ຢູ່ຄົນດຽວໃນ Zurich, ແລະ GitHub Copilot ແມ່ນຄູ່ຮ່ວມຂຽນໂປຣແກຣມທີ່ໄວຫຼາຍຂອງຂ້ອຍ.
ວິທີເຮັດວຽກຮ່ວມກັນລະຫວ່າງຄົນ ແລະ AI
ການແບ່ງໜ້າທີ່ແມ່ນຊັດເຈນ: ຂ້ອຍກຳນົດຟີເຈີ, ຈັດລຳດັບຄວາມສຳຄັນ ແລະຕັດສິນໃຈດ້ານສະຖາປັດຕະຍະກຳ. Copilot ຊ່ວຍໃນການພັດທະນາ: ຂຽນໂຄດ, ເພີ່ມການທົດສອບ, ຊອກຫາສາເຫດຂອງບັກ ແລະກະກຽມຂັ້ນຕອນປ່ອຍເວີຊັນ.
ຮອບພັດທະນາປົກກະຕິຂອງຂ້ອຍໂດຍປະມານເປັນແບບນີ້:
- ຄຳອະທິບາຍຟີເຈີ: ຂ້ອຍອະທິບາຍວ່າຟີເຈີຄວນເຮັດຫຍັງ, ລວມທັງກໍລະນີພິເສດ ແລະຂໍ້ຈຳກັດ.
- ການລົງມືເຮັດ: Copilot ແນະນຳໂຄດ ແລະເຮັດຕາມແນວທາງທີ່ໂຄງການໃຊ້ຢູ່ແລ້ວ.
- ການທົດສອບ: ການທົດສອບ end-to-end ອັດຕະໂນມັດເຮັດວຽກໃນ emulator ສອງເຄື່ອງ ແລະກວດເບິ່ງການເຊື່ອມຕໍ່ລະຫວ່າງເຄື່ອງຝັ່ງລູກ ແລະຝັ່ງພໍ່ແມ່ຈິງໆ.
- ການແຈກຈ່າຍ: ເມື່ອການທົດສອບຜ່ານ, ຈະກະກຽມແອັບເວີຊັນ Android ແລະ iOS ສຳລັບຮ້ານແອັບ ແລະຊ່ອງທາງທົດສອບທີ່ເໝາະສົມ.
ວົງຈອນນີ້ເຮັດຊ້ຳສຳລັບຟີເຈີ ແລະການແກ້ບັກ. ຂ້ອຍບໍ່ໄດ້ຂຽນທຸກບັນທັດດ້ວຍຕົນເອງ, ແຕ່ຂ້ອຍເປັນຄົນຕັດສິນໃຈ ວ່າຫຍັງ ຈະຖືກສ້າງ, ເປັນຫຍັງ ຈຶ່ງສ້າງມັນ, ແລະວ່າຂໍ້ແນະນຳນັ້ນເໝາະກັບ Timmy ຫຼືບໍ່.
ຈາກແນວຄິດສູ່ WebRTC
ວຽກດ້ານເຕັກນິກຫຼັກແມ່ນຊັດເຈນຕັ້ງແຕ່ເລີ່ມ: ສຽງ ແລະວິດີໂອແບບເວລາຈິງລະຫວ່າງໂທລະສັບສອງເຄື່ອງ. WebRTC ເປັນຕົວເລືອກທີ່ຊັດເຈນ, ແຕ່ການເຊື່ອມມັນເຂົ້າກັບ Flutter ບໍ່ງ່າຍ: ICE candidates, ການເຈລະຈາ SDP, TURN fallback ແລະ DataChannels ຕ້ອງເຮັດວຽກນຳກັນຕາມລຳດັບທີ່ຖືກຕ້ອງ.
Copilot ຊ່ວຍໃຫ້ຂ້ອຍລວມສ່ວນຕ່າງໆເຫຼົ່ານັ້ນເທື່ອລະຂັ້ນ: ຕັ້ງຄ່າ peer connection, ຮັກສາລຳດັບສຳຄັນໃຫ້ຖືກ (DataChannel ກ່ອນ offer, onTrack ກ່ອນ setRemoteDescription), ແລະໃຊ້ Firebase Firestore ສຳລັບ signaling. ແຕ່ລະສ່ວນຕ້ອງແລ່ນໃນ emulator ສອງເຄື່ອງກ່ອນຂ້ອຍຈະໄປຕໍ່.
ການຈັບຄູ່ທີ່ປອດໄພດ້ວຍ ECDH
ໜຶ່ງໃນຟີເຈີທີ່ສຳຄັນຫຼາຍແມ່ນ ລະບົບຈັບຄູ່ທີ່ປອດໄພ. ອຸປະກອນສອງເຄື່ອງຕ້ອງສ້າງຄວາມໄວ້ວາງໃຈຮ່ວມກັນ ໂດຍບໍ່ອາໄສ server ກາງມາຢືນຢັນ ຕົວຕົນຂອງພວກມັນ. ວິທີແກ້ໄຂ: ແລກປ່ຽນຄີ ECDH P-256 ຜ່ານ Firebase ຮ່ວມກັບ ເລກຢືນຢັນດ້ວຍຕາ (SAS) ທີ່ກວດຈັບການໂຈມຕີ man-in-the-middle.
Copilot ຊ່ວຍນຳໃຊ້ລຳດັບການເຂົ້າລະຫັດ: ສ້າງຄີ, ແລກປ່ຽນ public key, ຄຳນວນ shared secret, ຄຳນວນ SAS, ແລະເຂົ້າລະຫັດ AES-256-GCM ສຳລັບຂໍ້ມູນ signaling ທັງໝົດໃນພາຍຫຼັງ. ຂ້ອຍບໍ່ໄດ້ສົ່ງ pairing key ໄປ backend; ໃຊ້ພຽງ SHA-256 hash ຂອງມັນເປັນຕົວລະບຸ Firestore document.
ການກວດສອບຄວາມປອດໄພ: ຊອກຫາ ແລະແກ້ໄຂຊ່ອງໂຫວ່
ການພັດທະນາໂດຍມີ AI ຊ່ວຍ ບໍ່ແມ່ນພຽງການພິມໄວຂຶ້ນສຳລັບຂ້ອຍ. ມັນຍັງຊ່ວຍຊອກຫາບັກຢ່າງເປັນລະບົບ. ໃນ sprint ກວດສອບຄວາມປອດໄພທີ່ເນັ້ນຈຸດ, Copilot ໄດ້ວິເຄາະ codebase ແລະພົບ ບັນຫາຫົກຂໍ້ ທີ່ຂ້ອຍຕ້ອງແກ້ໄຂ:
- ຂາດການກວດສອບ input ຂອງຂໍ້ມູນ signaling
- ອາດເກີດ race condition ໃນການຈັດການ ICE candidate
- ຂໍ້ມູນ session ເກົ່າທີ່ບໍ່ໄດ້ລ້າງອອກຢ່າງຖືກຕ້ອງ
- ກົດຄວາມປອດໄພ Firestore ທີ່ອະນຸຍາດຫຼາຍເກີນໄປ
- ຂາດການພິຈາລະນາ certificate pinning
- ການຈັດການຂໍ້ຜິດພາດໃນ flow ຂໍ TURN credential ຍັງບໍ່ພຽງພໍ
ທັງຫົກຂໍ້ໄດ້ຖືກແກ້ໃນ sprint ດຽວກັນ. ນີ້ແມ່ນຈຸດທີ່ Copilot ເຮັດໄດ້ດີ: ອ່ານຫຼາຍໄຟລ໌, ປຽບທຽບຮູບແບບ ແລະໝາຍຈຸດທີ່ຂ້ອຍຕ້ອງກວດເບິ່ງລະອຽດຂຶ້ນ.
ຮອບພັດທະນາແບບປັບປຸງຕໍ່ເນື່ອງ: ແອັບພັດທະນາມາແນວໃດ
Timmy ເຕີບໂຕຜ່ານຮອບພັດທະນາທີ່ໄວ ແຕ່ມີຂອບເຂດຊັດເຈນ. ເປົ້າໝາຍສຳຄັນບາງສ່ວນມີດັ່ງນີ້:
- v1.8: ປັບຮູບແບບການຈັບຄູ່ໃໝ່ທັງໝົດ — ລະຫັດ 4 ຕົວອັກສອນ + ECDH P-256 ຜ່ານ Firebase ແທນວິທີ direct-key ເກົ່າ.
- v1.10: sprint ເພີ່ມຄວາມແຂງແຮງດ້ານຄວາມປອດໄພ — ວົງຈອນກວດສອບ ແລະແກ້ໄຂຊ່ອງໂຫວ່ທັງຫົກຂໍ້.
- v1.11: dark mode ທຸກໜ້າຈໍ, ພ້ອມກັບໜ້າຫຼັກ ແລະບລັອກທີ່ທ່ານກຳລັງອ່ານຢູ່ນີ້.
- v1.12: ຍົກເຄື່ອງໜ້າຈໍຝັ່ງພໍ່ແມ່ຄັ້ງໃຫຍ່, ເພີ່ມໂໝດເບິ່ງກາງຄືນ ແລະການກວດຈັບການເຄື່ອນໄຫວດ້ວຍການວິເຄາະພາບແຕ່ລະເຟຣມຈາກກ້ອງ.
ທຸກ sprint ເຮັດຕາມຮູບແບບພື້ນຖານດຽວກັນ: ອະທິບາຍເປົ້າໝາຍ, ກວດທານຄຳແນະນຳ, ທົດສອບອັດຕະໂນມັດ, ແລ້ວຈຶ່ງສົ່ງໃຫ້ຜູ້ທົດສອບ.
ການທົດສອບ E2E ຂ້າມອຸປະກອນ
ທ່ານທົດສອບແອັບເບິ່ງແຍງລູກໃຫ້ຖືກຕ້ອງດ້ວຍອຸປະກອນເຄື່ອງດຽວບໍ່ໄດ້. ຂ້ອຍຕ້ອງມີອຸປະກອນຝັ່ງລູກໜຶ່ງເຄື່ອງ ແລະຝັ່ງພໍ່ແມ່ອີກໜຶ່ງເຄື່ອງ. ໂຄງການເລີ່ມດ້ວຍ Android emulator ສອງເຄື່ອງແລ່ນພ້ອມກັນ ແລະຕອນນີ້ເສີມ ວົງຈອນນັ້ນດ້ວຍການກວດໃນ iOS simulator ພາຍໃນເຄື່ອງ ແລະອຸປະກອນຈິງ. script ທົດສອບ Android ອັດຕະໂນມັດ ຍັງເຮັດດັ່ງນີ້:
- ຕິດຕັ້ງແອັບໃນ emulator ທັງສອງເຄື່ອງ
- ນຳທາງຜ່ານການຈັບຄູ່ໃນອຸປະກອນທັງສອງ
- ກວດວ່າການເຊື່ອມຕໍ່ສຽງ ແລະວິດີໂອຖືກສ້າງຂຶ້ນແລ້ວ
- ທົດສອບ push-to-talk, ການຄວບຄຸມກ້ອງ ແລະຟີເຈີອື່ນໆ
ເນື່ອງຈາກ emulator ທັງສອງໃຊ້ IP address ດຽວກັນ (10.0.2.15), ການເຊື່ອມຕໍ່ peer-to-peer ໂດຍກົງຜ່ານ STUN ຈຶ່ງເປັນໄປບໍ່ໄດ້. ທຸກຮອບການທົດສອບຕ້ອງຜ່ານ Cloudflare TURN relay. ມັນໜ້າລຳຄານ, ແຕ່ກໍມີປະໂຫຍດ: ເສັ້ນທາງການເຊື່ອມຕໍ່ທີ່ຊັບຊ້ອນທີ່ສຸດຖືກທົດສອບທຸກຄັ້ງ.
ສິ່ງທີ່ຂ້ອຍໄດ້ຮຽນຮູ້
ການສ້າງແອັບທີ່ສົມບູນພ້ອມຄູ່ຮ່ວມຂຽນໂປຣແກຣມ AI ສອນຂ້ອຍຫຼາຍຢ່າງ:
- ສະຖາປັດຕະຍະກຳສຳຄັນກວ່າເກົ່າ. ແນວທາງທີ່ຊັດເຈນ ແລະຖານໂຄດທີ່ມີເອກະສານປະກອບຢ່າງດີ ຊ່ວຍໃຫ້ AI ແນະນຳໂຄດທີ່ສອດຄ່ອງກັນ. ຄວາມບໍ່ຊັດເຈນເຮັດໃຫ້ເສຍເວລາ ແລະແຮງງານເພີ່ມຂຶ້ນຢ່າງວ່ອງໄວ.
- ການທົດສອບເປັນສິ່ງທີ່ລະເວັ້ນບໍ່ໄດ້. ໂຄດທີ່ AI ສ້າງຕ້ອງໄດ້ຮັບການທົດສອບຢ່າງເຂັ້ມງວດ ເຊັ່ນດຽວກັບໂຄດທີ່ຄົນຂຽນ. ການທົດສອບ E2E ອັດຕະໂນມັດຈັບບັນຫາທີ່ ຈະພາດໄດ້ງ່າຍເມື່ອທົດສອບດ້ວຍມື.
- ຄົນຍັງຕ້ອງມີສ່ວນຮ່ວມ. ຂ້ອຍຍັງເປັນຜູ້ຕັດສິນໃຈທຸກເລື່ອງດ້ານສະຖາປັດຕະຍະກຳ, ການຊັ່ງນ້ຳໜັກ ດ້ານຄວາມປອດໄພທຸກຢ່າງ ແລະຂອບເຂດຂອງຜະລິດຕະພັນທັງໝົດ. AI ຊ່ວຍໃຫ້ການພັດທະນາໄວຂຶ້ນ ແຕ່ບໍ່ສາມາດແທນທີ່ວິຈາລະນະຍານໄດ້.
- ຄວາມໄວເຮັດໃຫ້ຄຸນນະພາບເປັນໄປໄດ້. ເພາະຟີເຈີຖືກປ່ອຍໃນບໍ່ກີ່ຊົ່ວໂມງແທນຫຼາຍມື້, ຈຶ່ງເຫຼືອຮອບການປັບໃຫ້ລະອຽດ ແລະແກ້ບັກຫຼາຍຂຶ້ນ. ໄວບໍ່ໄດ້ໝາຍຄວາມວ່າດີໂດຍອັດຕະໂນມັດ.
ກ້າວຕໍ່ໄປ
Baby Monitor Timmy ຍັງຄົງພັດທະນາຕໍ່. ການປ່ອຍເວີຊັນ iOS ໃກ້ຈະມາເຖິງ; ຫຼັງຈາກນັ້ນຈະມີຟີເຈີ sensor ເພີ່ມເຕີມ ແລະການເສີມຄວາມປອດໄພຢ່າງຕໍ່ເນື່ອງ. ຂັ້ນຕອນເຮັດວຽກຍັງຄ້າຍເດີມ: ຂ້ອຍກຳນົດທິດທາງ ແລະຂອບເຂດ, Copilot ຊ່ວຍລົງມືເຮັດ ແລະກວດສອບໄດ້ໄວ.
ຕອນນີ້ ອົງປະກອບຫຼັກທີ່ກ່ຽວຂ້ອງກັບຄວາມປອດໄພຖືກຈັດວາງໄວ້ໂດຍມີ ຂອບເຂດທີ່ຊັດເຈນ ຢູ່ໃນຄັງໂຄດສາທາລະນະ baby-monitor-timmy-core. ຄັງໂຄດນັ້ນຍັງມີເອກະສານການຕັດສິນໃຈດ້ານສະຖາປັດຕະຍະກຳກ່ຽວກັບການຈັບຄູ່, ການສົ່ງສັນຍານ ແລະສ່ວນຕໍ່ປະສານກັບລະບົບຫຼັງບ້ານ.