প্রোগ্রামার এবং ইঞ্জিনিয়ারদের লোককাহিনী (পর্ব 1)

এটি ইন্টারনেট থেকে গল্পগুলির একটি নির্বাচন যে কীভাবে বাগগুলি কখনও কখনও সম্পূর্ণ অবিশ্বাস্য প্রকাশ করে। সম্ভবত আপনারও কিছু বলার আছে।

ভ্যানিলা আইসক্রিমে গাড়ির অ্যালার্জি

প্রকৌশলীদের জন্য একটি গল্প যারা বোঝেন যে সুস্পষ্ট সবসময় উত্তর হয় না, এবং ঘটনাগুলি যতই দূরবর্তী মনে হোক না কেন, তারা এখনও সত্য। জেনারেল মোটর কর্পোরেশনের পন্টিয়াক বিভাগ একটি অভিযোগ পেয়েছে:

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

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

ইঞ্জিনিয়ার সাহেব এলেন আরও তিনটে সন্ধ্যায়। প্রথমবার আইসক্রিম ছিল চকোলেট। গাড়ি স্টার্ট দিল। দ্বিতীয়বার ছিল স্ট্রবেরি আইসক্রিম। গাড়ি স্টার্ট দিল। তৃতীয় সন্ধ্যায় তিনি ভ্যানিলা নিতে বললেন। গাড়ি স্টার্ট দেয়নি।

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

প্রকৌশলী শীঘ্রই বুঝতে পেরেছিলেন যে গাড়ির মালিক ভ্যানিলা আইসক্রিম কিনতে কম সময় ব্যয় করেছেন। কারণ ছিল দোকানে মালামালের বিন্যাস। ভ্যানিলা আইসক্রিম সবচেয়ে জনপ্রিয় ছিল এবং এটি খুঁজে পাওয়া সহজ করার জন্য স্টোরের সামনে একটি আলাদা ফ্রিজে রাখা হয়েছিল। এবং অন্যান্য সমস্ত জাতগুলি স্টোরের পিছনে ছিল এবং সঠিক বৈচিত্র্য খুঁজে পেতে এবং অর্থ প্রদান করতে আরও অনেক বেশি সময় লেগেছিল।

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

নৈতিক: এমনকি সম্পূর্ণ পাগল সমস্যা কখনও কখনও বাস্তব হয়.

ক্র্যাশ ধেড়ে

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

এখানে হার্ডওয়্যার বাগ সম্পর্কে আমার গল্প.

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

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

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

যখন আপনার কাছে ডিবাগিং করার কোন ধারনা থাকে না, তখন একমাত্র পন্থা বাকি থাকে "বিভক্ত করুন এবং জয় করুন": ত্রুটিপূর্ণ প্রোগ্রাম থেকে আরও বেশি সংখ্যক কোড সরিয়ে ফেলুন যতক্ষণ না অপেক্ষাকৃত ছোট টুকরো অবশিষ্ট থাকে যা এখনও সমস্যা সৃষ্টি করে। অর্থাৎ, আপনি প্রোগ্রামটিকে টুকরো টুকরো করে কেটে ফেলবেন যতক্ষণ না বাগটি থাকা অংশটি অবশিষ্ট থাকে।

কিন্তু বিষয় হল, একটি ভিডিও গেম থেকে অংশগুলি কাটা খুব কঠিন। আপনি যদি মাধ্যাকর্ষণ অনুকরণ করে এমন কোডটি সরিয়ে ফেলেন তবে কীভাবে এটি চালাবেন? নাকি অক্ষর আঁকা?

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

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

এটি আমাকে কোডের একটি ছোট টুকরো দিয়ে রেখেছিল যা এখনও উপরের সমস্যাটি ছিল - তবে এটি এখনও এলোমেলোভাবে ঘটছিল! প্রায়শই সবকিছু ঠিকঠাক কাজ করে, তবে মাঝে মাঝে ত্রুটি ছিল। আমি প্রায় সমস্ত গেম কোড মুছে ফেলেছি, কিন্তু বাগটি এখনও জীবিত ছিল। এটি বিস্ময়কর ছিল: অবশিষ্ট কোড আসলে কিছুই করেনি।

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

একটি ঘড়ির সাহায্যে, প্রসেসরের সাথে সরাসরি সংযুক্ত নয় এমন একটি ডিভাইস প্রসেসরে কার্যকর করা কোডের সাথে সিঙ্ক্রোনাইজ করা হয়। ঘড়িটি বড রেট নির্ধারণ করে - যে গতিতে ডেটা প্রেরণ করা হয়। যদি সময় নিয়ে বিভ্রান্তি থাকে, তবে হয় হার্ডওয়্যার বা সফ্টওয়্যার, বা উভয়ই বিভ্রান্ত হয়। এবং এটি খুব খারাপ, কারণ ডেটা ক্ষতিগ্রস্ত হতে পারে।

যদি আমাদের কোডে কিছু সময়কে বিভ্রান্ত করে? আমি পরীক্ষার প্রোগ্রাম কোডে এর সাথে সম্পর্কিত সবকিছু পরীক্ষা করেছি এবং লক্ষ্য করেছি যে আমরা PS1-এ প্রোগ্রামযোগ্য টাইমার সেট করেছি 1 kHz (প্রতি সেকেন্ডে 1000 টিক্স)। এটি অনেক বেশি; ডিফল্টরূপে, যখন কনসোল শুরু হয়, এটি 100 Hz এ চলে। এবং বেশিরভাগ গেম এই ফ্রিকোয়েন্সি ব্যবহার করে।

অ্যান্ডি, গেম ডেভেলপার, টাইমারটি 1 kHz এ সেট করেছেন যাতে গতিবিধি আরও সঠিকভাবে গণনা করা যায়। অ্যান্ডি ওভারবোর্ডে যাওয়ার প্রবণতা রাখে, এবং যদি আমরা মাধ্যাকর্ষণ অনুকরণ করি, আমরা যথাসম্ভব নির্ভুলভাবে তা করি!

কিন্তু যদি টাইমারের গতি বাড়ানো কোনভাবে প্রোগ্রামের সামগ্রিক সময়কে প্রভাবিত করে, এবং সেইজন্য ঘড়ি যা মেমরি কার্ডের জন্য বড রেট নিয়ন্ত্রণ করে?

আমি টাইমার কোড মন্তব্য. ত্রুটি আবার ঘটল না. কিন্তু এর মানে এই নয় যে আমরা এটি ঠিক করেছি, কারণ ব্যর্থতা এলোমেলোভাবে ঘটেছে। আমি যদি ভাগ্যবান হতাম?

কয়েকদিন পরে আমি আবার পরীক্ষা প্রোগ্রাম নিয়ে পরীক্ষা করলাম। বাগ পুনরাবৃত্তি হয়নি. আমি পুরো গেম কোডবেসে ফিরে গিয়েছিলাম এবং সংরক্ষণ এবং লোড কোডটি সংশোধন করেছি যাতে মেমরি কার্ড অ্যাক্সেস করার আগে প্রোগ্রামেবল টাইমারটি তার আসল মান (100Hz) রিসেট করে এবং তারপরে 1kHz এ পুনরায় সেট করে। আর কোন ক্র্যাশ ছিল না.

কিন্তু কেন এমন হল?

আমি আবার পরীক্ষা প্রোগ্রাম ফিরে. আমি 1 kHz টাইমারের সাথে একটি ত্রুটির ক্ষেত্রে কিছু প্যাটার্ন খুঁজে বের করার চেষ্টা করেছি। অবশেষে আমি লক্ষ্য করেছি যে যখন কেউ একটি PS1 কন্ট্রোলারের সাথে খেলে তখন ত্রুটি ঘটে। যেহেতু আমি খুব কমই এটি নিজে করব - কেন সংরক্ষণ এবং লোড কোড পরীক্ষা করার সময় আমার একটি নিয়ামক প্রয়োজন হবে? - আমি এই নির্ভরতাও লক্ষ্য করিনি। কিন্তু একদিন আমাদের একজন শিল্পী পরীক্ষা শেষ করার জন্য আমার জন্য অপেক্ষা করছিলেন - আমি সম্ভবত সেই মুহুর্তে অভিশাপ দিচ্ছিলাম - এবং নার্ভাসভাবে তার হাতে কন্ট্রোলারটি ঘুরিয়ে দিয়েছিল। একটি ত্রুটি উৎপন্ন হয়েছে. "কিসের অপেক্ষা?!" আচ্ছা, আবার কর!”

