DHH এবং Rails: কনভেনশন কীভাবে ওয়েব অ্যাপ দ্রুত শিপ করাতে সাহায্য করলো

কেন রেইলস আগের তুলনায় দ্রুত মনে হত

রেইলসের আগের যুগে ওয়েব অ্যাপ বানানো প্রায়ই শুরু হতো দীর্ঘ একটি “সেটআপ করো”-কাজ দিয়ে। আপনি ফোল্ডার স্ট্রাকচার বাছাই করতেন (বা বানাতেন), ঠিক করতেন কীভাবে URL কোডের সাথে ম্যাপ করবে, ডাটাবেজ কানেকশন হাত দিয়ে সেট আপ করতেন, আর একরকমের গ্লু কোড বারবার লিখতে হতো। এগুলো কোনো ফিচার শিপ করেনি—তবু দিনের মতো সময় ব্যয় করতো।

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

আইডিয়া: কম সিদ্ধান্ত, বেশি অগ্রগতি

রেইলস একটি সহজ প্রতিশ্রুতি জনপ্রিয় করেছিল: আপনি সাধারণভাবে কাজ করার ধরন অনুসরণ করলে, আপনাকে সবকিছু কনফিগার করতে হবে না। সাধারণ ভাষায় এটাই “কনভেনশন ওভার কনফিগারেশন।”

কোনও সেটিং প্রতিটি ক্ষেত্রে আপনাকে নির্দিষ্ট করার পরিবর্তে, রেইলস বোধগম্য ডিফল্ট ধরে নেয়:

• মডেল, ভিউ এবং কন্ট্রোলারের জন্য প্রত্যাশিত অবস্থান
• টেবিলের সাথে কোডকে অটোমেটিকভাবে সংযুক্ত করার স্ট্যান্ডার্ড নামকরণ
• সাধারণ URL প্যাটার্ন যা ম্যানুয়াল ওয়্যারিং কম করে

যখন ফ্রেমওয়ার্ক ইতিমধ্যেই “আপনি কী বোঝাতে চাইছেন” সেটা জানে, আপনি কম বয়লারপ্লেট লিখেন এবং দ্রুত কাজ করা স্ক্রিনের দিকে যেতে পারেন।

বাস্তবে কেন তা দ্রুত লাগত

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

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

এই নিবন্ধটি সেই ব্যবহারিক প্রভাবের উপর ফোকাস করে—কিভাবে রেইলস কনভেনশন আইডিয়া থেকে চলমান ফিচারে যাওয়ার পথ ছোট করে—বিরাট ভক্তি তৈরি না করেই। মূল কথা হল কোনো একজন ব্যক্তি বা কোনো এক ফ্রেমওয়ার্ক যেন ‘ম্যাজিক’ নয়; ভালো ডিফল্টগুলো প্রোডাক্ট তৈরির ঘর্ষণ কমায়।

DHH এবং Ruby on Rails-এর উত্স

David Heinemeier Hansson—সাধারণত DHH নামে পরিচিত—রুবি অন রেইলসের স্রষ্টা। তিনি Rails তৈরি করেছিলেন 37signals (এখন Basecamp) এ কাজ করার সময় এবং 2004 সালে এটাকে ওপেন সোর্সে প্রকাশ করেন। এই টাইমলাইন গুরুত্বপূর্ণ কারণ রেইলস কোনো শূন্যস্থানে ডিজাইন হয়নি: এটি বাস্তব প্রোডাক্ট শিপিংয়ের দৈনন্দিন চাপে গঠিত ছিল।

একটি বাস্তব অ্যাপ থেকে আলাদা করা, কাগজে নয়

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

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

“অপিনিয়নেটেড ফ্রেমওয়ার্ক” বলতে আসলে কী বোঝায়

রেইলসকে প্রায়ই “অপিনিয়নেটেড” বলা হয়। সাধারণ ভাষায় এর মানে হল রেইলস আপনার জন্য সিদ্ধান্ত নেয়—বিশেষত স্ট্রাকচার আর ডিফল্ট নিয়ে—তাই আপনাকে সবকিছু নির্ধারণ করতে হয় না।

