পাইথন কোডের 4 মিলিয়ন লাইন টাইপচেক করার পথ। অংশ 2

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

→ প্রথম অংশ পড়ুন

অফিসিয়াল টাইপ সাপোর্ট (PEP 484)

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

সেই সময়ে, পাইথন টাইপ ইঙ্গিত সিস্টেমগুলিকে প্রমিত করার ধারণাটি বাতাসে ছিল। আমি যেমন বলেছি, পাইথন 3.0 থেকে ফাংশনগুলির জন্য টাইপ টীকা ব্যবহার করা সম্ভব ছিল, তবে এগুলি সংজ্ঞায়িত সিনট্যাক্স এবং শব্দার্থবিদ্যা ছাড়াই ছিল কেবলমাত্র নির্বিচারে অভিব্যক্তি। প্রোগ্রাম সঞ্চালনের সময়, এই টীকাগুলি বেশিরভাগ অংশে উপেক্ষা করা হয়েছিল। হ্যাক সপ্তাহের পর, আমরা শব্দার্থবিদ্যাকে মানসম্মত করার জন্য কাজ শুরু করি। এই কাজ উত্থান নেতৃত্বে পিইপি 484 (Guido van Rossum, Łukasz Langa এবং আমি এই নথিতে সহযোগিতা করেছি)।

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

টাইপ ইঙ্গিত সিনট্যাক্স যা অবশেষে গৃহীত হয়েছিল mypy সেই সময়ে যা সমর্থন করেছিল তার সাথে খুব মিল ছিল। PEP 484 পাইথন 3.5 এর সাথে 2015 সালে প্রকাশিত হয়েছিল। পাইথন আর গতিশীলভাবে টাইপ করা ভাষা ছিল না। আমি এই ইভেন্টটিকে পাইথনের ইতিহাসে একটি উল্লেখযোগ্য মাইলফলক হিসেবে ভাবতে চাই।

অভিবাসনের শুরু

2015 সালের শেষের দিকে, ড্রপবক্স মাইপিতে কাজ করার জন্য তিনজনের একটি দল তৈরি করেছে। তাদের মধ্যে রয়েছে গুইডো ভ্যান রসাম, গ্রেগ প্রাইস এবং ডেভিড ফিশার। সেই মুহূর্ত থেকে, পরিস্থিতি খুব দ্রুত বিকাশ করতে শুরু করে। মাইপির বৃদ্ধির প্রথম বাধা ছিল কর্মক্ষমতা। আমি উপরে ইঙ্গিত দিয়েছি, প্রকল্পের প্রথম দিকে আমি সি-তে mypy বাস্তবায়ন অনুবাদ করার কথা ভেবেছিলাম, কিন্তু এই ধারণাটি আপাতত তালিকার বাইরে চলে গেছে। আমরা CPython ইন্টারপ্রেটার ব্যবহার করে সিস্টেম চালানোর সাথে আটকে গিয়েছিলাম, যা mypy এর মতো সরঞ্জামগুলির জন্য যথেষ্ট দ্রুত নয়। (PyPy প্রকল্প, একটি JIT কম্পাইলারের সাথে একটি বিকল্প পাইথন বাস্তবায়ন, আমাদেরও সাহায্য করেনি।)

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

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

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

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

আরও উত্পাদনশীলতা!

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

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

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

এমনকি আরও বেশি উত্পাদনশীলতা!

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

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

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

কম্পাইলার, যাকে আমরা mypyc বলে ডাকি (যেহেতু এটি প্রকার বিশ্লেষণের জন্য ফ্রন্ট-এন্ড হিসাবে mypy ব্যবহার করে), এটি একটি খুব সফল প্রকল্প হিসাবে পরিণত হয়েছে। সামগ্রিকভাবে, আমরা ক্যাশিং ছাড়াই ঘন ঘন মাইপি রানের জন্য প্রায় 4x গতি অর্জন করেছি। মাইপিইসি প্রকল্পের মূল বিকাশ করতে মাইকেল সুলিভান, ইভান লেভকিভস্কি, হিউ হ্যান এবং আমার একটি ছোট দল প্রায় 4 ক্যালেন্ডার মাস নিয়েছিল। এই পরিমাণ কাজ mypy পুনরায় লেখার জন্য যা প্রয়োজন হতো তার চেয়ে অনেক কম ছিল, উদাহরণস্বরূপ, C++ বা Go এ। এবং অন্য ভাষায় এটি পুনর্লিখন করার সময় আমাদের যা করতে হতো তার চেয়ে আমাদের প্রকল্পে অনেক কম পরিবর্তন করতে হয়েছিল। আমরা আশা করেছিলাম যে আমরা মাইপিসিকে এমন একটি স্তরে আনতে পারব যাতে অন্যান্য ড্রপবক্স প্রোগ্রামাররা তাদের কোড কম্পাইল এবং গতি বাড়াতে এটি ব্যবহার করতে পারে।

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

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

চলবে…

প্রিয় পাঠকগণ! আপনি যখন মাইপি প্রকল্পের অস্তিত্ব সম্পর্কে জানতে পেরেছিলেন তখন আপনার ছাপ কী ছিল?

উত্স: www.habr.com