যখন আমি বুঝতে পারি যে এই দুটি ঘটনা পরস্পর সংযুক্ত ছিল, তখন আমি সহজেই ত্রুটিটি পুনরুত্পাদন করতে সক্ষম হয়েছিলাম: আমি মেমরি কার্ডে রেকর্ডিং শুরু করেছিলাম, নিয়ামকটি সরিয়ে দিয়েছিলাম এবং মেমরি কার্ডটি নষ্ট করেছিলাম। আমার কাছে এটি একটি হার্ডওয়্যার বাগ মত লাগছিল.

আমি কনির কাছে এসে তাকে আমার আবিষ্কারের কথা বললাম। তিনি PS1 ডিজাইন করা একজন প্রকৌশলীর কাছে তথ্য রিলে করেছিলেন। "অসম্ভব," তিনি উত্তর দিয়েছিলেন, "এটি একটি হার্ডওয়্যার সমস্যা হতে পারে না।" আমি কনিকে আমাদের জন্য কথোপকথনের ব্যবস্থা করতে বললাম।

প্রকৌশলী আমাকে ডেকেছিলেন এবং আমরা তার ভাঙা ইংরেজিতে এবং আমার (অত্যন্ত) ভাঙা জাপানি ভাষায় তর্ক করেছি। অবশেষে আমি বলেছিলাম, "আমাকে আমার 30 লাইনের পরীক্ষার প্রোগ্রাম পাঠাতে দিন যেখানে নিয়ামক সরানো একটি বাগ সৃষ্টি করে।" তিনি একমত. বলেছিলেন যে এটি একটি সময়ের অপচয় ছিল এবং তিনি একটি নতুন প্রকল্পে কাজ করার জন্য ভয়ানকভাবে ব্যস্ত ছিলেন, কিন্তু আমরা ছেড়ে দেব কারণ আমরা সোনির জন্য একটি অত্যন্ত গুরুত্বপূর্ণ বিকাশকারী। আমি আমার পরীক্ষার প্রোগ্রাম পরিষ্কার করে তাকে পাঠিয়েছিলাম।

পরের দিন সন্ধ্যায় (আমরা লস অ্যাঞ্জেলেসে ছিলাম এবং তিনি টোকিওতে ছিলেন) তিনি আমাকে ফোন করেছিলেন এবং ভয়ঙ্করভাবে ক্ষমা চেয়েছিলেন। এটি একটি হার্ডওয়্যার সমস্যা ছিল।

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

কিন্তু নীচের লাইন হল যে মাদারবোর্ডের উপাদানগুলির মধ্যে হস্তক্ষেপ ছিল। এবং কন্ট্রোলার পোর্ট এবং 1 kHz এ চলমান টাইমার সহ মেমরি কার্ড পোর্টের মাধ্যমে একযোগে ডেটা প্রেরণ করার সময়, বিটগুলি হারিয়ে গিয়েছিল, ডেটা হারিয়ে গিয়েছিল এবং কার্ডটি ক্ষতিগ্রস্থ হয়েছিল।

খারাপ গরু

1980-এর দশকে, আমার পরামর্শদাতা সের্গেই SM-1800-এর জন্য সফ্টওয়্যার লিখেছিলেন, PDP-11-এর একটি সোভিয়েত ক্লোন। এই মাইক্রোকম্পিউটারটি সবেমাত্র ইউএসএসআর-এর একটি গুরুত্বপূর্ণ পরিবহন কেন্দ্র Sverdlovsk-এর কাছে একটি রেলস্টেশনে ইনস্টল করা হয়েছে। নতুন সিস্টেমটি ওয়াগন এবং মালবাহী ট্রাফিক রুট করার জন্য ডিজাইন করা হয়েছিল। কিন্তু এটিতে একটি বিরক্তিকর বাগ রয়েছে যা এলোমেলোভাবে ক্র্যাশ এবং ক্র্যাশের দিকে পরিচালিত করে। সন্ধ্যায় কেউ বাড়িতে গেলে সর্বদা জলপ্রপাত ঘটে। কিন্তু পরের দিন পুঙ্খানুপুঙ্খ তদন্ত সত্ত্বেও, কম্পিউটারটি সমস্ত ম্যানুয়াল এবং স্বয়ংক্রিয় পরীক্ষায় সঠিকভাবে কাজ করেছিল। এটি সাধারণত একটি রেস শর্ত বা অন্য কিছু প্রতিযোগিতামূলক বাগ নির্দেশ করে যা নির্দিষ্ট শর্তে ঘটে। গভীর রাতে কলে ক্লান্ত হয়ে, সের্গেই এটির নীচে যাওয়ার সিদ্ধান্ত নিয়েছিল এবং প্রথমেই বুঝতে পারে যে মার্শালিং ইয়ার্ডে কী পরিস্থিতি কম্পিউটারের বিপর্যয় ঘটায়।

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

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

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

গবাদিপশুগুলি কেবল প্রচুর পরিমাণে বিকিরণ নির্গত করেনি, এর মাত্রা এত বেশি ছিল যে এটি স্টেশনের পাশের একটি বিল্ডিংয়ে অবস্থিত এসএম-1800-এর স্মৃতিতে বিটগুলির এলোমেলো ক্ষতির দিকে পরিচালিত করেছিল।

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

পাইপের মাধ্যমে

এক সময়, মুভিটেক সলিউশনস সিনেমার জন্য সফটওয়্যার তৈরি করেছিল, যা অ্যাকাউন্টিং, টিকিট বিক্রয় এবং সাধারণ ব্যবস্থাপনার জন্য ডিজাইন করা হয়েছিল। ফ্ল্যাগশিপ অ্যাপের ডস সংস্করণটি উত্তর আমেরিকার ছোট এবং মাঝারি আকারের মুভি থিয়েটার চেইনের মধ্যে বেশ জনপ্রিয় ছিল। সুতরাং এটা আশ্চর্যের কিছু নয় যে যখন একটি Windows 95 সংস্করণ ঘোষণা করা হয়েছিল, সর্বশেষ টাচ স্ক্রিন এবং স্ব-পরিষেবা কিয়স্কগুলির সাথে একীভূত করা হয়েছিল, এবং সমস্ত ধরণের রিপোর্টিং সরঞ্জামগুলির সাথে সজ্জিত হয়েছিল, এটি দ্রুত জনপ্রিয় হয়ে ওঠে। প্রায়শই আপডেটটি সমস্যা ছাড়াই চলে যায়। স্থানীয় আইটি কর্মীরা নতুন সরঞ্জাম ইনস্টল করেছে, ডেটা স্থানান্তরিত করেছে এবং ব্যবসা চালিয়ে গেছে। বাদে যখন তা স্থায়ী হয়নি। যখন এটি ঘটেছিল, কোম্পানি জেমসকে পাঠাবে, ডাকনাম "দ্য ক্লিনার।"

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

অতএব, এটা আশ্চর্যের কিছু নয় যে এই ব্যস্ত সময়ে, জেমস সকালে অফিসে পৌঁছেছিলেন, এবং তার ডেস্কে পৌঁছানোর আগেই, ম্যানেজার তাকে স্বাগত জানিয়েছিলেন, স্বাভাবিকের বাইরে ক্যাফিনে ভরা।

"আমি ভয় পাচ্ছি যে আপনাকে যত তাড়াতাড়ি সম্ভব নোভা স্কটিয়ার আনাপোলিসে যেতে হবে।" তাদের পুরো সিস্টেমটি ভেঙে গেছে, এবং তাদের প্রকৌশলীদের সাথে কাজ করার এক রাতের পরে, আমরা বুঝতে পারি না যে কী হয়েছিল। দেখে মনে হচ্ছে সার্ভারে নেটওয়ার্ক ব্যর্থ হয়েছে৷ কিন্তু কয়েক মিনিট ধরে সিস্টেম চালু থাকার পরই।

- তারা পুরানো সিস্টেমে ফিরে আসেনি? - জেমস সম্পূর্ণ গম্ভীরভাবে উত্তর দিল, যদিও মানসিকভাবে সে বিস্ময়ে চোখ মেলেছে।

— সঠিকভাবে: তাদের আইটি বিশেষজ্ঞ "অগ্রাধিকার পরিবর্তন করেছেন" এবং তাদের পুরানো সার্ভারের সাথে চলে যাওয়ার সিদ্ধান্ত নিয়েছেন। জেমস, তারা ছয়টি সাইটে সিস্টেমটি ইনস্টল করেছে এবং শুধুমাত্র প্রিমিয়াম সমর্থনের জন্য অর্থ প্রদান করেছে এবং তাদের ব্যবসা এখন 1950 এর দশকের মতোই চালানো হচ্ছে।

