paint-brush
কিভাবে 400 ঘন্টা পরে, 2MB সীমা উত্তোলন ব্যাপকভাবে বিক্রয় বৃদ্ধিদ্বারা@tomaszs
1,440 পড়া
1,440 পড়া

কিভাবে 400 ঘন্টা পরে, 2MB সীমা উত্তোলন ব্যাপকভাবে বিক্রয় বৃদ্ধি

দ্বারা Tom Smykowski 7m2023/04/15
Read on Terminal Reader
Read this story w/o Javascript

অতিদীর্ঘ; পড়তে

2007 সালে একজন সফটওয়্যার ইঞ্জিনিয়ার একটি অনলাইন ভিডিও টিউটোরিয়াল সাইট তৈরি করতে শুরু করেন। তাকে কীভাবে টিউটোরিয়াল আপলোড করতে হয় এবং কীভাবে লোকেদের সেগুলি দেখতে সক্ষম করা যায় তা খুঁজে বের করতে হয়েছিল। সাইটটি Apache এবং পরে Nginx-এ চলছিল। উচ্চ মানের এবং ছোট ভিডিও আকারের জন্য একটি দর কষাকষি জিততে অনেক পরীক্ষা-নিরীক্ষার প্রয়োজন হয়েছে৷
featured image - কিভাবে 400 ঘন্টা পরে, 2MB সীমা উত্তোলন ব্যাপকভাবে বিক্রয় বৃদ্ধি
Tom Smykowski  HackerNoon profile picture

কখনও কখনও আপনি যখন কিছু সময়ের জন্য একটি সফ্টওয়্যার প্রকৌশলী হিসাবে কাজ করছেন, তখন আপনি শিখতে পারেন যে নৈপুণ্যের কোন ক্ষেত্রগুলি জলাবদ্ধ।


আপনি ঠিক জানেন কিভাবে এটি করতে হয়, আপনি যে সমস্ত সমস্যা ঘটতে পারে তা জানেন, এবং আপনি বিশেষ মনোযোগ সহকারে এই জাতীয় এলাকায় যান, উচ্চস্বরে হাসেন যখন কেউ মনে করেন যে তিনি এটি দ্রুত করতে পারেন এবং তাদের সামনে কী আছে তা না জেনেই ভাল।


এটি এমন একটি ক্ষেত্রের একটি গল্প যা আমি আমার ক্যারিয়ারে অনেক অভিজ্ঞতা পেয়েছি।

কি 400h ভিডিও আপলোড আমাকে শিখিয়েছে

কোথাও 2007 সালের কাছাকাছি ইউটিউব ইতিমধ্যে দুই বছর বয়সী ছিল যার অর্থ এখনও প্রায় কেউই এটি সম্পর্কে জানত না। লোকেরা এসডিতে ভিডিও রেকর্ড করছিল এবং সেগুলি সিডি বা ডিভিডিতে সংরক্ষণ করছিল।


আপনি যে দিনগুলিতে ইন্টারনেটে প্রতিটি ভিডিও আপলোড করবেন তা কেউ কল্পনাও করেনি কারণ সেগুলি ডাউনলোড করা খুব ব্যয়বহুল ছিল।


ওয়েল, হয়তো টরেন্ট ছাড়া. কিন্তু আপনার স্ক্রীন রেকর্ড করার এবং ক্যাপশন যোগ করার জন্য ইতিমধ্যেই অ্যাপ ছিল, তাই আপনি অনলাইনে ভিডিও টিউটোরিয়াল আপলোড করতে পারেন কিনা তা দেখতে আকর্ষণীয় ছিল।


যেহেতু এটি বলেছে, আমি একটি CentOS সার্ভার কিনেছি এবং একটি অনলাইন ভিডিও টিউটোরিয়াল সাইট একত্রিত করতে শুরু করেছি।


এটি কাজ করার জন্য আমাকে দুটি জিনিস বের করতে হয়েছিল: কীভাবে লোকেদের টিউটোরিয়াল আপলোড করতে সক্ষম করা যায় এবং কীভাবে লোকেদের সেগুলি দেখতে সক্ষম করা যায়।


