২০২৫ সালের ১৯ জুন আমি সেন্ট পিটার্সবার্গে PiterJS #79-এ গিয়েছিলাম। সন্ধ্যার বিষয়টি ইচ্ছাকৃতভাবেই খুব চকচকে ছিল না, আর সেটাই আমার কাছে ভালো লেগেছে: পরের feature কীভাবে ship করা যায় তা নয়, বরং আগে যা তৈরি হয়েছে সেটাকে কীভাবে টিকিয়ে রাখা যায় — monitoring, deployment এবং refactoring.
প্রোগ্রামটিও এই ভাবনার সঙ্গে খুব ভালোভাবে মিলে গিয়েছিল। Pavel Shlykov পুরোনো monolith উন্নত করার কথা বলেছেন, Alexander Panfilov FrontOps নিয়ে, আর Igor Antonov web application performance metrics নিয়ে। তিনটি বিষয় থেকেই আমি ব্যবহারযোগ্য নোট নিয়ে ফিরেছি।
অপ্রত্যাশিত অংশ ছিল Q&A। শেষ পর্যন্ত sessions-এ সেরা প্রশ্ন করার জন্য আমি দুটি পুরস্কার জিতেছিলাম। এটা বড় কোনো technical achievement নয়, কিন্তু সন্ধ্যার সবচেয়ে স্মরণীয় অংশ হয়ে যায়। কারণ আবার মনে করিয়ে দিয়েছিল কেন আমি এখনও সরাসরি technical meetup-কে মূল্য দিই: শুধু প্রস্তুত করা talk শোনা নয়, speaker তখনও সামনে থাকতেই নিজের বোঝাপড়া যাচাই করা যায়।
সবচেয়ে কাজে লেগেছে maintenance-এর আলোচনা, নতুনত্বের নয়
Frontend event খুব সহজেই নতুন framework, API এবং abstraction-এর প্রদর্শনী হয়ে যেতে পারে। PiterJS #79 তুলনামূলকভাবে বেশি বাস্তবমুখী ছিল। ঘোষিত theme ছিল ইতিমধ্যে থাকা software-কে কীভাবে support করা যায়।
এটা গুরুত্বপূর্ণ, কারণ engineering-এর বড় অংশ প্রথম সফল release-এর পর শুরু হয়। Legacy monolith মানেই স্বয়ংক্রিয়ভাবে খারাপ system নয়, আর “modernization” মানেই সবকিছু rewrite করা নয়। বাস্তব প্রশ্নটি সাধারণত আরও নির্দিষ্ট: এই মুহূর্তে কোন constraint system-কে সত্যিই সমস্যায় ফেলছে, আর কোন পরিবর্তন সেই সমস্যা কমাতে পারে এমনভাবে যাতে সরিয়ে দেওয়া risk-এর চেয়ে নতুন risk বেশি না হয়?
এই কারণেই তিনটি talk আমার কাছে একে অন্যের সঙ্গে সুন্দরভাবে যুক্ত মনে হয়েছে। Refactoring code বদলায়। FrontOps বদলায় frontend কীভাবে build, package, deliver এবং operate হয়। Performance work বদলায় আমরা ফলাফল কীভাবে measure করি। এগুলো একই সমস্যার আলাদা layer: বড় হয়ে যাওয়ার পরও একটি বাস্তব system-কে বোঝা এবং নিয়ন্ত্রণ করা যায় এমন অবস্থায় রাখা।
FrontOps শুধু Dockerfile নয়
Meetup থেকে নেওয়া আমার একটি note ছিল Docker দিয়ে FrontOps বাস্তবায়ন নিয়ে। গুরুত্বপূর্ণ পার্থক্যটি হলো Docker একটি tool, FrontOps-এর definition নয়।
npm run build সফল হলেই frontend-এর দায়িত্ব শেষ হয়ে যায় না। Production-এ এখনও reproducible build, artifact packaging, configuration কীভাবে application-এ পৌঁছায়, release rollback, cache behavior এবং failure observability নিয়ে ভাবতে হয়। Container এগুলোর কিছু অংশকে বেশি predictable করতে পারে, কিন্তু operational decision-এর বিকল্প নয়।
এটি একটি সাধারণ mental model সংশোধন করে: successful build শুধু প্রমাণ করে build শেষ হয়েছে। এটি প্রমাণ করে না application সঠিকভাবে deploy হবে, production-এ সঠিক behavior করবে, অথবা সমস্যা হলে সহজে recover করা যাবে।
Performance শুরু হয় “slow” বলতে কী বোঝায় তা ঠিক করা থেকে
Performance talk বিশেষভাবে practical ছিল measurement-কে যেভাবে frame করেছিল তার জন্য। ঘোষিত scope-এ loading speed-কে প্রভাবিত করা factor, বিভিন্ন frontend performance metric, “slow” কীভাবে quantify করা যায়, এমনকি optimization সব সময় কেন দরকার হয় না সেই প্রশ্নও ছিল।
শেষের বিষয়টি সহজেই অবহেলা করা যায়। “আরও fast করো” objective লক্ষ্য মনে হয়, কিন্তু metric আর user-visible problem ছাড়া তা ব্যয়বহুল অনুমানে পরিণত হতে পারে। ভালো performance process শুরু হয় আসলে কী slow তা নির্ধারণ করা, measure করা, bottleneck চিহ্নিত করা, একটি relevant পরিবর্তন করা এবং আবার measure করা দিয়ে।
একটি metric নিজে user experience নয়, তবে discussion-এর জন্য shared unit দেয়। Measurement ছাড়া performance work এমন technically impressive পরিবর্তনের তালিকা হতে পারে যার মাধ্যমে গুরুত্বপূর্ণ সমস্যাটি সত্যিই উন্নত হয়েছে কি না, তার পরিষ্কার evidence থাকে না।
Q&A meetup-এর value আমার কাছে বদলে দিয়েছে
আমি পরে recording দেখতে পারতাম, link-ও সংগ্রহ করতে পারতাম। কিন্তু talks-এর চারপাশে যে interaction হয়, সেটি একইভাবে পুনরায় তৈরি করা কঠিন। ভালো প্রশ্ন করতে গেলে নিজের uncertainty-কে এমন নির্দিষ্ট কিছুতে নামিয়ে আনতে হয় যার উত্তর অন্য engineer দিতে পারেন।
দুটি পুরস্কার জেতা আনন্দের ছিল, কিন্তু বেশি কাজে লাগা lesson ছিল সহজ: অংশ নেওয়ার প্রস্তুতি নিয়ে offline meetup-এ গেলে, সেটিকে live YouTube playlist-এর মতো দেখার চেয়ে অনেক বেশি value পাওয়া যায়।
ভালো technical প্রশ্নে সাধারণত context এবং constraint থাকে। “সেরা architecture কোনটি?” না জিজ্ঞেস করে বেশি কাজে লাগতে পারে জানতে চাওয়া: team যদি legacy system rewrite করতে না পারে তবে trade-off কীভাবে বদলায়, deployment যদি backward-compatible থাকতেই হয় তবে কী পরিবর্তন হয়, অথবা performance metric ভালো হলেও user-visible benefit না থাকলে কীভাবে বিচার করতে হবে।
প্রতিটি প্রশ্নকে খুব clever হতে হবে না। প্রশ্নের কাজ assumption, boundary বা failure mode সামনে আনা।
পরের technical meetup-এ আমি যা সঙ্গে নেব
- Talk আমার জন্য কেন relevant তা আগে জানব। শুরু হওয়ার আগে একটি বাস্তব problem বা uncertainty লিখে রাখব।
- Speaker-এর experience আর নিজের system আলাদা রাখব। ভালো case study evidence, universal recipe নয়।
- Trade-off নিয়ে প্রশ্ন করব। “কখন আপনি এটা ব্যবহার করবেন না?” অনেক সময় “কোন tool সেরা?”-র চেয়ে বেশি তথ্য দেয়।
- একটি follow-up action লিখে রাখব। Note তখনই বেশি মূল্যবান যখন meetup-এর পরে verify, test বা পড়ার মতো কোনো কাজে নিয়ে যায়।
- Convincing talk-কে production proof মনে করব না। Architecture, deployment এবং performance decision নিজের environment-এ এখনও validate করতে হয়।
শেষ পর্যন্ত যা আমার সঙ্গে রইল
একটি meetup কত কিছু বদলে দিতে পারে তা বাড়িয়ে বলতে চাই না। PiterJS থেকে আমি কোনো universal architecture recipe নিয়ে ফিরিনি, আর ভালো talk documentation, profiling, testing বা production data-এর বিকল্প নয়।
আমি যা সত্যিই নিয়ে ফিরেছি তা আরও নির্দিষ্ট: legacy monolith modernize করা, Docker দিয়ে FrontOps এবং web performance measurement নিয়ে ব্যবহারযোগ্য note; Q&A-তে দুটি পুরস্কার; আর local developer community-তে সরাসরি উপস্থিত হওয়ার মূল্য নিয়ে আরেকটি reminder।
Recording presentation ধরে রাখতে পারে। সবচেয়ে কঠিন archive করা হলো presentation-এর চারপাশের কথোপকথন।