জেমস একটু সোজা হল।

-সেটা অন্য ব্যাপার। ঠিক আছে, শুরু করা যাক.

যখন তিনি আনাপোলিসে পৌঁছেন, তখন তিনি প্রথম কাজটি করেছিলেন গ্রাহকের প্রথম থিয়েটারটি খুঁজে পান যেটিতে সমস্যা ছিল। বিমানবন্দরে নেওয়া মানচিত্রে, সবকিছু শালীন দেখায়, তবে পছন্দসই ঠিকানার চারপাশের এলাকাটি সন্দেহজনক বলে মনে হয়েছিল। ঘেটো নয়, ফিল্ম নোয়ারের কথা মনে করিয়ে দেয়। জেমস যখন কার্ব ডাউনটাউনে পার্ক করেছিল, তখন একজন পতিতা তার কাছে এসেছিল। অ্যানাপোলিসের আকারের পরিপ্রেক্ষিতে, সম্ভবত পুরো শহরে এটিই একমাত্র ছিল। তার উপস্থিতি অবিলম্বে বিখ্যাত চরিত্রের কথা মনে এনেছিল যিনি বড় পর্দায় অর্থের জন্য যৌনতার প্রস্তাব দিয়েছিলেন। না, জুলিয়া রবার্টস সম্পর্কে নয়, জন ভয়েট সম্পর্কে ["মিডনাইট কাউবয়" ছবির ইঙ্গিত - প্রায়। গলি].

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

সিনেমার পাশের প্রবেশদ্বারটি ছিল একটি অন্ধকার গলিতে। জেমস দরজায় গিয়ে নক করল। শীঘ্রই এটি creaked এবং সামান্য খোলা.

-আপনি কি ক্লিনার? - ভেতর থেকে একটা কর্কশ আওয়াজ এল।

- হ্যাঁ, আমিই... আমি সব ঠিক করতে এসেছি।

জেমস সিনেমার লবিতে চলে গেল। দৃশ্যত অন্য কোন বিকল্প না থাকায় কর্মীরা দর্শকদের কাগজের টিকিট দিতে শুরু করে। এটি আর্থিক প্রতিবেদনকে কঠিন করে তুলেছে, আরও আকর্ষণীয় বিবরণ ছেড়ে দিন। কিন্তু কর্মীরা স্বস্তির সাথে জেমসকে অভ্যর্থনা জানিয়ে সাথে সাথে সার্ভার রুমে নিয়ে যায়।

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

জেমস মার্ককে ডেকে পরিস্থিতির কথা জানায়। এটা কল্পনা করা কঠিন নয় যে জেমস চারপাশে লেগে থাকতে এবং অপ্রত্যাশিত কিছু ঘটে কিনা তা দেখতে চাইতে পারে। তিনি সিঁড়ি দিয়ে নেমে কর্মচারীদের জিজ্ঞাসা করতে লাগলেন কি হয়েছে। স্পষ্টতই সিস্টেমটি কাজ করা বন্ধ করে দিয়েছে। তারা এটি বন্ধ এবং চালু, সবকিছু কাজ. কিন্তু 10 মিনিটের পরে সিস্টেমটি বন্ধ হয়ে যায়।

ঠিক এই মুহুর্তে একইরকম কিছু ঘটেছে। হঠাৎ করেই টিকিট ব্যবস্থায় ত্রুটি দেখা দিতে শুরু করে। কর্মীরা দীর্ঘশ্বাস ফেলে কাগজের টিকিট ধরল, আর জেমস দ্রুত সার্ভার রুমে চলে গেল। সার্ভারের সাথে সবকিছু ভাল লাগছিল।

তখন একজন কর্মচারী প্রবেশ করেন।

- সিস্টেম আবার কাজ করছে।

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

- সিস্টেম ডাউন.

জেমস সার্ভারের দিকে তাকাল। বহু রঙের আকৃতির একটি আকর্ষণীয় এবং পরিচিত প্যাটার্ন পর্দায় নাচছে - বিশৃঙ্খলভাবে ঘোলাটে এবং আন্তঃসম্পর্কিত পাইপগুলি। আমরা সব কিছু সময়ে এই স্ক্রিনসেভার দেখেছি. এটি সুন্দরভাবে রেন্ডার করা হয়েছে এবং আক্ষরিক অর্থেই সম্মোহিত করা হয়েছে।

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

- সিস্টেম আবার কাজ করছে।

আপনি যদি মানসিক ফেসপাম করতে পারেন তবে জেমস ঠিক তাই করেছেন। স্ক্রিনসেভার। এটি OpenGL ব্যবহার করে। এবং সেইজন্য, অপারেশন চলাকালীন, এটি সার্ভার প্রসেসরের সমস্ত সংস্থান গ্রাস করে। ফলস্বরূপ, সার্ভারে প্রতিটি কল একটি সময় শেষ হয়ে যায়।

জেমস সার্ভার রুমে ফিরে এল, লগ ইন করলো এবং স্ক্রিনসেভারের বদলে খালি স্ক্রিন দিয়ে সুন্দর পাইপগুলো বসিয়ে দিল। অর্থাৎ, 100% প্রসেসর সংস্থান ব্যবহার করে এমন একটি স্ক্রিনসেভারের পরিবর্তে, আমি অন্য একটি ইনস্টল করেছি যা সংস্থানগুলি ব্যবহার করে না। তারপর আমি আমার অনুমান চেক করার জন্য 10 মিনিট অপেক্ষা করলাম।

জেমস যখন পরের সিনেমায় এলেন, তখন তিনি ভাবছিলেন কীভাবে তার ম্যানেজারকে বোঝাবেন যে তিনি স্ক্রিন সেভারটি বন্ধ করতে মাত্র 800 কিমি উড়ে এসেছিলেন।

চাঁদের একটি নির্দিষ্ট পর্যায়ে ক্র্যাশ

সত্য গল্প. একদিন একটি সফ্টওয়্যার বাগ দেখা দেয় যা চাঁদের ধাপের উপর নির্ভর করে। একটি ছোট রুটিন ছিল যা সাধারণত চাঁদের প্রকৃত পর্বের আনুমানিকতা গণনা করার জন্য বিভিন্ন এমআইটি প্রোগ্রামে ব্যবহৃত হত। GLS এই রুটিনটিকে একটি LISP প্রোগ্রামে তৈরি করেছে যা, একটি ফাইল লেখার সময়, প্রায় 80 অক্ষর দীর্ঘ টাইমস্ট্যাম্প সহ একটি লাইন আউটপুট করবে। এটি খুব বিরল ছিল যে একটি বার্তার প্রথম লাইনটি খুব দীর্ঘ হয়ে শেষ হবে এবং পরবর্তী লাইনে নিয়ে যাবে। এবং যখন প্রোগ্রাম পরে এই ফাইল পড়া, এটা অভিশাপ. প্রথম লাইনের দৈর্ঘ্য সঠিক তারিখ এবং সময়ের উপর নির্ভর করে, সেইসাথে টাইমস্ট্যাম্প মুদ্রণের সময় ফেজ স্পেসিফিকেশনের দৈর্ঘ্যের উপর নির্ভর করে। অর্থাৎ, বাগটি আক্ষরিক অর্থেই চাঁদের ধাপের উপর নির্ভর করে!

প্রথম কাগজ সংস্করণ জার্গন ফাইল (স্টিল-1983) এমন একটি লাইনের উদাহরণ রয়েছে যা বর্ণিত বাগটির দিকে পরিচালিত করেছিল, কিন্তু টাইপসেটার এটিকে "স্থির করেছে"। এটিকে "মুন ফেজ বাগ" হিসাবে বর্ণনা করা হয়েছে।