একটি ভিডিও আপলোড করা বেশ সহজ ছিল, আমি ভেবেছিলাম। আপনি শুধু HTML এ একটি ইনপুট ক্ষেত্র যোগ করুন এবং সার্ভারে ফাইলটি গ্রহণ করুন।


কিন্তু এটি পূর্বাভাসের চেয়ে কঠিন ঘটেছে। প্রথম জিনিসগুলি প্রথমে ভিডিওর আকার এবং দ্বিতীয়টি ইন্টারনেট সংযোগের গুণমান।


আমার সার্ভার পিএইচপি ব্যবহার করে, একমাত্র ভাষা যা আপনার প্রয়োজনীয় সবকিছু অফার করে (এটি এখনও এটি করে) দুর্দান্ত ছিল। এটি Apache এবং পরে Nginx-এ চলছিল।


Ngnix এর প্রাথমিক সংস্করণগুলির সাথে জিনিসটি ছিল যে এটি এই ধরনের পেলোড আশা করেনি। সার্ভারটিকে 30-60 মিনিটের ধ্রুবক আপলোড এবং স্থানান্তরের আকার গ্রহণ করতে সক্ষম করতে আমাকে বেশ কয়েকটি সেটিংস কনফিগার করতে হয়েছিল। এটি কিছু পরীক্ষা নিরীক্ষা করে এবং অবশেষে কাজ করে।


আরেকটি বিষয় যা সমস্যাযুক্ত ছিল তা হল Ngnix প্রক্রিয়াগুলিকে কাঁটাচামচ করার উপায়। Ngnix এর প্রথম সংস্করণে কিছু বাগ ছিল যার কারণে কাঁটাগুলি অপ্রত্যাশিতভাবে ঝুলে যায়।


এই ধরনের একটি কাঁটা, একজন ব্যবহারকারী দ্বারা ঝুলানো, পরে অন্যান্য ব্যবহারকারীদের জন্য বরাদ্দ করা হয়েছিল, যার অর্থ তারা ভিডিও আপলোড করতেও অক্ষম ছিল৷


কে কোন প্রক্রিয়াটি ব্যবহার করেছে সে সম্পর্কে আমাকে তথ্য সংরক্ষণ করতে হয়েছিল এবং যখন এটি করার সময় ছিল তখন তাদের হত্যা করতে হয়েছিল। তদুপরি, আমাকে প্রতি রাতে নিয়মিত সমস্ত প্রক্রিয়াগুলি মেরে ফেলতে হয়েছিল, কারণ দিনের বেলা বাগগুলি জমেছিল।


Nginx এবং PHP কনফিগারেশনে দীর্ঘ ঘন্টা অতিবাহিত করার পরে, অবশেষে আপলোড কাজ শুরু করে।


পরবর্তী পদক্ষেপ ছিল ব্যবহারকারীদের কাছে ভিডিও প্রদর্শন করা। সেই সময়ে একজন অনলাইন প্লেয়ার উপলব্ধ ছিল। আমি নাম মনে নেই, কিন্তু এটা ভাল ছিল এবং সাবটাইটেল প্রস্তাব. এটা গুরুত্বপূর্ণ ছিল কারণ আমি চেয়েছিলাম যে সবাই ভিডিও টিউটোরিয়াল থেকে শিখতে পারবে।


কিন্তু অন্য সমস্যা দেখা দিল। একটি কাঁচা ভিডিও চালানো খুব কঠিন ছিল. একটি বেশ দ্রুত সংযোগে এটি অনেক glitched, এবং কখনও কখনও এমনকি ব্রাউজার ভেঙ্গে.


ইতিমধ্যেই ffmpeg ছিল, তাই আমি কীভাবে ভিডিওটি অপ্টিমাইজ করব তা খুঁজে বের করেছি। ভিডিও টিউটোরিয়ালের গুরুত্বপূর্ণ দিক হল আপনি একটি উচ্চ মানের পুরো পর্দা দেখাতে চান। কারণ অন্যথায় লোকেরা দেখতে পাবে না আপনি কী ক্লিক করেন এবং মনিটরে কী পাঠ্য প্রদর্শিত হয়।


