របៀបដែលខ្ញុំបង្កើត Baby Monitor Timmy ជាមួយ GitHub Copilot

Baby Monitor Timmy ចាប់ផ្តើមពីគំនិតសាមញ្ញមួយ៖ ម៉ូនីទ័រទារកដែលគោរពឯកជនភាពនៅផ្ទះ។ គ្មានការថតទុកលើពពក គ្មានផ្លូវបញ្ជូនទិន្នន័យមិនចាំបាច់ចេញពីបន្ទប់កូន។ អ្វីដែលមនុស្សជាច្រើនមិនឃើញគឺ៖ ខ្ញុំបង្កើត Timmy ជាគម្រោងម្នាក់ឯងនៅ Zurich ហើយ GitHub Copilot គឺជាដៃគូសរសេរកូដដ៏លឿនរបស់ខ្ញុំ។

របៀបធ្វើការរវាងមនុស្ស និង AI

ការបែងចែកតួនាទីគឺច្បាស់៖ ខ្ញុំកំណត់មុខងារ ដាក់អាទិភាព និងសម្រេចចិត្តអំពីស្ថាបត្យកម្ម។ Copilot ជួយក្នុងការអនុវត្ត៖ សរសេរកូដ បន្ថែមការធ្វើតេស្ត ស្វែងរកមូលហេតុកំហុសឱ្យកាន់តែច្បាស់ និងរៀបចំជំហានចេញផ្សាយ។

សម្រាប់ខ្ញុំ sprint ធម្មតាមួយមានប្រហែលដូចនេះ៖

1. ការពិពណ៌នាមុខងារ៖ ខ្ញុំពិពណ៌នាអំពីអ្វីដែលមុខងារនោះត្រូវធ្វើ រួមទាំងករណីពិសេស និងលក្ខខណ្ឌកំណត់។
2. ការអនុវត្ត៖ Copilot ស្នើកូដ និងអនុវត្តតាមរបៀបសរសេរកូដដែលគម្រោងមានស្រាប់។
3. ការសាកល្បង៖ ការសាកល្បង end-to-end ស្វ័យប្រវត្តិដំណើរការលើ emulator ពីរ ហើយពិនិត្យការតភ្ជាប់ពិតប្រាកដរវាងឧបករណ៍កូន និងឧបករណ៍ឪពុកម្តាយ។
4. ការចែកចាយ៖ ពេលការសាកល្បងជោគជ័យ build សម្រាប់ Android និង iOS ត្រូវបានរៀបចំសម្រាប់ store និង testing track ដែលត្រឹមត្រូវ។

វដ្តនេះកើតឡើងម្តងហើយម្តងទៀតសម្រាប់មុខងារ និងការកែកំហុស។ ខ្ញុំមិនសរសេរកូដគ្រប់បន្ទាត់ដោយខ្លួនឯងទេ ប៉ុន្តែខ្ញុំសម្រេចថា អ្វី ត្រូវបង្កើត ហេតុអ្វី វាត្រូវបង្កើត និងថាតើសំណើណាមួយសមស្របនឹង Timmy ឬអត់។

ពីគំនិតទៅ WebRTC

ភារកិច្ចបច្ចេកទេសស្នូលគឺច្បាស់តាំងពីដំបូង៖ សំឡេង និងវីដេអូពេលជាក់ស្តែងរវាងទូរស័ព្ទពីរ។ WebRTC គឺជាជម្រើសជាក់ស្តែង ប៉ុន្តែការបញ្ចូលវាជាមួយ Flutter មិនសាមញ្ញទេ៖ ICE candidates, ការចរចា SDP, TURN fallback និង DataChannels ត្រូវធ្វើការជាមួយគ្នាតាមលំដាប់ត្រឹមត្រូវ។

Copilot ជួយខ្ញុំផ្គុំផ្នែកទាំងនេះជាជំហានៗ៖ រៀបចំ peer connection, រក្សាលំដាប់សំខាន់ឱ្យត្រឹមត្រូវ (DataChannel មុន offer, onTrack មុន setRemoteDescription), ហើយដាក់ signaling លើ Firebase Firestore។ គ្រប់ផ្នែកត្រូវដំណើរការលើ emulator ពីរ មុនខ្ញុំបន្តទៅមុខ។

ការផ្គូផ្គងសុវត្ថិភាពជាមួយ ECDH

មុខងារសំខាន់បំផុតមួយគឺ ប្រព័ន្ធផ្គូផ្គងសុវត្ថិភាព។ ឧបករណ៍ពីរត្រូវបង្កើតការទុកចិត្តគ្នាទៅវិញទៅមក ដោយមិនពឹងលើម៉ាស៊ីនមេកណ្ដាលឱ្យបញ្ជាក់ អត្តសញ្ញាណរបស់ពួកវា។ ដំណោះស្រាយគឺ៖ ការប្តូរសោ ECDH P-256 តាម Firebase រួមជាមួយ លេខផ្ទៀងផ្ទាត់ដោយមើលឃើញ (SAS) ដែលរកឃើញការវាយប្រហារ man-in-the-middle។