যাইহোক, অনুমানের সাথে সতর্ক থাকুন। কয়েক বছর আগে, CERN (European Center for Nuclear Research) এর প্রকৌশলীরা লার্জ ইলেক্ট্রন-পজিট্রন কোলাইডারে করা পরীক্ষায় ত্রুটির সম্মুখীন হয়েছিলেন। যেহেতু কম্পিউটারগুলি বিজ্ঞানীদের ফলাফল দেখানোর আগে এই ডিভাইসের দ্বারা উত্পন্ন বিপুল পরিমাণ ডেটা সক্রিয়ভাবে প্রক্রিয়া করে, তাই অনেকেই অনুমান করেছিলেন যে সফ্টওয়্যারটি চাঁদের পর্যায়ের জন্য কোনওভাবে সংবেদনশীল ছিল৷ বেশ কিছু মরিয়া প্রকৌশলী সত্যের গভীরে পৌঁছেছেন। 27 কিলোমিটার দীর্ঘ বলয়ের জ্যামিতিতে সামান্য পরিবর্তনের কারণে ত্রুটিটি দেখা দিয়েছে চাঁদের উত্তরণের সময় পৃথিবীর বিকৃতির কারণে! এই গল্পটি পদার্থবিজ্ঞানের লোককাহিনীতে "নিউটনের প্রতিশোধ অন পার্টিকেল ফিজিক্স" হিসাবে প্রবেশ করেছে এবং পদার্থবিজ্ঞানের সবচেয়ে সহজ এবং প্রাচীনতম আইন এবং সবচেয়ে উন্নত বৈজ্ঞানিক ধারণাগুলির মধ্যে সংযোগের একটি উদাহরণ।

টয়লেট ফ্লাশ করলে ট্রেন থামে

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

একটি চেক করার সময়, ট্রেনে ভ্রমণকারী একজন ইঞ্জিনিয়ার টয়লেটে যান। সে শীঘ্রই ভেসে গেল, বুম! জরুরী বিরতি.

প্রকৌশলী ড্রাইভারের সাথে যোগাযোগ করে জিজ্ঞাসা করলেন:

- আপনি ব্রেক করার ঠিক আগে কি করছিলেন?

- আচ্ছা, আমি নামার গতি কমিয়ে দিয়েছি...

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

- আমি ধীর গতিতে যাচ্ছি.

কিছুই ঘটেনি.

- শেষ ব্রেকিংয়ের সময় আপনি কী করেছিলেন? - ড্রাইভার জিজ্ঞেস করল।

- আচ্ছা... আমি টয়লেটে ছিলাম...

-আচ্ছা, তাহলে টয়লেটে যাও আর আমরা আবার নিচে গেলে তুমি যা করলে!

প্রকৌশলী টয়লেটে গিয়েছিলেন, এবং ড্রাইভার যখন সতর্ক করেছিলেন: "আমি গতি কম করছি," তিনি জল ফ্লাশ করলেন। অবশ্য সঙ্গে সঙ্গে ট্রেন থামল।

এখন তারা সমস্যাটি পুনরুত্পাদন করতে পারে এবং কারণ খুঁজে বের করতে হবে।

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

গেটওয়ে যে FORTRAN ঘৃণা

কয়েক মাস আগে আমরা লক্ষ্য করেছি যে মূল ভূখণ্ডে [এটি হাওয়াইতে ছিল] নেটওয়ার্ক সংযোগগুলি খুব, খুব ধীর হয়ে যাচ্ছে৷ এটি 10-15 মিনিটের জন্য স্থায়ী হতে পারে এবং তারপরে হঠাৎ আবার ঘটতে পারে। কিছু সময় পর, আমার সহকর্মী আমাকে অভিযোগ করেন যে মূল ভূখণ্ডে নেটওয়ার্ক সংযোগ সাধারণভাবে কাজ করে না. তার কাছে কিছু FORTRAN কোড ছিল যা মূল ভূখণ্ডের একটি মেশিনে অনুলিপি করা প্রয়োজন, কিন্তু এটি সম্ভব হয়নি কারণ "নেটওয়ার্কটি FTP আপলোড সম্পূর্ণ করার জন্য যথেষ্ট সময় ধরে রাখে নি।"

হ্যাঁ, দেখা গেল যে নেটওয়ার্ক ব্যর্থতা ঘটেছে যখন একজন সহকর্মী মূল ভূখণ্ডের একটি মেশিনে FORTRAN-এ সোর্স কোড সহ একটি ফাইল FTP করার চেষ্টা করেছিল৷ আমরা ফাইলটি সংরক্ষণাগার করার চেষ্টা করেছি: তারপর এটি মসৃণভাবে অনুলিপি করা হয়েছিল (কিন্তু লক্ষ্য মেশিনে একটি আনপ্যাকার ছিল না, তাই সমস্যাটি সমাধান করা হয়নি)। অবশেষে আমরা FORTRAN কোডটিকে খুব ছোট ছোট টুকরো করে "বিভক্ত" করেছিলাম এবং সেগুলিকে একবারে পাঠিয়েছিলাম। বেশিরভাগ টুকরো সমস্যা ছাড়াই অনুলিপি করা হয়েছিল, কিন্তু কয়েকটি টুকরা পাস করেনি বা পরে পাস করেনি অনেক প্রচেষ্টা

যখন আমরা সমস্যাযুক্ত প্যাসেজগুলি পরীক্ষা করেছি, তখন আমরা আবিষ্কার করেছি যে তাদের মধ্যে কিছু মিল রয়েছে: সেগুলির সবকটিতে মন্তব্য ব্লক রয়েছে যা শুরু এবং শেষ হয়েছে ক্যাপিটাল সি সমন্বিত লাইন দিয়ে (যেমন একজন সহকর্মী FORTRAN এ মন্তব্য করতে পছন্দ করেন)। আমরা মূল ভূখণ্ডে নেটওয়ার্ক বিশেষজ্ঞদের ইমেল করেছি এবং সাহায্য চেয়েছি। অবশ্যই, তারা আমাদের ফাইলগুলির নমুনা দেখতে চেয়েছিল যেগুলি FTP-এর মাধ্যমে স্থানান্তর করা যায় না... কিন্তু আমাদের চিঠিগুলি তাদের কাছে পৌঁছায়নি৷ অবশেষে আমরা একটি সহজ সঙ্গে এসেছি বর্ণনা করাঅ-হস্তান্তরযোগ্য ফাইল দেখতে কেমন। এটা কাজ করেছে :) [আমি এখানে সমস্যাযুক্ত FORTRAN মন্তব্যের একটি উদাহরণ যোগ করার সাহস করি? সম্ভবত এটি মূল্যহীন!]

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

কঠিন সময়

কয়েক বছর আগে, ফেজ 40 ক্লিনিকাল ট্রায়ালের খরচ কমাতে পার্লে একটি ETL সিস্টেম তৈরির কাজ করার সময়, আমাকে প্রায় 000 তারিখ প্রক্রিয়া করতে হয়েছিল। তাদের মধ্যে দুজন পরীক্ষায় পাস করেনি। এটি আমাকে খুব বেশি বিরক্ত করেনি কারণ এই তারিখগুলি ক্লায়েন্ট-প্রদত্ত ডেটা থেকে নেওয়া হয়েছিল যা প্রায়শই ছিল, আমরা কি বলব, আশ্চর্যজনক। কিন্তু যখন আমি আসল ডেটা চেক করলাম, তখন দেখা গেল যে এই তারিখগুলি জানুয়ারী 1, 2011 এবং 1 জানুয়ারী, 2007। আমি ভেবেছিলাম যে বাগটি আমার লেখা প্রোগ্রামটিতে রয়েছে, কিন্তু দেখা গেল যে এটি ইতিমধ্যে 30 বছর হয়ে গেছে। পুরাতন যারা সফটওয়্যার ইকোসিস্টেমের সাথে অপরিচিত তাদের কাছে এটি রহস্যময় মনে হতে পারে। অর্থ উপার্জন করার জন্য অন্য একটি কোম্পানির দীর্ঘস্থায়ী সিদ্ধান্তের কারণে, আমার ক্লায়েন্ট আমাকে একটি বাগ সংশোধন করার জন্য অর্থ প্রদান করেছে যা একটি কোম্পানি দুর্ঘটনাক্রমে এবং অন্যটি উদ্দেশ্যমূলকভাবে প্রবর্তন করেছিল। আমি যে বিষয়ে কথা বলছি তা বুঝতে আপনার জন্য, আমাকে সেই কোম্পানির কথা বলতে হবে যেটি বৈশিষ্ট্যটি যোগ করেছে যা একটি বাগ পরিণত হয়েছে, সেইসাথে আরও কয়েকটি আকর্ষণীয় ইভেন্ট যা আমি ঠিক করা রহস্যময় বাগটিতে অবদান রেখেছিল৷