সেই সময়ের লাইভ রেকর্ডিংয়ের তুলনায়, ভিডিও টিউটোরিয়ালগুলির মানের জন্য উচ্চতর প্রয়োজনীয়তা ছিল (এ কারণেই ভিডিও টিউটোরিয়ালগুলি অনেক, বহু বছর ধরে ইউটিউবের একটি শক্তিশালী পা ছিল না)।


উচ্চ মানের এবং ছোট ভিডিও আকারের জন্য একটি দর কষাকষি জিততে ffmpeg-এর সাথে অনেক পরীক্ষা-নিরীক্ষা করতে হয়েছে৷ অবশ্যই এটি তাত্ক্ষণিকভাবে করা যায়নি, তাই একটি ক্রোন কাজ ছিল যা MySQL ডাটাবেসগুলিকে অনুসন্ধান করছে এবং ভিডিওগুলি খুঁজে বের করছে যা ইতিমধ্যে সঠিকভাবে রূপান্তরিত হয়নি৷


একটি ভিডিও শুধুমাত্র ffmpeg দ্বারা উত্পাদিত হয়নি কিনা তা পরীক্ষা করাও গুরুত্বপূর্ণ ছিল। যদিও ffmpeg দুর্দান্ত ছিল, কখনও কখনও এটি ভিডিও বা অডিও কম্প্রেশন ফর্ম্যাট, এমনকি ইনপুট ভিডিওর আকারও পছন্দ করে না। ফলস্বরূপ এটি একটি আউটপুট ভিডিও তৈরি করেছিল, কিন্তু এটি কালো ছিল।


তাই আমি আরেকটি ক্রোন কাজ যোগ করেছি। এর কাজটি ছিল আউটপুট ভিডিওতে আবার ffmpeg চালানো, এর আকার, রেজোলিউশন পড়া এবং একটি থাম্বনেইলের জন্য আমার প্রয়োজনীয় একটি ফ্রেম দখল করা। এর পরে, প্রক্রিয়াটি থাম্বনেইলে পিক্সেল চেক করে তা কালো কিনা তা দেখতে। যদি কোনো ত্রুটি না থাকে এবং থাম্বনেইলটি কালো না হয়, তাহলে ধারণা করা হতো রূপান্তরটি সফল হয়েছে।


আমি ভেবেছিলাম এটি যথেষ্ট হবে, কিন্তু এটি ঘটেনি। কারণ কখনও কখনও ffmpeg বা অন্য লাইব্রেরি শুধু হ্যাং হয়। মানে রূপান্তর প্রক্রিয়া, বা বৈধকরণ প্রক্রিয়াটিও স্তব্ধ ছিল এবং কিছু ভুল হলে তথ্য সংরক্ষণ করতে অক্ষম ছিল।


তাই আমি আরেকটি ক্রন প্রক্রিয়া যোগ করেছি। তৃতীয় প্রক্রিয়াটি আগের দুটি প্রক্রিয়ার উপর পরীক্ষা করা হয়েছিল। এটি ডাটাবেসে চেক করে যখন একটি রূপান্তর প্রক্রিয়া শুরু হয়, যখন এটি শেষবার জীবিত থাকার রিপোর্ট করে এবং বর্তমান সময়ের সাথে তুলনা করে।


সুতরাং উদাহরণস্বরূপ যদি একটি রূপান্তর তিন ঘন্টার জন্য সাড়া না দেয় - আমি রূপান্তরটিকে ব্যর্থ হিসাবে চিহ্নিত করেছি এবং এটি পুনরায় চালানোর জন্য যোগ করেছি। যদি একটি বৈধতা প্রক্রিয়া 30 মিনিটের কাজের পরে সাড়া না দেয়, তবে ডাটাবেস যাচাইকরণ ব্যর্থ হয়, তাই ভিডিওটিকে স্ক্র্যাচ থেকে রূপান্তর করতে হয়েছিল এবং প্রক্রিয়াগুলিকে হত্যা করতে হয়েছিল।