উদাহরণস্বরূপ, এটি দলগুলোকে এগুলোর প্রতি উৎসাহ দেয়:

• স্ট্যান্ডার্ড ফোল্ডার লেআউট ও নামকরণ
• ডাটা ও সম্পর্ক মডেল করার একটি সঙ্গতিপূর্ণ উপায়
• কন্ট্রোলার, ভিউ এবং রাউটসের জন্য প্রত্যাশিত প্যাটার্ন

এই মতামতগুলো আপনার আগে নিতে হবে এমন সিদ্ধান্তের সংখ্যা কমায়—এর ফলে সাধারণত দ্রুত প্রথম ভার্সন এবং দ্রুত ইটারেশন হয়।

কমিউনিটি ইফেক্ট: শেয়ার করা ডিফল্ট, শেয়ার করা শব্দভাণ্ডার

রেইলস কেবল কোড দেনি; এটি ওয়েব অ্যাপ সম্পর্কে একটি শেয়ার করা উপায়ও তৈরি করেছিল। যখন হাজার হাজার দল একই কনভেনশন অনুসরণ করে, আপনি পেয়ে যান একটি সাধারণ শব্দভাণ্ডার (“models”, “migrations”, “scaffolds”, “RESTful routes”) এবং ট্রান্সফারযোগ্য স্কিল। এতে অনবোর্ডিং সময় কমে, সাহায্য খুঁজা সহজ হয়, এবং “আমরা এটা কীভাবে করব?” প্রশ্নটি বদলে যায় “রেইলসে এর জন্য স্ট্যান্ডার্ড আছে।”

কনভেনশন ওভার কনফিগারেশন, সহজভাবে ব্যাখ্যা

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

মূল ধারণা: ডিফল্ট আগে, ব্যতিক্রম পরে

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

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

রেইলস কিভাবে আপনার হয়ে সিদ্ধান্ত নেয়—সহজ উদাহরণ

রেইলস প্রেডিক্টেবল নামকরণ ও স্থানে রাখা ব্যবহার করে অংশগুলোকে অটোমেটিকভাবে সংযুক্ত করে:

• যদি আপনার একটি মডেল থাকে Article, রেইলস আশা করে একটি ডাটাবেজ টেবিল articles নামে থাকবে।
• ArticlesController নামক কন্ট্রোলারটি আর্টিকেলের ইউআরএল ও অ্যাকশনগুলোর সাথে ম্যাপ হবে।
• ফাইলগুলো সাধারণ লোকেশনে থাকবে যেমন app/models/article.rb এবং app/controllers/articles_controller.rb।

কারণ রেইলস জানে কোথায় খুঁজবে এবং কী নামে কল করবে, আপনি বারংবার ওয়্যারিং এড়িয়ে লেখেন ফিচারটি, গ্লু কোড নয়।

ট্রেড-অফ

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

রেইলস MVC এবং প্রত্যাশিত স্ট্রাকচারের শক্তি

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

• Models: অ্যাপের “বিজনেস অবজেক্ট।” এগুলো ডাটা সংরক্ষণ করে (সাধারণত ডাটাবেসের মাধ্যমে) এবং ভ্যালিডেশন, প্রাইসিং লজিক, স্টেট চেঞ্জের মতো নিয়ম রাখে।
• Views: ব্যবহারকারীরা যা দেখে। টেমপ্লেট যা ডাটাকে HTML (বা JSON) তে রূপান্তর করে, উপস্থাপনায় ফোকাস করে সিদ্ধান্ত গ্রহণে নয়।
• Controllers: ট্র্যাফিক ডিরেক্টর। তারা একটি রিকোয়েস্ট গ্রহণ করে, মডেল থেকে যা দরকার তা অনুরোধ করে, এবং কোন ভিউ (বা রেসপন্স) ফিরিয়ে দেবে তা নির্বাচন করে।