ভাল পুরানো দিনে, অ্যাপল কম্পিউটারগুলি কখনও কখনও স্বতঃস্ফূর্তভাবে তাদের তারিখ 1 জানুয়ারী, 1904 এ পুনরায় সেট করত। কারণটি সহজ ছিল: তারিখ এবং সময় ট্র্যাক রাখতে এটি একটি ব্যাটারি চালিত "সিস্টেম ঘড়ি" ব্যবহার করেছিল। ব্যাটারি মারা গেলে কী হয়েছিল? কম্পিউটারগুলি একটি যুগের শুরু থেকে সেকেন্ডের সংখ্যা দ্বারা তারিখ ট্র্যাক করতে শুরু করে। যুগের দ্বারা আমরা রেফারেন্সের আসল তারিখ বোঝাতে চেয়েছিলাম, এবং ম্যাকিনটোশের জন্য এটি ছিল জানুয়ারী 1, 1904। এবং ব্যাটারি মারা যাওয়ার পরে, বর্তমান তারিখটি নির্দিষ্ট তারিখে পুনরায় সেট করা হয়েছিল। কিন্তু কেন এমন হল?

পূর্বে, অ্যাপল আসল তারিখ থেকে সেকেন্ডের সংখ্যা সংরক্ষণ করতে 32 বিট ব্যবহার করত। এক বিট দুটি মানের একটি সংরক্ষণ করতে পারে - 1 বা 0। দুটি বিট চারটি মানের একটি সংরক্ষণ করতে পারে: 00, 01, 10, 11। তিনটি বিট - আটটির মধ্যে একটি মান: 000, 001, 010, 011, 100 , 101, 110, 111, ইত্যাদি। এবং 32 232 মানের মধ্যে একটি সংরক্ষণ করতে পারে, অর্থাৎ 4 সেকেন্ড। অ্যাপলের তারিখের জন্য, এটি প্রায় 294 বছরের সমান, তাই পুরোনো ম্যাকগুলি 967 সালের পরে তারিখগুলি পরিচালনা করতে পারে না। এবং যদি সিস্টেমের ব্যাটারিটি মারা যায়, তাহলে যুগের শুরু থেকে তারিখটি 296 সেকেন্ডে রিসেট করা হয় এবং আপনি প্রতিবার কম্পিউটার চালু করার সময় (বা আপনি একটি নতুন ব্যাটারি না কেনা পর্যন্ত) আপনাকে ম্যানুয়ালি তারিখটি সেট করতে হবে।

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

এগিয়ে যান. আমরা লোটাস 1-2-3 ব্যবহার করেছি, আইবিএমের "হত্যাকারী অ্যাপ্লিকেশন" যা পিসি বিপ্লব চালু করতে সাহায্য করেছিল, যদিও অ্যাপল কম্পিউটারে ভিসিক্যালক ছিল, যা ব্যক্তিগত কম্পিউটারকে সফল করেছে। ন্যায্যভাবে, 1-2-3 উপস্থিত না হলে, পিসিগুলি খুব কমই বন্ধ হয়ে যেত, এবং ব্যক্তিগত কম্পিউটারের ইতিহাস খুব আলাদাভাবে বিকশিত হতে পারত। লোটাস 1-2-3 ভুলভাবে 1900 কে অধিবর্ষ হিসাবে গণ্য করা হয়েছে। মাইক্রোসফ্ট যখন তার প্রথম স্প্রেডশীট, মাল্টিপ্ল্যান প্রকাশ করে, তখন এটি বাজারের একটি ছোট অংশ দখল করে। এবং যখন তারা এক্সেল প্রজেক্ট চালু করে, তখন তারা লোটাস 1-2-3 থেকে শুধুমাত্র সারি এবং কলামের নামকরণ স্কিমটি অনুলিপি করার সিদ্ধান্ত নেয় না, কিন্তু ইচ্ছাকৃতভাবে 1900 কে লিপ ইয়ার হিসাবে বিবেচনা করে বাগ সামঞ্জস্যতা নিশ্চিত করারও সিদ্ধান্ত নেয়। এই সমস্যা আজও বিদ্যমান। তাই 1-2-3-এ এটি একটি বাগ ছিল, কিন্তু Excel-এ এটি একটি সচেতন সিদ্ধান্ত ছিল যে সমস্ত 1-2-3 ব্যবহারকারীরা ডেটা পরিবর্তন না করেই তাদের টেবিলগুলিকে Excel এ আমদানি করতে পারে, যদিও এটি ভুল ছিল।

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

আমার ETL সিস্টেম গ্রাহকদের কাছ থেকে এক্সেল স্প্রেডশীট পেয়েছে যা Windows-এ তৈরি করা হয়েছে, কিন্তু Mac এও তৈরি করা যেতে পারে। সুতরাং, সারণীতে যুগের সূচনা হতে পারে 1 জানুয়ারী, 1900, বা 1 জানুয়ারী, 1904। কিভাবে খুঁজে বের করতে? এক্সেল ফাইল বিন্যাস প্রয়োজনীয় তথ্য দেখায়, কিন্তু আমি যে পার্সারটি ব্যবহার করেছি তা দেখায়নি (এখন এটি করে), এবং ধরে নেওয়া হয়েছে যে আপনি একটি নির্দিষ্ট টেবিলের জন্য যুগ জানেন। আমি সম্ভবত এক্সেল বাইনারি বিন্যাসটি বুঝতে এবং পার্সার লেখকের কাছে একটি প্যাচ পাঠাতে আরও বেশি সময় ব্যয় করতে পারতাম, তবে ক্লায়েন্টের জন্য আমার আরও অনেক কিছু করার ছিল, তাই আমি দ্রুত যুগ নির্ধারণের জন্য একটি হিউরিস্টিক লিখেছিলাম। তিনি সহজ সরল ছিল.

এক্সেলে, 5 জুলাই, 1998 তারিখটি "07-05-98" (অকেজো আমেরিকান সিস্টেম), "জুলাই 5, 98", "5 জুলাই, 1998", "5-জুলাই-98" ফর্ম্যাটে উপস্থাপন করা যেতে পারে অন্য কিছু ফরম্যাট। অন্য একটি অকেজো ফরম্যাট (আড়ম্বরপূর্ণভাবে, আমার এক্সেলের সংস্করণ যে ফর্ম্যাটটি অফার করেনি তার মধ্যে একটি হল ISO 8601)। যাইহোক, টেবিলের মধ্যে, বিন্যাসহীন তারিখটি epoch-35981-এর জন্য "1900" বা epoch-34519-এর জন্য "1904" হিসাবে সংরক্ষিত ছিল (সংখ্যাগুলি যুগের পর থেকে দিনের সংখ্যাকে প্রতিনিধিত্ব করে)। আমি বিন্যাসিত তারিখ থেকে বছর বের করতে একটি সাধারণ পার্সার ব্যবহার করেছি এবং তারপরে আনফরম্যাট করা তারিখ থেকে বছর বের করতে এক্সেল পার্সার ব্যবহার করেছি। যদি উভয় মান 4 বছর দ্বারা পৃথক হয়, তাহলে আমি জানতাম যে আমি epoch-1904 এর সাথে একটি সিস্টেম ব্যবহার করছি।

কেন আমি শুধু ফরম্যাট করা তারিখ ব্যবহার করিনি? কারণ 5 জুলাই, 1998 কে হারানো মাসের দিন দিয়ে "জুলাই, 98" হিসাবে ফর্ম্যাট করা যেতে পারে। আমরা এতগুলি সংস্থার কাছ থেকে টেবিল পেয়েছি যেগুলি তাদের বিভিন্ন উপায়ে তৈরি করেছে যে তারিখগুলি বের করা আমাদের (এই ক্ষেত্রে, আমার) উপর নির্ভর করে। উপরন্তু, যদি এক্সেল এটি সঠিক পায়, তাহলে আমাদেরও উচিত!

একই সময়ে আমি 39082 এর সম্মুখীন হলাম। আমি আপনাকে মনে করিয়ে দিই যে লোটাস 1-2-3 1900 কে একটি লিপ ইয়ার হিসাবে বিবেচনা করেছিল এবং এটি এক্সেল এ বিশ্বস্তভাবে পুনরাবৃত্তি হয়েছিল। এবং যেহেতু এটি 1900 সালে একটি দিন যোগ করেছে, তাই সেই দিনের জন্য অনেক তারিখ গণনা ফাংশন ভুল হতে পারে। অর্থাৎ, 39082 1 জানুয়ারী, 2011 (ম্যাকগুলিতে) বা 31 ডিসেম্বর, 2006 (উইন্ডোজে) হতে পারে। যদি আমার "বছর পার্সার" ফর্ম্যাট করা মান থেকে 2011 সাল বের করে, তাহলে সবকিছু ঠিক আছে। কিন্তু যেহেতু এক্সেল পার্সার জানে না কোন যুগটি ব্যবহার করা হচ্ছে, তাই এটি ডিফল্ট epoch-1900, 2006 সালে ফিরে আসে। আমার অ্যাপ্লিকেশন দেখেছে যে পার্থক্যটি 5 বছর, এটি একটি ত্রুটি হিসাবে বিবেচিত হয়েছে, এটি লগ করেছে এবং একটি বিন্যাসহীন মান ফিরিয়ে দিয়েছে৷