সাধারণত যে সাহায্য করেছে. যদি এটি তৃতীয়বারের জন্য কাজ না করে তবে সিস্টেমটি একটি ইমেল পাঠিয়েছে কিছু ভুল।


অবশেষে সিস্টেমটি কাজ করেছে এবং লোকেরা ভিডিও আপলোড করতে সক্ষম হয়েছিল। ভিডিওগুলি রূপান্তরিত হয়েছিল এবং একটি থাম্বনেইল এবং সাবটাইটেল সহ পৃষ্ঠায় প্রদর্শিত হয়েছিল৷


এটি একটি আকর্ষণীয় প্রকল্প ছিল যা আমি 400 ঘন্টার বেশি ব্যয় করেছি। এটি আমাকে ভিডিও, অডিও প্রক্রিয়াকরণ এবং বৈধতা সম্পর্কে অনেক কিছু শিখিয়েছে।


কিন্তু এটি আমাকে এটাও শিখিয়েছে যে আপলোডগুলি পরিচালনা করা একটি জলাবদ্ধ এলাকা যেটিতে আমাকে ফোকাস করতে হবে। এটা পরিশোধ বন্ধ…


আপলোড সীমিত করে আপনি বিক্রয় সীমিত করেন

আপনি ভাবতে পারেন যে এখন, 2023 সালে পরিস্থিতি ভিন্ন। কিন্তু এটা না. অনেক কিছুই নিশ্চিতভাবে পরিবর্তিত হয়েছে। প্রসেসিং পাওয়ার এবং স্টোরেজ পাওয়া সহজ। ইন্টারনেট সংযোগ আরও ভাল। সরঞ্জামগুলি আরও ভাল এবং আরও বিশদ ডকুমেন্টেশন রয়েছে৷


কিন্তু এখনও, ডিফল্ট সেটিংস সহ কিছু আপলোড আকারের কারণে ব্যর্থ হবে। একটি ডিফল্ট আপলোড ফর্ম Android ডিভাইসে কাজ করবে না। আমি অনেক ওয়েব অ্যাপে এই সমস্যাটি বারবার দেখতে পাই।


ভিডিওর একাধিক ফর্ম্যাট এবং এমনকি ফটোগুলি পরিচালনা করা কঠিন। বিশেষ করে এখন থেকে নতুন পরীক্ষামূলক বিন্যাস আছে।


উদাহরণস্বরূপ কিছু বছর আগে আমি সামাজিক মিডিয়ার জন্য একটি বিষয়বস্তু ব্যবস্থাপনা এবং পরিকল্পনা সিস্টেম তৈরি করছিলাম।


এটি বিপণনকারীদের আপলোড করা ফটো সম্পাদনা করার ক্ষমতা দিতে হয়েছিল। ক্রপ এবং ফিল্টার মত শুধু মৌলিক জিনিস. এমনকি সর্বশেষ লাইব্রেরি ব্যবহার করার সময়ও এটি 100% নির্ভরযোগ্য ছিল না এবং এটিকে অন্তত গ্রহণযোগ্য মাত্রায় ব্যবহারযোগ্য করার জন্য প্রচুর টুইকিংয়ের প্রয়োজন ছিল।


অনেক পরিস্থিতিতে একটি ফাইল আপলোড করা একটি প্রক্রিয়ার একটি গুরুত্বপূর্ণ ধাপ। উদাহরণস্বরূপ আপনি যখন একটি দীর্ঘ ফর্ম পূরণ করেন এবং শেষ ধাপে আপনাকে একটি ফাইল আপলোড করতে হবে।


যদি কোনো কারণে আপলোড ব্যর্থ হয়, তাহলে আপনাকে ব্যবহারকারীকে তার ইতিমধ্যেই রাখা সমস্ত ডেটা হারানো থেকে রক্ষা করতে হবে।


আপলোড ব্যর্থ হলে আপনাকে একটি দৃশ্যকল্প পরিচালনা করতে হবে, অথবা আপনি ফাইলটিতে আবেদন করেন এমন কোনো নিম্নলিখিত প্রক্রিয়া।