রেইলস কীভাবে তা কম সেটআপে সংযোজন করে

গতি বাড়ানোর মূল কারণ হল রেইলস কনভেনশনগুলো এই লেয়ারগুলোকে অটোমেটিকভাবে সংযুক্ত করে। আপনি যদি PostsController তৈরি করেন, রেইলস আশা করে এটা থাকবে app/controllers/posts_controller.rb এ। একটি Post মডেল থাকে app/models/post.rb তে। ওই কন্ট্রোলারের জন্য ভিউগুলো স্বাভাবিকভাবেই app/views/posts/ এ যায়।

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

প্রত্যাশিত স্ট্রাকচার দলগত গতি বাড়ায়

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

“ফ্যাট মডেল, স্কিনি কন্ট্রোলার” (এবং কোথায় এটি ভেঙে যায়)

একটি সাধারণ নির্দেশিকা হল ফ্যাট মডেল, স্কিনি কন্ট্রোলার: কন্ট্রোলারগুলো সরল রাখুন এবং পুনঃব্যবহারযোগ্য নিয়মগুলো মডেলে চাপুন। এটি এন্ডপয়েন্ট জুড়ে কপি-পেস্ট করা লজিক এড়াতে সাহায্য করে।

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

স্ক্যাফোল্ডিং: আইডিয়া থেকে কাজ করা CRUD মিনিটের মধ্যে

রেইলস স্ক্যাফোল্ডিং একটি ফিচারের কাজ করা বেসলাইন দ্রুত তৈরি করার শর্টকাট। এক কমান্ডেই রেইলস একটি মডেল, ডাটাবেস মাইগ্রেশন, কন্ট্রোলার অ্যাকশন, রাউটস, এবং Create/Read/Update/Delete (CRUD) জন্য বেসিক ভিউ জেনারেট করতে পারে। ফলাফলটি স্লাইড ডেক বা মকআপ নয়; এটি ক্লিক করে চালানো যায় এমন অ্যাপের একটি চলমান অংশ।

স্ক্যাফোল্ডিং আসলে কী দেয়

একটি স্ক্যাফোল্ড “বিরক্তিকর কিন্তু প্রয়োজনীয়” অংশগুলোকে ওয়্যার করে যাতে আপনি দ্রুত আইডিয়া প্রমাণ করতে পারেন:

• আপনার নির্বাচিত ফিল্ড নিয়ে একটি ডাটাবেস-ব্যাকড রিসোর্স
• রেকর্ড তৈরি ও সম্পাদনার জন্য ফর্ম
• রেকর্ড লিস্ট ও ভিউ পেজ
• প্রচলিত রাউটস এবং কন্ট্রোলার অ্যাকশন

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

স্ক্যাফোল্ডগুলো শেখার জন্য, শেষ করার জন্য নয়

স্ক্যাফোল্ডিংকে najle ভালোভাবে দেখা উচিত প্রোটোটাইপ জেনারেটর হিসেবে। ডিফল্ট ভিউগুলো সাধারণ, UX মিনিমাল, এবং কোড জেনেরিক অনুমানগুলো প্রতিফলিত করে। এটি একটি বৈশিষ্ট্য, ত্রুটি নয়: এটি আপনাকে স্ক্যাফোল্ডকে শুরু পয়েন্ট হিসেবে দেখতে উত্সাহ দেয়, না যে “এটাই ডিজাইন।”

একটি সাধারণ স্বাস্থ্যকর ওয়ার্কফ্লো:

1. একটি রিসোর্স স্ক্যাফোল্ড করুন যাতে এন্ড-টু-এন্ড লুপ কাজ করে।
2. কাউকে (ভেতরে হলেও) দেখান ফ্লো ভ্যালিডেট করার জন্য।
3. রিফ্যাক্টর: ভ্যালিডেশন, অনুমতি, UI, এবং বিজনেস রুল সংশোধন করুন।

সতর্কতা: গতি দায়বদ্ধতা মুছে দেয় না