এটি প্রায় পেতে, আমি এটি লিখেছিলাম (ছদ্মকোড):

diff = formatted_year - parsed_year
if 0 == diff
    assume 1900 date system
if 4 == diff
    assume 1904 date system
if 5 == diff and month is December and day is 31
    assume 1904 date system

এবং তারপর সমস্ত 40 তারিখ সঠিকভাবে পার্স করা হয়েছে।

বড় প্রিন্ট কাজের মাঝখানে

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

তারা ড্রাইভগুলিকে নতুন করে ডিজাইন করেছে যাতে তাদের একটি কেন্দ্রীয় "A" ড্রাইভ সাতটি "B" ড্রাইভের সাথে সংযুক্ত থাকতে পারে এবং RAM-এর ছোট OS যেটি "A" ড্রাইভ নিয়ন্ত্রণ করে তা সমস্ত "B" ড্রাইভে রিড এবং রাইট অপারেশন অর্পণ করতে পারে।

প্রতিবার ড্রাইভ "A" শুরু করার সময়, অপারেটিং সিস্টেমটিকে তার মেমরিতে লোড করার জন্য "A" এর সাথে সংযুক্ত পেরিফেরাল ড্রাইভে একটি ফ্লপি ডিস্ক সন্নিবেশ করা প্রয়োজন। এটি অত্যন্ত আদিম ছিল: একটি 8-বিট মাইক্রোকন্ট্রোলার দ্বারা কম্পিউটিং শক্তি সরবরাহ করা হয়েছিল।

এই ধরনের সরঞ্জামগুলির লক্ষ্য দর্শকরা ছিল অনেক বড় ডেটা গুদাম সহ সংস্থাগুলি - ব্যাঙ্ক, খুচরা চেইন ইত্যাদি - যেগুলির প্রচুর ঠিকানা লেবেল বা ব্যাঙ্ক স্টেটমেন্ট প্রিন্ট করার প্রয়োজন ছিল৷

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

স্টোরেজ টেকনোলজিস থেকে প্রযুক্তিবিদদের পাঠানো হয়েছিল। কিন্তু তাদের সর্বোত্তম প্রচেষ্টা সত্ত্বেও, তারা পরীক্ষার শর্তে বাগটি পুনরুত্পাদন করতে পারেনি: এটি বড় প্রিন্ট কাজের মাঝখানে ঘটতে পারে বলে মনে হচ্ছে। সমস্যাটি হার্ডওয়্যারের ছিল না, তারা যা করতে পারে তা প্রতিস্থাপন করেছে: RAM, মাইক্রোকন্ট্রোলার, ফ্লপি ড্রাইভ, টেপ ড্রাইভের প্রতিটি অনুমেয় অংশ - সমস্যাটি অব্যাহত ছিল।

এরপর টেকনিশিয়ানরা হেডকোয়ার্টারে ডেকে এক্সপার্ট ডেকে পাঠান।

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

বিশেষজ্ঞ আবার চেয়ারে বসে ব্যর্থতার জন্য অপেক্ষা করতে লাগলেন। প্রায় ছয় ঘন্টা কেটে গেছে এবং ব্যর্থতা ঘটেছে। বিশেষজ্ঞের আবার কোন ধারনা ছিল না, শুধু মানুষে ভরা রুমে সবকিছু ঘটেছিল। তিনি মিশনটি পুনরায় চালু করার নির্দেশ দিয়েছিলেন, আবার বসে রইলেন এবং অপেক্ষা করতে লাগলেন।

তৃতীয় ব্যর্থতার মাধ্যমে, বিশেষজ্ঞ কিছু লক্ষ্য করেছেন। ব্যর্থতা ঘটেছিল যখন কর্মীরা একটি বিদেশী ড্রাইভে টেপ পরিবর্তন করেছিল। তদুপরি, একজন কর্মচারী মেঝেতে একটি নির্দিষ্ট টালি দিয়ে হেঁটে যাওয়ার সাথে সাথে ব্যর্থতা ঘটেছিল।

উত্থিত মেঝেটি 6 থেকে 8 ইঞ্চি উচ্চতায় অ্যালুমিনিয়াম টাইলস দিয়ে তৈরি। কম্পিউটারের অসংখ্য তারগুলি উত্থাপিত মেঝেটির নীচে চলে গেছে যাতে কেউ দুর্ঘটনাক্রমে একটি গুরুত্বপূর্ণ তারের উপর পা রাখতে না পারে। উত্থাপিত মেঝেতে ধ্বংসাবশেষ যাতে না যায় সে জন্য টাইলসগুলি খুব শক্তভাবে স্থাপন করা হয়েছিল।

বিশেষজ্ঞ বুঝতে পেরেছিলেন যে একটি টাইলস বিকৃত ছিল। যখন একজন কর্মচারী এটির কোণে পা রাখেন, তখন টাইলের প্রান্তগুলি পার্শ্ববর্তী টাইলের সাথে ঘষে যায়। টাইলসের সাথে সংযুক্ত প্লাস্টিকের অংশগুলিও তাদের সাথে ঘষে, যা স্ট্যাটিক মাইক্রোডিসচার্জ সৃষ্টি করে যা রেডিও ফ্রিকোয়েন্সি হস্তক্ষেপ তৈরি করে।

আজ, RAM রেডিও ফ্রিকোয়েন্সি হস্তক্ষেপ থেকে অনেক ভাল সুরক্ষিত। কিন্তু ২০ বছরে এমনটা হয়নি। বিশেষজ্ঞ বুঝতে পেরেছিলেন যে এই হস্তক্ষেপ স্মৃতিকে ব্যাহত করেছে এবং এর সাথে অপারেটিং সিস্টেমের অপারেশন। তিনি সমর্থন পরিষেবাকে কল করেছিলেন, নতুন টাইলস অর্ডার করেছিলেন, সেগুলি নিজেই ইনস্টল করেছিলেন এবং সমস্যাটি অদৃশ্য হয়ে গিয়েছিল।

এটা উচ্চ জোয়ার!

গল্পটি পোর্টসমাউথের একটি অফিসের চতুর্থ বা পঞ্চম তলায় একটি সার্ভার রুমে সংঘটিত হয়েছিল (আমার মনে হয়), ডকস এলাকায়।

একদিন প্রধান ডাটাবেস সহ ইউনিক্স সার্ভার ক্র্যাশ হয়ে গেল। তারা তাকে রিবুট করেছিল, কিন্তু সে সুখে বারবার পড়ে যেতে থাকে। আমরা সমর্থন পরিষেবা থেকে কাউকে কল করার সিদ্ধান্ত নিয়েছি।

সমর্থনকারী লোক... আমার মনে হয় তার নাম ছিল মার্ক, কিন্তু তাতে কিছু যায় আসে না... আমার মনে হয় না আমি তাকে চিনি। এটা কোন ব্যাপার না, সত্যিই. আসুন মার্কের সাথে লেগে থাকি, ঠিক আছে? দারুণ।

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

একই সন্ধ্যায় সার্ভার আবার ক্র্যাশ হয়. গল্প একই... সার্ভার উঠে না। মার্ক দূর থেকে সাহায্য করার চেষ্টা করে, কিন্তু ক্লায়েন্ট সার্ভার শুরু করতে পারে না।

আরেকটি ট্রেন, বাস, লেমন মেরিঙ্গু বা অন্য কিছু বাজে কথা, এবং মার্ক পোর্টসমাউথ ফিরে এসেছে। দেখুন, সার্ভার কোন সমস্যা ছাড়াই বুট! অলৌকিক ঘটনা. অপারেটিং সিস্টেম বা সফ্টওয়্যারের সাথে সবকিছু ঠিকঠাক আছে কিনা তা পরীক্ষা করতে মার্ক কয়েক ঘন্টা ব্যয় করে এবং লিডসের উদ্দেশ্যে যাত্রা করে।

