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

তৃতীয় স্থান - মাইক্রোসফ্ট সি কম্পাইলার

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

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

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

এটা একটা দুঃস্বপ্ন ছিল. অনেক বছর পরে আমাকে বলা হয়েছিল যে আমার কোডের উত্তরাধিকারী প্রোগ্রামার আমাকে ঘৃণা করে।

পাঠ শিখেছি

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

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

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

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

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

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

দ্বিতীয় স্থান: সামাজিক নেটওয়ার্কে বিজ্ঞাপন

যখন আমি গুগলে সোশ্যাল মিডিয়া বিজ্ঞাপনে কাজ করছিলাম (মাইস্পেস মনে আছে?), আমি C++ এ এরকম কিছু লিখেছিলাম:

for (int i = 0; i < user->interests->length(); i++) {
  for (int j = 0; j < user->interests(i)->keywords.length(); j++) {
      keywords->add(user->interests(i)->keywords(i)) {
  }
}

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

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

পাঠ শিখেছি

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

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

এখানে কি বলুন আইবিএমের কিংবদন্তি প্রধান টমাস ওয়াটসন সম্পর্কে:

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

ওয়াটসন জিজ্ঞাসা করলেন কি ভুল হয়েছে।

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

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

আমার কাছে একটি টি-শার্ট আছে যাতে লেখা আছে: "যদি আপনি সত্যিই ভুল থেকে শিখেন, তাহলে আমি ইতিমধ্যেই একজন মাস্টার।" আসলে, যখন ত্রুটি আসে, আমি বিজ্ঞানের একজন ডাক্তার।

প্রথম স্থান: অ্যাপ উদ্ভাবক API

সত্যিই ভয়ানক ত্রুটিগুলি বিপুল সংখ্যক ব্যবহারকারীকে প্রভাবিত করে, জনসাধারণের জ্ঞানে পরিণত হয়, সংশোধন করতে দীর্ঘ সময় নেয় এবং যারা সেগুলি তৈরি করতে পারেনি তাদের দ্বারা করা হয়৷ আমার সবচেয়ে বড় ভুল এই সব মানদণ্ড ফিট করে.

যত খারাপ তত ভালো

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

এটি কেমন হওয়া উচিত: নকশাটি বাস্তবায়ন এবং ইন্টারফেসে সহজ হওয়া উচিত। ইন্টারফেসের সরলতা বাস্তবায়নের সরলতার চেয়ে বেশি গুরুত্বপূর্ণ।

খারাপ, ভাল: নকশা বাস্তবায়ন এবং ইন্টারফেস সহজ হতে হবে. বাস্তবায়নের সরলতা ইন্টারফেসের সরলতার চেয়ে বেশি গুরুত্বপূর্ণ।

আসুন এক মিনিটের জন্য এটি সম্পর্কে ভুলে যাই। দুর্ভাগ্যবশত, আমি অনেক বছর ধরে এটি সম্পর্কে ভুলে গেছি।

অ্যাপ উদ্ভাবক

গুগলে কাজ করার সময়, আমি দলের অংশ ছিলাম অ্যাপ উদ্ভাবক, উচ্চাকাঙ্ক্ষী Android বিকাশকারীদের জন্য একটি ড্র্যাগ-এন্ড-ড্রপ অনলাইন উন্নয়ন পরিবেশ৷ এটি ছিল 2009, এবং আমরা সময়মতো আলফা সংস্করণ প্রকাশ করার জন্য তাড়াহুড়ো করেছিলাম যাতে গ্রীষ্মে আমরা শিক্ষকদের জন্য মাস্টার ক্লাস করতে পারি যারা শরত্কালে পাঠদানের সময় পরিবেশ ব্যবহার করতে পারে। আমি TI-99/4-এ কীভাবে গেম লিখতাম তার জন্য আমি নস্টালজিক, স্প্রিট বাস্তবায়ন করতে স্বেচ্ছাসেবক হয়েছি। যারা জানেন না তাদের জন্য, একটি স্প্রাইট একটি দ্বি-মাত্রিক গ্রাফিকাল অবজেক্ট যা অন্য সফ্টওয়্যার উপাদানগুলির সাথে সরানো এবং যোগাযোগ করতে পারে। স্প্রাইটের উদাহরণগুলির মধ্যে রয়েছে স্পেসশিপ, গ্রহাণু, মার্বেল এবং র্যাকেট।

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

একটি বল এবং একটি স্প্রাইট মধ্যে প্রধান পার্থক্য ঠিক কি আঁকা হয় - একটি ভরা বৃত্ত বা একটি রাস্টার। যেহেতু আমি প্রথমে স্প্রাইট প্রয়োগ করেছি, তাই ছবিটি যেখানে অবস্থিত ছিল তার উপরের বাম কোণে x- এবং y- স্থানাঙ্কগুলি নির্দিষ্ট করা যৌক্তিক ছিল।

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

প্রকৃতপক্ষে, বৃত্তের কেন্দ্রের x- এবং y-স্থানাঙ্কগুলি নির্দেশ করার প্রয়োজন ছিল, যেমনটি গণিতের পাঠ্যপুস্তক এবং বৃত্তের উল্লেখ করে এমন অন্য কোনো উত্সে শেখানো হয়েছে।

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

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

পাঠ শিখেছি

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

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

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

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

উপসংহার

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

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

উত্স: www.habr.com