জেনারেটেড কোড এখনও রিভিউ করতেই হবে। আপনাকে টেস্ট যোগ করতে হবে, অনুমতি শক্ত করতে হবে, এবং এরর হ্যান্ডলিং উন্নত করতে হবে। এবং কারণ স্ক্যাফোল্ডেড পেজ ইউটিলিটেরিয়ান, প্রকৃত UX কাজের জন্য সময় প্ল্যান করুন—কপি, লেআউট, অ্যাক্সেসিবিলিটি, এবং এজ কেস। স্ক্যাফোল্ডিং প্রথম ড্রাফট দ্রুত করে; এটা ইঞ্জিনিয়ারিং জাজমেন্টের বিকল্প নয়।

জেনারেটর ও মাইগ্রেশন: ওয়ার্কফ্লোতে ইটারেশন নির্মিত

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

জেনারেটর, মাইগ্রেশন, এবং কনভেনশন এক সিস্টেম হিসেবে

একটি রেইলস জেনারেটর কেবল “ফাইল তৈরি করে” না। এটি প্রত্যাশিত ফাইলগুলো প্রত্যাশিত জায়গায় প্রত্যাশিত নামে তৈরি করে—মডেলগুলো app/models এ, কন্ট্রোলার app/controllers এ, টেস্ট সঠিক ফোল্ডারে, এবং বিশেষভাবে একটি মাইগ্রেশন যা ডাটাবেস স্ট্রাকচার আপডেট করে।

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

মাইগ্রেশনগুলো পরিবর্তনকে পণ্যের অংশ হিসেবে করে তোলে

মাইগ্রেশন ডাটাবেস স্কিমাকে এমন কিছু হিসেবে নিয়ে আসে যা অ্যাপের সাথে সাথে বিবর্তিত হয়। "ডাটাবেস শেষ, এখন কোড" এমন নয়—রেইলস একটি স্থির রিদম উৎসাহ দেয়: ফিচার তৈরি করুন, স্কিমা সামঞ্জস্য করুন, বাস্তব ব্যবহার থেকে শিখুন, তারপর পরিমার্জন করুন।

প্রতিটি মাইগ্রেশন একটি ছোট, টাইমস্ট্যাম্পেড ধাপ যা রিভিউ করা যায়, ভার্সন কন্ট্রোলে ট্র্যাক হয়, এবং পরিবেশ জুড়ে রেপ্লে করা যায়। ফলে ইটারেটিভ প্রোডাক্ট পরিবর্তন—ফিল্ড যোগ করা, কনস্ট্রেইন্ট টুইক করা, নতুন টেবিল আনা—সময়ের সঙ্গে অনেক কম ঝুঁকিপূর্ণ হয়।

উদাহরণ ওয়ার্কফ্লো: একটি ফিল্ড যোগ করুন, ভ্যালিডেট করে শিপ করুন

ধরা যাক আপনি ইউজারদের কাছে role যোগ করতে চান:

1. পরিবর্তন জেনারেট করুন: rails g migration AddRoleToUsers role:string
2. চালান: rails db:migrate
3. মডেল আপডেট করুন: User-এ ভ্যালিডেশন যোগ (এবং সম্ভবত একটি enum)।
4. ফর্ম ও ভিউ ঠিক করুন, টেস্ট আপডেট করুন, ডিপ্লয় করুন।

এটি একটি টাইট লুপ: স্কিমা পরিবর্তন ও অ্যাপ পরিবর্তন একসাথে চলে, তাই আপনি “রহস্যময় কলাম” বা এমন কোড পাবেন না যা ডেটা নেই বলে ধরে নেয়।

শৃঙ্খলা জরুরি

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

ডিফল্টভাবে DRY: কম বয়লারপ্লেট, ফিচারের ওপর বেশি ফোকাস