দিনের মাঝখানে সার্ভার ক্র্যাশ হয় (এটি সহজ নিন!) এইবার সার্ভার প্রতিস্থাপনের জন্য হার্ডওয়্যার সমর্থনকারী লোকদের আনা যুক্তিসঙ্গত বলে মনে হচ্ছে। কিন্তু না, প্রায় 10 ঘন্টা পরে এটিও পড়ে যায়।

বেশ কয়েকদিন ধরে পরিস্থিতির পুনরাবৃত্তি ঘটে। সার্ভার কাজ করে, প্রায় 10 ঘন্টা পরে ক্র্যাশ হয় এবং পরবর্তী 2 ঘন্টার জন্য শুরু হয় না। তারা কুলিং চেক করেছে, মেমরি লিক করেছে, তারা সবকিছু চেক করেছে, কিন্তু কিছুই পায়নি। তারপর ক্র্যাশ বন্ধ হয়ে যায়।

সপ্তাহটা নিশ্চিন্তে কেটে গেল... সবাই খুশি। সব আবার শুরু না হওয়া পর্যন্ত খুশি। ছবিও একই। 10 ঘন্টা কাজ, 2-3 ঘন্টা ডাউনটাইম...

এবং তারপরে কেউ (আমি মনে করি তারা আমাকে বলেছিল যে এই ব্যক্তির আইটির সাথে কোনও সম্পর্ক নেই) বলেছেন:

"এটা জোয়ার!"

বিস্ময়কর শব্দটি ফাঁকা দৃষ্টিতে দেখা গিয়েছিল, এবং কারও হাত সম্ভবত নিরাপত্তা কল বোতামে দ্বিধা করেছিল।

"এটি জোয়ারের সাথে কাজ করা বন্ধ করে দেয়।"

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

"গত সপ্তাহে জোয়ার কম ছিল, কিন্তু এই সপ্তাহে তা বেশি।"

যাদের ইয়ট লাইসেন্স নেই তাদের জন্য একটু পরিভাষা। জোয়ার চন্দ্র চক্রের উপর নির্ভর করে। এবং পৃথিবী ঘোরার সাথে সাথে প্রতি 12,5 ঘন্টায় সূর্য এবং চাঁদের মহাকর্ষীয় টান একটি জোয়ারের তরঙ্গ তৈরি করে। 12,5-ঘন্টা চক্রের শুরুতে একটি উচ্চ জোয়ার হয়, চক্রের মাঝখানে একটি ভাটা থাকে এবং শেষে আবার একটি উচ্চ জোয়ার হয়। কিন্তু চাঁদের কক্ষপথের পরিবর্তনের সাথে সাথে নিম্ন এবং উচ্চ জোয়ারের পার্থক্যও ঘটে। যখন চাঁদ সূর্য এবং পৃথিবীর মাঝখানে থাকে বা পৃথিবীর বিপরীত দিকে থাকে (পূর্ণিমা বা চাঁদ নেই), তখন আমরা সিজিজিন জোয়ার পাই - সর্বোচ্চ উচ্চ জোয়ার এবং সর্বনিম্ন ভাটা। অর্ধচন্দ্রে আমরা চতুর্ভুজ জোয়ার পাই - সর্বনিম্ন জোয়ার। দুই চরমের মধ্যে পার্থক্য অনেক কমে যায়। চন্দ্র চক্র 28 দিন স্থায়ী হয়: সিজিজিয়ান - চতুর্ভুজ - সিজিজিয়ান - চতুর্ভুজ।

যখন টেকনিশিয়ানদের জোয়ারের শক্তির সারমর্ম ব্যাখ্যা করা হয়েছিল, তারা অবিলম্বে ভেবেছিল যে তাদের পুলিশকে কল করা দরকার। এবং বেশ যৌক্তিক। কিন্তু দেখা যাচ্ছে ভাই ঠিক ছিল। দুই সপ্তাহ আগে, একটি ডেস্ট্রয়ার অফিস থেকে দূরে ছিল না। প্রতিবার জোয়ার এটিকে একটি নির্দিষ্ট উচ্চতায় উন্নীত করে, জাহাজের রাডার পোস্টটি সার্ভার রুমের মেঝের স্তরে শেষ হয়। এবং রাডার (বা ইলেকট্রনিক যুদ্ধ সরঞ্জাম, বা অন্য কিছু সামরিক খেলনা) কম্পিউটারে বিশৃঙ্খলা সৃষ্টি করেছিল।

রকেটের জন্য ফ্লাইট মিশন

আমাকে একটি বড় (প্রায় 400 হাজার লাইন) রকেট লঞ্চ কন্ট্রোল এবং মনিটরিং সিস্টেম অপারেটিং সিস্টেম, কম্পাইলার এবং ভাষার নতুন সংস্করণে পোর্ট করার দায়িত্ব দেওয়া হয়েছিল। আরও স্পষ্ট করে বললে, সোলারিস 2.5.1 থেকে সোলারিস 7 পর্যন্ত, এবং অ্যাডা 83-এ লেখা ভার্ডিক্স অ্যাডা ডেভেলপমেন্ট সিস্টেম (VADS) থেকে, অ্যাডা 95-এ লেখা Rational Apex Ada সিস্টেম পর্যন্ত। VADS Rational দ্বারা কেনা হয়েছিল এবং এর পণ্য ছিল অপ্রচলিত, যদিও Rational অ্যাপেক্স কম্পাইলারে রূপান্তর সহজ করার জন্য VADS-নির্দিষ্ট প্যাকেজগুলির সামঞ্জস্যপূর্ণ সংস্করণগুলি প্রয়োগ করার চেষ্টা করেছিল।

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

আর থ্যাঙ্কসগিভিংয়ের আগের শুক্রবার ফোনটা বেজে উঠল।

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

পূর্ববর্তী মাসগুলিতে, এই কাউন্টডাউন চ্যালেঞ্জটি কয়েকশ বার বিভিন্ন পরিবর্তনে চালানো হয়েছিল, শুধুমাত্র কয়েকটি ছোটখাটো হেঁচকি সহ। সুতরাং এটি ঘটার সম্ভাবনা খুবই কম ছিল, কিন্তু এর পরিণতি ছিল খুবই তাৎপর্যপূর্ণ। এই উভয় কারণকে গুণ করুন, এবং আপনি বুঝতে পারবেন যে খবরটি আমার এবং কয়েক ডজন প্রকৌশলী এবং পরিচালকদের জন্য একটি ধ্বংসপ্রাপ্ত ছুটির সপ্তাহের পূর্বাভাস দিয়েছে।

এবং সিস্টেমটি পোর্ট করা ব্যক্তি হিসাবে আমার প্রতি মনোযোগ দেওয়া হয়েছিল।

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

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

যেহেতু জার্নালগুলিতে আকর্ষণীয় কিছু ছিল না, তাই আমরা স্থানীয় পরীক্ষাগারে সমস্যাটি পুনরুত্পাদন করার চেষ্টা করার সিদ্ধান্ত নিয়েছি। এটি একটি সহজ কাজ ছিল না যেহেতু ইভেন্টটি প্রতি 1000 রানে প্রায় একবার ঘটেছিল। একটি সন্দেহজনক কারণ ছিল যে একটি বিক্রেতা-উন্নত মিউটেক্স ফাংশনে একটি কল (VADS মাইগ্রেশন প্যাকেজের অংশ) Unlock আনলকিং নেতৃত্বে না. প্রসেসিং থ্রেড যা ফাংশনকে বলে প্রসেসড হার্টবিট মেসেজ, যা নামমাত্র প্রতি সেকেন্ডে আসে। আমরা ফ্রিকোয়েন্সি 10 Hz এ উন্নীত করেছি, অর্থাৎ প্রতি সেকেন্ডে 10 বার, এবং চলতে শুরু করেছি। প্রায় এক ঘন্টা পরে সিস্টেমটি নিজেই লক হয়ে যায়। লগে, আমরা দেখেছি যে রেকর্ড করা বার্তাগুলির ক্রম ব্যর্থ পরীক্ষার সময় একই ছিল৷ আমরা আরও অনেক রান করেছি, সিস্টেমটি শুরু হওয়ার 45-90 মিনিট পরে ধারাবাহিকভাবে ব্লক করা হয়েছিল এবং প্রতিবার লগে একই রুট রয়েছে। যদিও আমরা প্রযুক্তিগতভাবে ভিন্ন কোড চালাচ্ছিলাম - বার্তা ফ্রিকোয়েন্সি ভিন্ন ছিল - সিস্টেমের আচরণ একই ছিল, তাই আমরা আত্মবিশ্বাসী ছিলাম যে এই লোড পরিস্থিতি একই সমস্যা সৃষ্টি করছে।

