Baby Monitor Timmy শুরু হয়েছিল একটি সহজ ভাবনা থেকে: এমন একটি বেবি মনিটর, যা বাড়ির গোপনীয়তাকে সম্মান করে। কোনো ক্লাউড রেকর্ডিং নয়, শিশুর ঘর থেকে বাইরে যাওয়ার অপ্রয়োজনীয় ডেটা-পথও নয়। অনেকেই যা দেখেন না: আমি জুরিখে একাই Timmy তৈরি করি, আর GitHub Copilot হলো আমার খুব দ্রুত পেয়ার প্রোগ্রামার।
মানুষ-AI কর্মপ্রবাহ
ভাগটা পরিষ্কার: ফিচার ঠিক করি, অগ্রাধিকার দিই এবং আর্কিটেকচার-সংক্রান্ত সিদ্ধান্ত নিই আমি। Copilot বাস্তবায়নে সাহায্য করে: কোড লেখা, টেস্ট যোগ করা, বাগের কারণ ছোট করে আনা এবং রিলিজের ধাপ প্রস্তুত করা।
আমার একটি সাধারণ স্প্রিন্ট মোটামুটি এমন হয়:
- ফিচারের বিবরণ: এজ কেস ও সীমাবদ্ধতাসহ ফিচারটি কী করবে, তা আমি লিখে দিই।
- বাস্তবায়ন: Copilot কোডের প্রস্তাব দেয় এবং প্রজেক্টের বিদ্যমান নিয়মকানুন মেনে চলে।
- টেস্টিং: দুটি এমুলেটরে স্বয়ংক্রিয় end-to-end টেস্ট চলে এবং আসল বেবি/প্যারেন্ট সংযোগ পরীক্ষা করে।
- বিতরণ: টেস্ট পাস হলে Android ও iOS বিল্ড সঠিক স্টোর ও টেস্টিং ট্র্যাকের জন্য প্রস্তুত করা হয়।
ফিচার ও বাগফিক্সের জন্য এই চক্রটি বারবার চলে। আমি নিজে প্রতিটি লাইন লিখি না, তবে আমি ঠিক করি কী তৈরি হবে, কেন এটি তৈরি হবে এবং কোনো প্রস্তাব Timmy-এর সঙ্গে মানায় কি না।
ধারণা থেকে WebRTC
শুরু থেকেই মূল প্রযুক্তিগত কাজটি পরিষ্কার ছিল: দুটি ফোনের মধ্যে রিয়েল-টাইম অডিও ও ভিডিও। WebRTC-ই ছিল স্বাভাবিক পছন্দ, কিন্তু Flutter-এর সঙ্গে এটি যুক্ত করা সহজ নয়: ICE candidate, SDP negotiation, TURN fallback এবং DataChannel-কে সঠিক ক্রমে একসঙ্গে কাজ করতে হয়।
Copilot ধাপে ধাপে এসব অংশ একত্র করতে সাহায্য করেছে: peer connection সেট আপ করা, গুরুত্বপূর্ণ ক্রমটি ঠিক রাখা (offer-এর আগে DataChannel, setRemoteDescription-এর আগে onTrack), এবং Firebase Firestore-এ signaling রাখা। পরের ধাপে যাওয়ার আগে প্রতিটি অংশকে দুটি এমুলেটরে চালাতে হয়েছে।
ECDH দিয়ে নিরাপদ পেয়ারিং
সবচেয়ে গুরুত্বপূর্ণ ফিচারগুলোর একটি ছিল নিরাপদ পেয়ারিং ব্যবস্থা। দুটি ডিভাইসকে এমনভাবে পারস্পরিক বিশ্বাস স্থাপন করতে হয়, যাতে তাদের পরিচয় নিশ্চিত করার জন্য কোনো কেন্দ্রীয় সার্ভারের ওপর নির্ভর করতে না হয়। সমাধানটি হলো: Firebase-এর মাধ্যমে ECDH P-256 key exchange, সঙ্গে একটি ভিজ্যুয়াল verification number (SAS), যা man-in-the-middle আক্রমণ শনাক্ত করে।
Copilot ক্রিপ্টোগ্রাফিক ধারাটি বাস্তবায়নে সাহায্য করেছে: key generation, public key exchange, shared secret derivation, SAS computation এবং পরের সব signaling ডেটার জন্য AES-256-GCM encryption। আমি pairing key ব্যাকএন্ডে পাঠাই না; শুধু তার SHA-256 hash-ই Firestore document identifier হিসেবে ব্যবহার করা হয়।
নিরাপত্তা অডিট: দুর্বলতা খুঁজে বের করা ও ঠিক করা
AI-সহায়তায় ডেভেলপমেন্ট আমার কাছে শুধু দ্রুত টাইপ করা নয়। এটি পদ্ধতিগতভাবে বাগ খুঁজতেও সাহায্য করে। একটি মনোযোগী security audit sprint-এ Copilot কোডবেস বিশ্লেষণ করে খুঁজে পেয়েছিল ছয়টি সমস্যা যা আমাকে ঠিক করতে হয়েছিল:
- signaling ডেটায় ইনপুট ভ্যালিডেশন না থাকা
- ICE candidate হ্যান্ডলিংয়ে সম্ভাব্য race condition
- পুরোনো session data ঠিকভাবে পরিষ্কার না হওয়া
- Firestore security rule অতিরিক্ত শিথিল হওয়া
- certificate pinning নিয়ে প্রয়োজনীয় বিবেচনা না থাকা
- TURN credential flow-তে অপর্যাপ্ত error handling
একই স্প্রিন্টেই ছয়টিই ঠিক করা হয়েছিল। এখানেই Copilot শক্তিশালী: অনেক ফাইল পড়া, প্যাটার্ন মিলিয়ে দেখা এবং যেসব জায়গা আমাকে আরও খুঁটিয়ে দেখতে হবে সেগুলো চিহ্নিত করা।
ধাপে ধাপে স্প্রিন্ট: অ্যাপটি যেভাবে এগিয়েছে
Timmy দ্রুত, তবে স্পষ্ট সীমারেখার মধ্যে থাকা স্প্রিন্টের মাধ্যমে বড় হয়েছে। কয়েকটি মাইলস্টোন:
- v1.8: সম্পূর্ণ পেয়ারিং নতুনভাবে তৈরি — Firebase-এর মাধ্যমে 4-character code + ECDH P-256 পুরোনো direct-key পদ্ধতির জায়গা নিয়েছে।
- v1.10: নিরাপত্তা জোরদার করার স্প্রিন্ট — ছয়টি দুর্বলতার অডিট ও সমাধান চক্র।
- v1.11: সব স্ক্রিনে ডার্ক মোড, সঙ্গে আপনি এখন যে হোমপেজ ও ব্লগ পড়ছেন।
- v1.12: প্যারেন্ট স্ক্রিনে বড় পরিবর্তন, নাইট ভিশন মোড এবং ক্যামেরা ফ্রেম বিশ্লেষণের মাধ্যমে নড়াচড়া শনাক্তকরণ।
প্রতিটি স্প্রিন্ট একই মৌলিক ধারা মেনে চলে: লক্ষ্য বর্ণনা করা, প্রস্তাবগুলো পর্যালোচনা করা, স্বয়ংক্রিয় টেস্ট চালানো, তারপর টেস্টারদের কাছে পাঠানো।
ডিভাইসজুড়ে E2E টেস্টিং
একটি ডিভাইসে বেবি মনিটর ঠিকভাবে টেস্ট করা যায় না। আমার একটি বেবি ডিভাইস এবং একটি প্যারেন্ট ডিভাইস দরকার। প্রজেক্টটি একই সময়ে চালানো দুটি Android emulator দিয়ে শুরু হয়েছিল, আর এখন সেই চক্রে local iOS simulator ও বাস্তব ডিভাইসের পরীক্ষাও যোগ হয়েছে। স্বয়ংক্রিয় Android test script এখনও:
- দুই এমুলেটরেই অ্যাপ ইনস্টল করে
- দুই ডিভাইসে পেয়ারিং প্রক্রিয়ার মধ্য দিয়ে যায়
- অডিও ও ভিডিও সংযোগ স্থাপিত হয়েছে কি না যাচাই করে
- push-to-talk, camera control এবং অন্যান্য ফিচার পরীক্ষা করে
দুই এমুলেটরের IP address একই হওয়ায় (10.0.2.15), STUN-এর মাধ্যমে সরাসরি পিয়ার-টু-পিয়ার সংযোগ সম্ভব নয়। প্রতিটি টেস্ট রানকে Cloudflare TURN রিলের মাধ্যমে যেতে হয়। এটি বিরক্তিকর, তবে উপকারী: সবচেয়ে জটিল সংযোগের পথটি প্রতিবারই পরীক্ষা করা হয়।
আমি যা শিখেছি
AI পেয়ার প্রোগ্রামার দিয়ে একটি পূর্ণাঙ্গ অ্যাপ তৈরি করতে গিয়ে আমি কয়েকটি বিষয় শিখেছি:
- আর্কিটেকচার এখন আগের চেয়েও বেশি গুরুত্বপূর্ণ। স্পষ্ট নিয়মকানুন ও ভালোভাবে নথিবদ্ধ কোডবেস AI-কে ধারাবাহিক কোডের প্রস্তাব দিতে সাহায্য করে। অস্পষ্টতার খরচ দ্রুত বেড়ে যায়।
- টেস্টিং নিয়ে আপস করা যায় না। AI-তৈরি কোডেরও মানুষের লেখা কোডের মতোই কঠোর টেস্টিং দরকার। স্বয়ংক্রিয় E2E টেস্ট এমন সমস্যা ধরেছে, যা হাতে পরীক্ষা করলে সহজেই চোখ এড়িয়ে যেতে পারত।
- মানুষকেই সিদ্ধান্তে থাকতে হয়। প্রতিটি আর্কিটেকচার সিদ্ধান্ত, প্রতিটি নিরাপত্তা-সংক্রান্ত সমঝোতা এবং পণ্যের প্রতিটি সীমারেখার দায়িত্ব আমারই থাকে। AI বাস্তবায়নের গতি বাড়ায়, কিন্তু বিচারবোধের বিকল্প নয়।
- গতি মান বজায় রাখতে সাহায্য করে। ফিচার কয়েক দিনের বদলে কয়েক ঘণ্টায় প্রকাশ করা যায় বলে, পরিমার্জন ও বাগ ঠিক করার জন্য আরও বেশি iteration থাকে। দ্রুত মানেই নিজে থেকে ভালো নয়।
সামনের পথ
Baby Monitor Timmy ক্রমাগত উন্নত হচ্ছে। iOS রিলিজ খুব কাছেই; এরপর আসবে অতিরিক্ত sensor feature এবং চলমান নিরাপত্তা জোরদার করার কাজ। কর্মপ্রবাহটি একই রকম থাকবে: দিকনির্দেশনা ও সীমা ঠিক করি আমি, Copilot দ্রুত বাস্তবায়ন ও যাচাই করতে সাহায্য করে।
নিরাপত্তা-সংক্রান্ত মূল উপাদানগুলো এখন রয়েছে স্পষ্ট সীমারেখার মধ্যে, পাবলিক baby-monitor-timmy-core repository-তে। পেয়ারিং, signaling এবং backend interface-সংক্রান্ত আর্কিটেকচার সিদ্ধান্তগুলোও সেখানে নথিবদ্ধ আছে।