“নিজেকে বারবার না করো” (DRY) ধারণা সহজ: আপনার অ্যাপের প্রতিটি জ্ঞানের জন্য একটি স্পষ্ট একক উৎস থাকা উচিত। ওয়েব অ্যাপে, পুনরাবৃত্তি প্রায়শই তখন আসে যখন একই ধারণা একাধিক স্থানে স্পষ্ট হয়—রাউটস, কন্ট্রোলার লজিক, ভিউ টেমপ্লেট, এমনকি ডাটাবেস কুয়েরি।

একটি স্পষ্ট DRY উদাহরণ: Posts ফিচার

ধরুন আপনি একটি মৌলিক ব্লগ বানাচ্ছেন Post রেকর্ড নিয়ে। DRY অভ্যাস ছাড়া আপনি একই “আইডি দ্বারা পোস্ট খুঁজুন” কোডটি show, edit, update, এবং destroy-এ কপি করতে পারেন। রেইলস আপনাকে একটি শেয়ার করা মেথডের দিকে ধাক্কা দেয়:

before_action :set_post, only: %i[show edit update destroy]

def set_post
  @post = Post.find(params[:id])
end

এটিই DRY: একবার পরিবর্তন (যেমন Post.friendly.find-এ স্যুইচ করা) করলে প্রতিটি অ্যাকশন আপডেট হয়।

কনভেনশন কিভাবে রাউটস, কন্ট্রোলার, এবং ভিউ জুড়ে ডুপ্লিকেশন কমায়

রেইলস কনভেনশনগুলো ডুপ্লিকেশন কমানো সহজ করে কারণ বিভিন্ন লেয়ারগুলোর নামকরণ ও স্ট্রাকচার “মেলায়।” আপনি যখন RESTful রাউটস (resources :posts) ব্যবহার করেন, রেইলস PostsController-কে স্ট্যান্ডার্ড অ্যাকশন প্রত্যাশা করে, এবং ভিউগুলো predictable পাথে যেমন app/views/posts/show.html.erb-এ থাকে।

এই অংশগুলো মিললে আপনি গ্লু কোড কম লিখেন। একটি লিংক হেল্পার যেমন link_to @post.title, @post কাজ করে কারণ রেইলস মডেল ইনস্ট্যান্স থেকে সঠিক রুট অনুমান করতে পারে। পারশিয়াল নামকরণ (render @posts) প্রত্যেক আইটেমের জন্য অটোমেটিকভাবে posts/_post বেছে নিতে পারে।

DRYতিরও অতিরিক্ততা ক্ষতিকর হতে পারে

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

সুখী পথ: কেন ডিফল্টগুলো পণ্যের ইটারেশন ত্বরান্বিত করে

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

সহজ কথায় হ্যাপি-পাথ ডেভেলপমেন্ট

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

সিদ্ধান্তের ক্লান্তি কমানো এমন ডিফল্টগুলো

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

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

দ্রুত পরীক্ষা, ঘন ফিডব্যাক লুপ

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

• একটি নতুন ধারণা মডেল করা এবং দ্রুত অ্যাপে যুক্ত করা
• অতিরিক্ত প্লাম্বিং ছাড়া ভ্যালিডেশন ও এরর মেসেজ যোগ করা
• এমন এন্ডপয়েন্ট ও পেজ তৈরি করা যা অ্যাপের বাকি অংশের সাথে সঙ্গতিপূর্ণ

সংক্ষিপ্ত নির্মাণ সময়ই সংক্ষিপ্ত ফিডব্যাক লুপে পরিণত হয়—এবং সেখানেই গতি শেখায়।

যখন হ্যাপি-পাথ ভাঙে

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

দলগত গতি: শেয়ার করা কনভেনশন সমন্বয় খরচ কমায়

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

দিন-প্রতি-দিনে “রেইলস উপায়” কেমন লাগে

কনভেনশনগুলো ঘন ঘন ছোট, পুনরাবৃত্ত সিদ্ধান্তে দেখা যায়:

• app/models এ মডেল, app/controllers এ কন্ট্রোলার, app/views এ ভিউ
• প্রত্যাশিত নামকরণ (PostsController Post পরিচালনা করে)
• সাধারণ RESTful রাউটস (index, show, create, ইত্যাদি)
• ফর্ম, ভ্যালিডেশন, এবং পারশিয়াল নিয়ে পরিচিত পদ্ধতি