এখন আমাদের বুঝতে হবে যে অভিব্যক্তির ক্রমটিতে ব্লকিংটি ঠিক কোথায় ঘটেছে।

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

আমি এই টাস্ক মেকানিজমটি বর্ণনা করেছি কারণ যখন একটি মিলনকে অনুরোধ করা হয়েছিল বা সম্পূর্ণ হওয়ার আশা করা হয়েছিল, তখন একটি "টাস্ক সুইচ" ঘটতে পারে। অর্থাৎ, প্রসেসর অন্য একটি টাস্ক প্রক্রিয়াকরণ শুরু করতে পারে যা কার্যকর করার জন্য প্রস্তুত। দেখা যাচ্ছে যে যখন একটি টাস্ক অন্য টাস্কের সাথে মিলিত হওয়ার জন্য প্রস্তুত হয়, তখন একটি সম্পূর্ণ ভিন্ন টাস্ক কার্যকর করা শুরু করতে পারে এবং শেষ পর্যন্ত নিয়ন্ত্রণটি প্রথম মিলনস্থলে ফিরে আসে। এবং অন্যান্য ঘটনা ঘটতে পারে যার কারণে কাজটি পরিবর্তন হয়; এই ধরনের একটি ইভেন্ট হল একটি সিস্টেম ফাংশনের জন্য একটি কল, যেমন একটি mutex মুদ্রণ বা চালানো।

কোডের কোন লাইনটি সমস্যা সৃষ্টি করছে তা বোঝার জন্য, আমাকে একটি টাস্ক সুইচ ট্রিগার না করে বিবৃতিগুলির একটি অনুক্রমের মাধ্যমে অগ্রগতি রেকর্ড করার একটি উপায় খুঁজে বের করতে হবে, যা ক্র্যাশ হওয়া থেকে প্রতিরোধ করবে। তাই সুবিধা নিতে পারিনি Put_Line()I/O অপারেশন সম্পাদন এড়াতে। আমি একটি কাউন্টার ভেরিয়েবল বা অনুরূপ কিছু সেট করতে পারি, কিন্তু আমি কীভাবে এটির মান দেখতে পারি যদি আমি এটি স্ক্রিনে প্রদর্শন করতে না পারি?

এছাড়াও, লগ পরীক্ষা করার সময়, এটি প্রমাণিত হয়েছিল যে, হার্টবিট বার্তাগুলির প্রক্রিয়াকরণে হিমায়িত হওয়া সত্ত্বেও, যা প্রক্রিয়াটির সমস্ত I/O ক্রিয়াকলাপকে অবরুদ্ধ করে এবং অন্যান্য প্রক্রিয়াকরণকে সঞ্চালিত হতে বাধা দেয়, অন্যান্য স্বাধীন কাজগুলি সম্পাদন করা অব্যাহত ছিল। অর্থাৎ, কাজটি সম্পূর্ণরূপে অবরুদ্ধ করা হয়নি, শুধুমাত্র একটি (সমালোচনামূলক) কাজের শৃঙ্খল।

এটি ব্লকিং এক্সপ্রেশন মূল্যায়ন করার জন্য প্রয়োজনীয় সূত্র ছিল।

আমি একটি Ada প্যাকেজ তৈরি করেছি যাতে একটি টাস্ক, একটি গণনাকৃত টাইপ এবং সেই ধরনের একটি গ্লোবাল ভেরিয়েবল ছিল। অগণিত আক্ষরিক সমস্যাযুক্ত অনুক্রমের নির্দিষ্ট অভিব্যক্তিতে আবদ্ধ ছিল (যেমন Incrementing_Buffer_Index, Locking_Mutex, Mutex_Unlocked), এবং তারপর এটিতে অ্যাসাইনমেন্ট এক্সপ্রেশনগুলি সন্নিবেশ করান যা একটি বিশ্ব পরিবর্তনশীলের সাথে সংশ্লিষ্ট গণনাকে বরাদ্দ করে। যেহেতু এই সমস্ত বস্তুর কোডটি কেবল মেমরিতে একটি ধ্রুবক সঞ্চয় করে, তাই এটি কার্যকর করার ফলে টাস্ক স্যুইচিং অত্যন্ত অসম্ভাব্য ছিল। আমরা প্রাথমিকভাবে অভিব্যক্তিগুলির বিষয়ে সন্দেহজনক ছিলাম যা টাস্কটি স্যুইচ করতে পারে, যেহেতু টাস্কটি ফিরে যাওয়ার সময় (অনেক কারণে) ফিরে আসার পরিবর্তে কার্যকর করার সময় ব্লক করা হয়েছিল।

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

এটি প্রত্যাশিত ছিল যে সিস্টেমটি যখন সমস্যাযুক্ত কোড কার্যকর করার পর্যায়ে পৌঁছেছে, প্রতিটি পরবর্তী এক্সপ্রেশনে যাওয়ার সময় গ্লোবাল ভেরিয়েবল রিসেট করা হবে। তারপরে এমন কিছু ঘটবে যা টাস্কটি স্যুইচ করে, এবং যেহেতু এটির এক্সিকিউশন ফ্রিকোয়েন্সি (10 Hz) মনিটরিং টাস্কের তুলনায় কম, তাই মনিটর গ্লোবাল ভেরিয়েবলের মান ক্যাপচার করতে পারে এবং লিখতে পারে। একটি স্বাভাবিক পরিস্থিতিতে, আমি গণনার একটি উপসেটের পুনরাবৃত্তিমূলক ক্রম পেতে পারি: টাস্ক স্যুইচের সময় ভেরিয়েবলের শেষ মান। হ্যাং করার সময়, গ্লোবাল ভেরিয়েবল আর পরিবর্তন করা উচিত নয় এবং লেখা শেষ মানটি নির্দেশ করবে কোন এক্সপ্রেশনটি সম্পূর্ণ হয়নি।

আমি ট্র্যাকিং সঙ্গে কোড রান. সে জমে গেল। এবং মনিটরিং ঘড়ির কাঁটার মতো কাজ করেছিল।

লগটিতে প্রত্যাশিত ক্রম রয়েছে, যা একটি মান দ্বারা বাধাগ্রস্ত হয়েছিল যা নির্দেশ করে যে একটি মিউটেক্স কল করা হয়েছে Unlock, এবং কাজটি সম্পূর্ণ হয়নি - যেমনটি হাজার হাজার পূর্ববর্তী কলের ক্ষেত্রে।

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

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

আমি এটি কোডে সন্নিবেশিত করেছি এবং পরীক্ষা চালিয়েছি। সাত ঘন্টা পরেও কোডটি কাজ করছিল।

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

এটি ছিল আমার ক্যারিয়ারের সবচেয়ে জমজমাট কোড পর্যালোচনা 🙂 আমার সাথে রুমে প্রায় দশজন ইঞ্জিনিয়ার এবং ম্যানেজার ছিলেন, আরও দশজন লোক একটি কনফারেন্স কলে ছিলেন - এবং তারা সবাই প্রায় 20 লাইনের কোড পরীক্ষা করেছেন।

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

ঠিক আছে, সব ভাল এবং ভাল, কিন্তু গল্পের বিন্দু কি?

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

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

আমি সমস্যার প্রকৃতি বুঝতে পেরেছি। আমি ঠিক জানতাম না কোথায় ঘটছে বা কেন, কিন্তু আমি জানতাম কি ঘটছে।

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

কোডের সাথে সংগ্রামের এই ধরনের গল্পগুলি তাদের জন্য খুব আকর্ষণীয় নয় যারা এই জাতীয় সংগ্রামের বৈশিষ্ট্য এবং শর্তগুলির সাথে পরিচিত নয়। কিন্তু এই গল্পগুলি আমাদের বুঝতে সাহায্য করে যে এটি সত্যিই কঠিন সমস্যার সমাধান করতে কি লাগে।

সত্যিই কঠিন সমস্যা সমাধানের জন্য, আপনাকে শুধু একজন প্রোগ্রামার হতে হবে না। আপনাকে কোডটির "ভাগ্য" বুঝতে হবে, এটি কীভাবে এর পরিবেশের সাথে মিথস্ক্রিয়া করে এবং পরিবেশ নিজেই কীভাবে কাজ করে।

এবং তারপরে আপনার নিজের নষ্ট ছুটির সপ্তাহ থাকবে।

অবিরত করা।

উত্স: www.habr.com