এই ধরনের কিছু সমস্যা সমাধানের একটি উপায় হল ব্যবহারকারীদের আকার এবং বিন্যাসে সীমাবদ্ধ করা। এটা লোভনীয় শোনাচ্ছে.


আমি সম্প্রতি একটি ইকমার্স প্রকল্পে কাজ করছিলাম যেখানে লোকেরা ফটো আপলোড করে তাদের নিজস্ব পণ্য তৈরি করতে সক্ষম হয়েছিল। অ্যাপটি যদিও ছবির আকার 2MB এবং 1000x1000px রেজোলিউশনে সীমাবদ্ধ করেছে।


এই সীমা 3MB এবং 2000x2000px করার প্রস্তাব ছিল। আমি আমার ফোন বের করলাম, একটি ছবি তুললাম এবং লোকেদের দেখালাম ছবির সাইজ কত।


এটি ছিল 4MB এবং প্রায় 3000x3000px। তাই এর জন্য আরেকটি প্রস্তাব করা হলো। তাই আমি আমার ফোনের সাথে একটি ফটো তোলার রেজোলিউশন বাড়িয়েছি এবং আমাদের বলেছি যে আমাদের এই সীমাগুলি সম্পূর্ণভাবে সরিয়ে ফেলতে হবে।


সীমা রাখার একটি প্রস্তাবও ছিল কারণ লোকেরা আপলোড করার আগে ফটোগুলিকে রূপান্তর করতে এবং সঙ্কুচিত করতে পারে।


এটা সঠিক. কিন্তু অধিকাংশ মানুষ এটা কিভাবে করতে হয় তা জানে না, এটা নিয়ে ভাবতে চায় না এবং এটা কঠিন মনে হতে পারে। আমি ক্লায়েন্ট এবং দলকে সীমাবদ্ধতা সম্পূর্ণভাবে তুলতে রাজি করতে সক্ষম হয়েছি।


এটি একটি দুর্দান্ত পদক্ষেপ ছিল কারণ এটি ব্যাপকভাবে বিক্রয় বৃদ্ধি করেছে এবং প্রস্থানের হার খুব কমে গেছে যা প্রমাণ করে যে লোকেরা তাদের ফোনে পণ্য কিনতে চায়, কিন্তু তারা প্রয়োজনীয়তার দ্বারা অবরুদ্ধ ছিল। অনেক লোককে তাদের কাঙ্খিত পণ্য কিনতে সক্ষম করার জন্য সীমা উত্তোলন করা একটি সহজ সমাধান ছিল।


ফাইল আপলোড করা একটি জলাভূমি, তবে কিছু ক্ষেত্রে এটি বিক্রয় এবং গ্রাহক সন্তুষ্টি (আবার বিক্রয়) এর জন্য গুরুত্বপূর্ণ হতে পারে।


এই কারণেই আমি সিস্টেমের এই ক্ষেত্রগুলিতে বিশেষ মনোযোগ দিই যে আমি ফাইল আপলোড পরিচালনা করি, কারণ এটি এমন একটি জায়গা যা গ্রাহক ব্যবসাকে সবচেয়ে বেশি প্রভাবিত করতে পারে।


আপনি কোন ফাইল আপলোড সম্পর্কিত গল্প আছে? মন্তব্যে শেয়ার করুন!


এছাড়াও হার্ট আইকনে ক্লিক করুন, সোশ্যাল মিডিয়ায় লাইক এবং শেয়ার করুন। এটা আমাকে অনুপ্রাণিত করে এরকম বিষয় নিয়ে আরো লিখতে!


আপনি যদি একজন সফ্টওয়্যার ইঞ্জিনিয়ার হিসাবে এটি সম্পর্কে খুব বেশি ভাবতে না চান তবে ফাইলস্ট্যাকটিও দেখুন। এটি জাভাস্ক্রিপ্ট ফাইল আপলোড পরিচালনা করার জন্য একটি API। তারা একটি প্রতিযোগীতা স্পনসর আমি এই গল্প সঙ্গে অংশগ্রহণ. ফাইলস্ট্যাক এবং হ্যাকারনুন - শেয়ার করার অনুপ্রেরণার জন্য ধন্যবাদ! এটা করতে মহান ছিল!