লেখা
কাজ আর জীবন থেকে কিছু কথা।
ইঞ্জিনিয়ারিং, সন্তান মানুষ করা আর নিজের বিচারবুদ্ধি নিয়ে লেখা। মঞ্চের কিছু মুহূর্তও আছে। যে ভাবনা আর স্মৃতিগুলো রেখে দিতে ইচ্ছে হয়, তাদের জন্য এই জায়গা।
মঞ্চ থেকে · ভিডিওর সংগ্রহ
দুর্গাপুজোর মঞ্চ থেকে
আমাদের দুর্গাপুজোর কিছু অনুষ্ঠান একসঙ্গে। নিজের মুহূর্তটা খুঁজে নিন, আবার দেখুন, আর ইচ্ছে হলে একটা কপি রেখে দিন।
7টি ভিডিও দেখুন বা রেখে দিনএখনকার ভাবনা · ছয় পর্বে
AI-কে নিয়ে ডেভেলপমেন্টের গোটা ব্যবস্থা গড়া
একটা ভাবনা থেকে ছোট প্রোটোটাইপ, কাজের যাচাই, মানুষের ব্যবহার থেকে প্রমাণ, আর পরের ভালো রিলিজ—মাঝে কাজের আসল উদ্দেশ্য না হারিয়ে এই পথটা তৈরি করাই এখন আমার আগ্রহ।
- পর্ব 1
মাইগ্রেশনের মাঝপথে AI-first development বেছে নিলাম কেন
Cloud front-end-এর মাইগ্রেশনের মাঝেই AI-assisted কাজ থেকে AI-first development-এর দিকে যাওয়ার সিদ্ধান্ত নিয়েছিলাম। সেই বদলটা কাজে কীভাবে দেখতে চেয়েছিলাম, আর কোন সিদ্ধান্ত ও যাচাই আমার দিকেই থেকে যায়—সেই কথা। - পর্ব 2
কাজের চাহিদাগুলোই AI ডেলিভারির নিয়ন্ত্রণের জায়গা
AI-কে নিয়ে কাজ ঠিক পথে থাকে যখন কী আচরণ চাই, কী বাধা আছে, কোথায় ব্যতিক্রম আর কোন প্রমাণে কাজ মেনে নেব—এসব লিখে রাখা ইঞ্জিনিয়ারিংয়ের ইনপুট হয়। - পর্ব 3
ঠিক তথ্যের উৎস সাদামাটা হলেই context routing কাজে দেয়
AI-র কাজে ফল মেলে যখন দরকারি Markdown ফাইলগুলো হালনাগাদ থাকে, ঠিক সময়ে ঠিক জায়গায় পৌঁছয়, আর একই তথ্যের জন্য একটা নির্দিষ্ট উৎস মানে। - পর্ব 4
একসঙ্গে অনেক এজেন্ট চালাতে গেলে সাদামাটা চুক্তি দরকার
একাধিক এজেন্ট কাজে লাগে তখনই, যখন কার কাজ কতটা, কার দায়িত্ব কোথায়, কে কার ওপর নির্ভর করছে, কী বদলাবে না, কী প্রমাণ লাগবে আর কখন থামবে—এসব স্পষ্ট থাকে। - পর্ব 5
প্রমাণ দেখাতে না পারলে এজেন্টের কাজ এখনও শেষ নয়
তৈরি হওয়া diff একটা প্রস্তাব। কাজ শেষ বলতে হলে ঝুঁকি মেনে চাহিদা, পরীক্ষা, ব্রাউজারের আচরণ আর জানা সীমাবদ্ধতার মধ্যে প্রমাণের যোগ চাই। - পর্ব 6
আসল পরীক্ষা পরের বদলটা সামলাতে পারা
প্রথম ইমপ্লিমেন্টেশন গতি দেখাতে পারে। চাহিদা আবার বদলালে বোঝা যায়, আগের কথা না ভুলে ব্যবস্থা মানিয়ে নিতে পারে কি না।
আলাদা লেখা
আলাদা করে পড়ার মতো ভাবনা।
সন্তান মানুষ করা, ইঞ্জিনিয়ারিং, আর কাজ ও জীবনে রোজকার বিচারবুদ্ধি।
মেয়েকে একটু ঝুঁকি নিতে দিই—বুঝেশুনে
সন্তান মানুষ করা আমার কাছে সব ধারালো কোণা সরিয়ে দেওয়া নয়। মেয়েকে ছোট, বোঝা যায় এমন ঝুঁকির সামনে দাঁড়াতে দেওয়া। যাতে নিজের ক্ষমতা, বিচারবুদ্ধি আর ভুল হলে সামলে নেওয়ার ভরসা তৈরি হয়।
AI প্রোডাক্ট তৈরির পথ বদলাবে, ইঞ্জিনিয়ারদের মুছে দেবে না
প্রোডাক্টের ডিজাইন, মানুষের মতামত আর ফ্রন্টএন্ড ডেলিভারির মধ্যের পথ AI ছোট করবে। কিন্তু গোটা ব্যবস্থায় ইঞ্জিনিয়ারিংয়ের বিচারবুদ্ধি তখনও লাগবে।
প্রথম রিলিজের পরে বদল সামলানোতেই ফ্রন্টএন্ড আর্কিটেকচারের পরীক্ষা
প্রথম রিলিজের পরে দল কতটা নিশ্চিন্তে মত বদলাতে পারে, সেটা দিয়েই আমি আর্কিটেকচার বিচার করি।
Angular component-এর API-তেও প্রোডাক্টের ভাষা চাই
component-এর API পড়ে তার প্রোডাক্টের সিদ্ধান্তটা বোঝা যাক। শুধু সাজানোর সুইচের তালিকা যেন না হয়।
অপেক্ষার সময়েই প্রোডাক্টের সত্যি কথাটা বোঝা যায়
spinner অনেক সময় বলে দেয়, আসলে কী হচ্ছে সেটা ইন্টারফেস এখনও বলতে চায়নি।
AI ইন্টারফেসে অনিশ্চয়তা লুকোনোর বদলে স্বীকার করা দরকার
AI SaaS প্রোডাক্টে অর্ধেক উত্তর, বাদ পড়া প্রেক্ষাপট, কম ভরসার ফল আর মানুষের রিভিউ—এসবের জন্যও আলাদা UI state চাই।
জটিল ফ্রন্টএন্ড pull request আমি কীভাবে দেখি
নিজের স্টাইলের পছন্দে সময় দেওয়ার আগে আচরণ, দায়িত্ব আর বাদ পড়া state দেখি।
প্রোডাক্ট জটিল হলেও কাজে থাকে এমন Angular component
ব্যবহারকারী আর দল যে দায়িত্বগুলো চেনে, component-এর সীমানাও সেগুলোর সঙ্গে মিললে বেশি দিন কাজে লাগে।
state management যত সাদামাটা রাখা যায়, তত ভালো
বড় Angular অ্যাপে নাটকীয় state-এর যন্ত্রপাতির চেয়ে পরিষ্কার দায়িত্ব আর type দিয়ে বলা transition বেশি দরকার হয়।
ঘন enterprise UI-র কাজটাকেও গুরুত্ব দেওয়া দরকার
সবচেয়ে কঠিন screen অনেক সময় সেই শান্ত screen-গুলো, যেখানে মানুষ সারাদিন দেখে, মেলায়, ছাঁকে আর কাজ করে।
অ্যাপ বানানোর সবচেয়ে আকর্ষণীয় জায়গা এখনও ব্রাউজার
চোখে দেখা যায় না এমন ব্যবস্থাকে হাতে-কলমে বোঝা যায় বলেই ব্রাউজারের পরীক্ষায় বারবার ফিরে আসি।