OpenMRS প্রকল্প

এই পৃষ্ঠায় Google সিজন অফ ডক্সের জন্য গৃহীত প্রযুক্তিগত লেখার প্রকল্পের বিশদ বিবরণ রয়েছে৷

প্রকল্পের সারাংশ

ওপেন সোর্স সংস্থা:

OpenMRS

প্রযুক্তিগত লেখক:

সৌরভ

প্রকল্পের নাম:

REST API-এর জন্য ব্যবহারকারী বান্ধব গিটহাব ডকুমেন্টেশন বাড়ানো

প্রকল্পের দৈর্ঘ্য:

স্ট্যান্ডার্ড দৈর্ঘ্য (3 মাস)

প্রকল্পের বিবরণ

প্রাথমিক উদ্দেশ্য

API-এর ব্যবহারের বিষয়ে নির্দেশিকা যোগ করতে OpenMRS Swagger-ভিত্তিক REST API ডকুমেন্টেশন উন্নত করুন।

প্রকল্পের বিবরণ

OpenMRS REST API হল ডেভেলপারদের OpenMRS থেকে ডেটা অ্যাক্সেস করার জন্য একটি মূল প্রক্রিয়া। ইতিমধ্যেই OpenMRS Webservices API-এর একটি Swagger-ভিত্তিক স্বয়ংক্রিয়-উত্পাদিত ডকুমেন্টেশন এবং পাশাপাশি একটি স্ট্যাটিক GitHub ভিত্তিক ডকুমেন্টেশন রয়েছে, আমরা ডক্সের এই সিজনে সেই গিটহাব ভিত্তিক ডকুমেন্টেশনকে প্রসারিত করার কথা।

সংক্ষিপ্ত ওভারভিউ

বার্কের পরামর্শ অনুসারে OpenMRS Talk-এর উপর কিছুটা গবেষণা করার পর, আমি জানতে পেরেছি যে এই প্রকল্পটি 2017 সালে একটি GSOC প্রকল্প হিসাবে আবার শুরু হয়েছিল। Gayan Weerakutti এর সাথে যেখানে মূল উদ্দেশ্য ছিল OpenMRS REST API-এর বিদ্যমান ডকুমেন্টেশন উন্নত করা, এর সোয়াগার স্পেসিফিকেশন উন্নত করা এবং এর সোয়াগার স্পেসিফিকেশন যেভাবে তৈরি হচ্ছে তাতে উন্নতি করা যাতে সোয়াগার ডকুমেন্টেশনের আরও ভাল সংস্করণ তৈরি হয়। প্রকল্পে সম্পাদিত সমস্ত প্রাসঙ্গিক বিবরণ এখানে এই OpenMRS টক পোস্টে সংক্ষিপ্ত করা হয়েছে এবং বেশ কার্যকর ছিল।

তারপরে, 2019 সালে, এই প্রকল্পটি পুনর্গঠন করা হয়েছিল, এবং আমরা এই বিষয়ে বৈচিত্র তৈরি করে Swagger ডকুমেন্টেশন টুইকগুলি থেকে এগিয়েছি। পরিবর্তে, আমরা একটি স্ট্যাটিক GitHub বন্ধুত্বপূর্ণ ডকুমেন্টেশন তৈরি করেছি যা আমরা ডক্সের এই মরসুমে প্রসারিত করতে যাচ্ছি।

তাই বর্তমান প্রকল্প প্রস্তাবের একটি সংক্ষিপ্ত যা আমি বর্ণনা করতে চাই:

1. কিছু জনপ্রিয় ভাষায় উদাহরণ নিয়ে আসছে (বিশেষভাবে জাভা এবং জাভাস্ক্রিপ্ট উল্লেখ করা হয়েছে)।
2. সোয়াগার ""ট্রাই-আউট" বৈশিষ্ট্যের মতো স্লেট ডকুমেন্টেশনের জন্য খেলার মাঠ সমর্থন যোগ করা।
3. এখন পর্যন্ত করা কাজ রিফ্যাক্টরিং এবং উন্নত করা।
4. খুঁজে পাওয়া এবং অনুপস্থিত সম্পদ যোগ.
5. ডক্সের কনসোল বিভাগে একটু বেশি বিবরণ যোগ করা হচ্ছে

বিশদ বিবরণ

1. বিভিন্ন ভাষায় উদাহরণ দিয়ে আসা.

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

1. API-এর উদাহরণ পরীক্ষা করার জন্য খেলার মাঠ সমর্থন যোগ করা হচ্ছে

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

1. এখন পর্যন্ত করা কাজ রিফ্যাক্টরিং এবং উন্নত করা

বর্তমান কার্ল উদাহরণ পরীক্ষা করা হচ্ছে

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

কিছু উদাহরণে অনুপস্থিত API প্রতিক্রিয়া

বর্তমান কার্ল উদাহরণগুলির জন্য কিছু প্রতিক্রিয়া যোগ করা হয়েছে, কিন্তু কিছু কার্ল উদাহরণের প্রতিক্রিয়া নেই৷ আমি মনে করি এমনকি যদি প্রতিক্রিয়াগুলি ভার্বোস না হয় যা সাধারণত রিসোর্স শুদ্ধ করার মতো ক্রিয়াকলাপের ক্ষেত্রে হয়, তবে আমাদের একটি উদাহরণ JSON API প্রতিক্রিয়া থাকা উচিত যদিও আমরা সমস্ত সম্ভাব্য প্রতিক্রিয়া কোড নথিভুক্ত করেছি এবং সেগুলি পাওয়ার কারণ আমি মনে করি এটি তৈরি করবে এপিআই ডকুমেন্টেশন জুড়ে উদাহরণ আরো অভিন্ন !!

বিভিন্ন অপারেশনে কাজের উদাহরণ অনুপস্থিত

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

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

একটি স্পষ্ট শিরোনাম হিসাবে ব্যবহারের ক্ষেত্রে যোগ করা হচ্ছে

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

1. অনুপস্থিত সংস্থানগুলি সন্ধান এবং নথিভুক্ত করা

   বর্তমান প্রজেক্ট স্টেটে এখানে তালিকাভুক্ত সংস্থান রয়েছে, কিন্তু এখানে swagger ডকুমেন্টেশনের সর্বশেষ সংস্করণটি দেখে, আমি এমন অনেক সংস্থান খুঁজে বের করতে পারি যা GitHub ফ্রেন্ডলি API ডক্সের বর্তমান স্যুটে যোগ করা যেতে পারে বর্ণনার সাথে অন্যান্য ডক্স 2019-এর সিজনে সম্পদ। আমি ডক্সে যে বিষয়গুলি যোগ করতে হবে সেগুলি নিয়ে আলোচনা করব এবং উপযুক্তভাবে যোগ করব৷

উপসংহার

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

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