Copilot ជួយអនុវត្តខ្សែសង្វាក់គ្រីបតូក្រាហ្វិក៖ បង្កើតសោ ផ្លាស់ប្តូរសោសាធារណៈ ទាញយកសម្ងាត់រួម គណនា SAS និងអ៊ិនគ្រីបទិន្នន័យ signaling បន្ទាប់ទាំងអស់ដោយ AES-256-GCM។ ខ្ញុំមិនផ្ញើសោផ្គូផ្គងទៅប្រព័ន្ធខាងក្រោយទេ; មានតែ hash SHA-256 របស់វាប៉ុណ្ណោះដែលត្រូវប្រើជាលេខសម្គាល់ឯកសារ Firestore។

សវនកម្មសុវត្ថិភាព៖ ស្វែងរក និងកែកន្លែងងាយរងគ្រោះ

សម្រាប់ខ្ញុំ ការអភិវឌ្ឍដោយមាន AI ជួយ មិនមែនគ្រាន់តែវាយកូដលឿនឡើងទេ។ វាក៏ជួយស្វែងរកកំហុសជាប្រព័ន្ធផងដែរ។ ក្នុង sprint សវនកម្មសុវត្ថិភាពដែលផ្តោតច្បាស់ Copilot បានវិភាគ codebase ហើយរកឃើញ បញ្ហា 6 ដែលខ្ញុំត្រូវកែ៖

• ខ្វះការផ្ទៀងផ្ទាត់ទិន្នន័យបញ្ចូលសម្រាប់ទិន្នន័យ signaling
• អាចមាន race condition ក្នុងការដោះស្រាយ ICE candidate
• ទិន្នន័យ session ចាស់ដែលមិនត្រូវបានសម្អាតឱ្យត្រឹមត្រូវ
• ច្បាប់សុវត្ថិភាព Firestore ដែលអនុញ្ញាតទូលាយពេក
• ខ្វះការពិចារណាអំពី certificate pinning
• ការដោះស្រាយកំហុសមិនគ្រប់គ្រាន់ក្នុងលំហូរ TURN credential

បញ្ហាទាំង 6 ត្រូវបានកែរួចក្នុង sprint ដដែល។ នេះជាចំណុចខ្លាំងរបស់ Copilot៖ អានឯកសារជាច្រើន ប្រៀបធៀបលំនាំ និងសម្គាល់កន្លែងដែលខ្ញុំត្រូវពិនិត្យឱ្យដិតដល់។

Sprint ជាបន្តបន្ទាប់៖ របៀបដែលកម្មវិធីបានរីកចម្រើន

Timmy រីកចម្រើនតាមរយៈ sprint លឿនៗ ប៉ុន្តែមានព្រំដែនច្បាស់លាស់។ សមិទ្ធផលសំខាន់ៗមួយចំនួន៖

• v1.8៖ រៀបចំការផ្គូផ្គងឡើងវិញទាំងស្រុង — លេខកូដ 4 តួ + ECDH P-256 តាម Firebase ជំនួសវិធីសាស្ត្រសោដោយផ្ទាល់ចាស់។
• v1.10៖ sprint ពង្រឹងសុវត្ថិភាព — វដ្តសវនកម្ម និងកែបញ្ហាងាយរងគ្រោះទាំង 6។
• v1.11៖ របៀបងងឹតនៅគ្រប់អេក្រង់ រួមទាំងទំព័រដើម និងប្លុកដែលអ្នកកំពុងអានឥឡូវនេះ។
• v1.12៖ កែលម្អអេក្រង់ឪពុកម្តាយធំមួយ របៀបមើលពេលយប់ និងការរកឃើញចលនាតាមរយៈការវិភាគ frame កាមេរ៉ា។

គ្រប់ sprint សុទ្ធតែអនុវត្តតាមលំនាំមូលដ្ឋានដូចគ្នា៖ ពិពណ៌នាគោលដៅ ពិនិត្យសំណើ សាកល្បងដោយស្វ័យប្រវត្តិ បន្ទាប់មកបញ្ជូនទៅអ្នកសាកល្បង។

ការសាកល្បង E2E លើឧបករណ៍ជាច្រើន

អ្នកមិនអាចសាកល្បងម៉ូនីទ័រទារកឱ្យបានត្រឹមត្រូវលើឧបករណ៍តែមួយទេ។ ខ្ញុំត្រូវការឧបករណ៍កូនមួយ និងឧបករណ៍ឪពុកម្តាយមួយ។ គម្រោងនេះចាប់ផ្តើមដោយ Android emulator ពីរដំណើរការព្រមគ្នា ហើយឥឡូវបន្ថែម ការត្រួតពិនិត្យដោយ iOS simulator ក្នុងម៉ាស៊ីន និងឧបករណ៍ពិត។ ស្គ្រីបសាកល្បង Android ស្វ័យប្រវត្តិ នៅតែ៖