এগুলোর কোনো একটিই একা জাদু নয়। একসঙ্গে তারা “এখানে আমরা কীভাবে কাজ করি?” কথাগুলো কমায়।

দ্রুত অনবোর্ডিং এবং কম হ্যান্ডঅফ

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

ভালো কোড রিভিউ, কম বাইকশেডিং

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

ট্রেড-অফ: সমরূপতা সবসময় সঠিক নয়

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

ব্যাটারি ইনক্লুডেড: ইন্টিগ্রেটেড টুলস যা প্রোডাক্ট দ্রুত শিপ করে

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

সাধারণ চাহিদার জন্য স্ট্যান্ডার্ড সমাধান

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

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

কম সিম এবং কম গ্লু কোড

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

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

ট্রেড-অফ: ফ্রেমওয়ার্ক-ব্যাপী পরিবর্তন

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

কোথায় কনভেনশন ওভার কনফিগারেশন ক্ষতি করতে পারে

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

আপনি কনভেনশনের বিরুদ্ধে লড়াই করছেন—চিহ্নগুলো

কয়েকটি ব্যবহারিক “ধোঁয়া-সংকেত” সাধারণত দ্রুত উঠে আসে:

• আপনি ধারাবাহিকভাবে ডিফল্ট ওভাররাইড করে যাচ্ছেন (autoloading, inflections, routing প্যাটার্ন) শুধু যাতে জিনিসগুলো “ঠিক” লাগে।
• আপনি কাস্টম ডিরেক্টরি নিয়ম এনেছেন যা নতুন সহকর্মীরা মানচিত্র ছাড়া অনুমান করতে পারে না।
• ভারী মেটাপ্রোগ্রামিং মূল আচরণ ট্রেস করা কঠিন করে দেয় ("এই মেথড কোথায় ডিফাইন করা হয়েছে?" প্রতিদিনের প্রশ্ন হয়ে যায়)।
• মৌলিক কাজগুলো প্রকল্প-নির্দিষ্ট রীতিনীতি মনে রেখে সম্পন্ন করতে হয়, স্ট্যান্ডার্ড রেইলস প্যাটার্ন নয়।

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

কর্মক্ষমতা ও স্কেলিং: প্রকৃত ট্রেড-অফ

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

কনভেনশন ক্ষতি করতে পারে যখন আপনি ডিফল্টগুলোকে “সবসময় অপ্টিমাল” ধরে নেন। উদাহরণস্বরূপ, নিষ্প্রভ Active Record ব্যবহার N+1 কুয়েরি তৈরি করতে পারে, এবং ডিফল্ট ক্যাশিং সিদ্ধান্তগুলা আপনার হটএন্ডপয়েন্টের জন্য অনেকটাই জেনেরিক হতে পারে। স্কেলিং সাধারণত মাপা, তারপর ইচ্ছাকৃতভাবে সমন্বয় করার বিষয়।

দ্রুত ইটারেশন মানে "কোন টেকনিক্যাল ডেব্ট নেই" নয়

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

কিভাবে কাস্টমাইজ করবেন সুচিন্তিতভাবে

ইচ্ছাকৃতভাবে কাস্টমাইজ করুন:

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

লক্ষ্য হল এমন নমনীয়তা অর্জন করা যা কনভেনশনের সুবিধাগুলো নষ্ট না করে—অর্থাৎ "প্রতিটি জায়গায় কনফিগারেশন" বানিয়ে না ফেলার চেষ্টা।

আধুনিক সমান্তরাল: কনভেনশন বনাম “ভাইব-কোডিং” ডিফল্ট

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