1. ដំឡើងកម្មវិធីលើ emulator ទាំងពីរ
2. ឆ្លងកាត់ជំហានផ្គូផ្គងលើឧបករណ៍ទាំងពីរ
3. ផ្ទៀងផ្ទាត់ថាការតភ្ជាប់សំឡេង និងវីដេអូត្រូវបានបង្កើត
4. សាកល្បង push-to-talk ការគ្រប់គ្រងកាមេរ៉ា និងមុខងារផ្សេងៗ

ដោយសារ emulator ទាំងពីរចែករំលែកអាសយដ្ឋាន IP ដូចគ្នា (10.0.2.15), ការតភ្ជាប់ដោយផ្ទាល់ពីមិត្តភក្តិទៅមិត្តភក្តិតាមរយៈ STUN មិនអាចធ្វើទៅបានទេ។ រាល់ការសាកល្បងត្រូវឆ្លងកាត់ TURN relay របស់ Cloudflare។ វាគួរឱ្យរំខាន ប៉ុន្តែមានប្រយោជន៍៖ ផ្លូវតភ្ជាប់ដែលស្មុគស្មាញបំផុតត្រូវបានសាកល្បងរាល់ពេល។

អ្វីដែលខ្ញុំបានរៀន

ការបង្កើតកម្មវិធីពេញលេញជាមួយដៃគូសរសេរកូដ AI បានបង្រៀនខ្ញុំនូវរឿងមួយចំនួន៖

• ស្ថាបត្យកម្មសំខាន់ជាងពេលណាៗទាំងអស់។ ក្បួនច្បាស់លាស់ និង codebase ដែលមានឯកសារពន្យល់ល្អ ជួយឱ្យ AI ស្នើកូដដែលស៊ីសង្វាក់គ្នា។ ភាពមិនច្បាស់លាស់ធ្វើឱ្យចំណាយកើនឡើងយ៉ាងលឿន។
• ការសាកល្បងមិនអាចខ្វះបានទេ។ កូដដែល AI បង្កើតត្រូវការការសាកល្បងម៉ត់ចត់ដូចគ្នា នឹងកូដដែលមនុស្សសរសេរ។ ការសាកល្បង E2E ស្វ័យប្រវត្តិបានចាប់បញ្ហាដែលងាយ មើលរំលងពេលសាកល្បងដោយដៃ។
• មនុស្សនៅតែត្រូវចូលរួមក្នុងដំណើរការ។ រាល់ការសម្រេចចិត្តអំពីស្ថាបត្យកម្ម រាល់ ការថ្លឹងថ្លែងផ្នែកសុវត្ថិភាព និងរាល់ព្រំដែនផលិតផល នៅតែជាការទទួលខុសត្រូវរបស់ខ្ញុំ។ AI ជួយពន្លឿនការអនុវត្ត ប៉ុន្តែមិនអាចជំនួសការវិនិច្ឆ័យបានទេ។
• ល្បឿនជួយឱ្យមានគុណភាព។ ដោយសារមុខងារត្រូវបានចេញផ្សាយក្នុងរយៈពេលប៉ុន្មានម៉ោង ជំនួសឱ្យប៉ុន្មានថ្ងៃ ដូច្នេះមានពេលធ្វើម្តងទៀតច្រើនសម្រាប់កែលម្អលម្អិត និងកែកំហុស។ លឿនមិនមានន័យថាល្អដោយស្វ័យប្រវត្តិទេ។

មើលទៅមុខ

Baby Monitor Timmy នៅតែបន្តអភិវឌ្ឍ។ ការចេញផ្សាយ iOS ជិតមកដល់ហើយ; បន្ទាប់ពីនោះនឹងមានមុខងារ sensor បន្ថែម និងការពង្រឹងសុវត្ថិភាពជាបន្តបន្ទាប់។ របៀបធ្វើការនៅតែស្រដៀងគ្នា៖ ខ្ញុំកំណត់ទិសដៅ និងព្រំដែន ខណៈ Copilot ជួយអនុវត្ត និងពិនិត្យបានលឿន។

ឥឡូវនេះសមាសភាគស្នូលដែលពាក់ព័ន្ធនឹងសុវត្ថិភាព ស្ថិតនៅក្រោម ព្រំដែន ច្បាស់លាស់ ក្នុង ឃ្លាំងកូដ baby-monitor-timmy-coreសាធារណៈ។ នៅទីនោះផងដែរ មានឯកសារកត់ត្រាការសម្រេចចិត្តផ្នែកស្ថាបត្យកម្មអំពីការផ្គូផ្គង signaling និង backend interface។

អត្ថបទបន្ថែម

• បច្ចេកវិទ្យានៅពីក្រោយ Timmy
• របៀបដែល Timmy ផ្គូផ្គងដោយសុវត្ថិភាព
• ហេតុអ្វីកម្មវិធីម៉ូនីទ័រទារកគួរតែជាប្រភពបើកចំហ
• ឯកជនភាពក្នុងបន្ទប់កូន

← ត្រឡប់ទៅប្លុក