রেইলস যে ফলাফলটি অপ্টিমাইজ করেছিল—আইডিয়া থেকে চলমান ফিচারের ছোট পথ—ওই একই ফলাফল Koder.ai-এর মতো প্ল্যাটফর্মগুলোও লক্ষ্য করে। সেখানে আপনি কথা বলে বলেই (চ্যাটে) প্ল্যাটফর্মকে বললে এটি একটি বাস্তব অ্যাপ জেনারেট করে, আপনি তারপর রেইলসের স্ক্যাফোল্ডের পরের ধাপে যেভাবে ফাইন-টিউন করবেন (আচরণ, অনুমতি, UX সামঞ্জস্য), ঠিক তেমনই আপনিও ইন্টারেক্টিভভাবে পরিমার্জন করতে পারবেন।

মূল পাঠটি এক রকম: দলগুলো দ্রুত চলে যখন প্রাথমিক, পুনরাবৃত্ত সিদ্ধান্তগুলো একবারই নির্ধারিত হয় (ফ্রেমওয়ার্ক বা প্ল্যাটফর্ম দ্বারা) এবং সবাই সেই ডিফল্টগুলোর ওপর গড়ে তোলে।

রেইলস দিয়ে নির্মাণ ও ইটারেট করার জন্য ব্যবহারিক নির্দেশ

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

কনভেনশন ভালভাবে ব্যবহার করার নিয়ম-কাঠামো

শুরুতেই রেইলসের “প্রত্যাশিত” অপশনগুলোতে ভর করে: প্রচলিত নামকরণ, স্ট্যান্ডার্ড ফোল্ডার স্ট্রাকচার, RESTful রাউটস, এবং ফর্ম, ভ্যালিডেশন, ব্যাকগ্রাউন্ড জব হ্যান্ডলিং-এর বিল্ট-ইন উপায়।

একটি সহজ অভ্যাস হিসেবে জিজ্ঞাসা করুন: “একজন নতুন সহকর্মী কি পূর্বাভাস দিতে পারবে এই কোড কোথায় আছে এবং কিভাবে আচরণ করে?” যদি উত্তর হ্যাঁ হয়, আপনি সম্ভবত কনভেনশনের কাছাকাছি আছেন—এবং ভবিষ্যতের পরিবর্তন সস্তা হবে।

একটি লাইটওয়েট সিদ্ধান্ত কাঠামো

যখনই একটি মাপযোগ্য দরকার না থাকে, কনভেনশন অনুসরণ করুন। “মাপযোগ্য” হতে পারে:

• একটি পুনরাবৃত্ত পারফরম্যান্স বটলনেক যা আপনি পুনর্নিমাণ করতে পারেন
• একটি পুনরাবৃত্ত ডেভেলপারস্মস (যা বাগ সৃষ্টি করে বা রিভিউ ধীর করে)
• একটি পরিষ্কার পণ্য প্রয়োজন যা রেইলস ডিফল্ট আকারে সঠিকভাবে প্রকাশ করতে পারে না

আপনি যদি এগুলোর কোনোটি নির্দেশ করতে না পারেন, রেইলস পদ্ধতি বেছে নিন। এটি সিস্টেমটিকে বোঝার যোগ্য রাখে এবং ইটারেশনকে মসৃণ করে।

ব্যতিক্রমগুলো ছোট রাখুন ও লিখে রাখুন

প্রতিটি দল শেষপর্যন্ত কয়েকটি ইচ্ছাকৃত বিচ্যতি করবে—কাস্টম সার্ভিস অবজেক্ট, বিকল্প ফর্ম প্যাটার্ন, নির্দিষ্ট রাউটিং কনভেনশন, বা কুয়েরির মানদণ্ড।

এগুলো একটি সংক্ষিপ্ত “টিম প্লেবুক” এ ধারণ করুন (রেপোতে এক পেজ):

• বিচ্যতি কী
• কখন এটি ব্যবহার করবেন (এবং কখন নয়)
• আপনার কোডবেসের একটি স্পষ্ট উদাহরণ

এটি এক্সসেপশন ক্রিপ প্রতিরোধ করে এবং নতুন হায়ারদের আত্মবিশ্বাসের সাথে শিপ করতে সাহায্য করে।

মূল শিক্ষা

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