سلام، ساتھیوں. آج ہم اس قسم کی تیاری کے کام کے بارے میں بات کرنے جا رہے ہیں جو آپ کو جنگلی طریقے سے کوڈنگ شروع کرنے سے پہلے کرنے کی ضرورت ہے۔ مزید خاص طور پر، ایک ایپلیکیشن فن تعمیر کی منصوبہ بندی اور تخلیق کے بارے میں۔ لیکن کہاں سے شروع کریں؟ اس فن تعمیر کو کیسے بنایا جائے؟ جیسا کہ ہر چیز کے ساتھ، آپ کو شروع سے شروع کرنے کی ضرورت ہے. یعنی - IDEA کے ساتھ۔ ہمارے پروجیکٹ کا خیال بنیادی فعالیت کے ساتھ ایک مفید ٹیلیگرام بوٹ بنانا تھا۔ آئیے بالکل وہی بات دہرائیں: "میں، ایک صارف کے طور پر، جاوا رش پر ان گروپس میں نئے مضامین شائع ہونے پر اطلاعات موصول کرنا چاہتا ہوں جو میری دلچسپی رکھتے ہیں۔" یگنی کے اصول پر عمل کرتے ہوئے، ہم اپنی درخواست تیار کریں گے۔ اس کا مطلب ہے کہ ہم صرف وہی لیں گے جس کی ہمیں ضرورت ہے۔ ہم پہلے سے اور ریزرو میں فعالیت پیدا نہیں کریں گے کیونکہ ہم چاہتے ہیں اور کسی دن یہ حقیقت میں کام آسکتا ہے۔ ہاں، ہم ایک پڑھنے کے قابل اور قابل توسیع ایپلی کیشن بنائیں گے، لیکن اس کا مطلب یہ نہیں ہے کہ ہم "ترقی کے لیے" ڈیٹا بیس اسکیما بنائیں گے۔ اس "ترقی" کی حمایت نہ کرنے کے لیے، میں نے فیصلہ کیا کہ اسے مکمل طور پر ترک کر دینا بہتر ہوگا۔ اس سے ہمیں ترقی اور غیر ضروری جانچ کے دوران غیر ضروری مدد سے بچنے میں مدد ملے گی۔ بعد میں، جب ہمارا پراجیکٹ پروڈکشن میں چلا جائے گا (دوبارہ انگلیسیزم، مخفف پروڈ - پروڈکشن سے)، ہم کچھ اور کرنے کے قابل ہو جائیں گے۔ ایک بار جب آپ کسی آئیڈیا پر فیصلہ کر لیتے ہیں، تو آپ کو تھوڑا شرارتی ہو کر ڈرا کرنے کی ضرورت ہوتی ہے۔ کیا کھینچنا ہے؟ ہمیں مختلف صارفین کے گروپس کی سبسکرپشنز پر ڈیٹا محفوظ کرنے کی صلاحیت کی ضرورت ہوگی۔ میں جانتا ہوں کہ آپ ٹیلی گرام میں یوزر آئی ڈی کو چیٹ آئی ڈی کی شکل میں استعمال کر سکتے ہیں۔ اور اس بات کا اندازہ ہے کہ نئے مضامین کی تلاش دراصل کس طرح آگے بڑھے گی: ہم ان تمام گروپس میں تلاش کریں گے جن کے پاس نئے مضامین کی سبسکرپشنز ہیں اور انہیں چیٹس پر بھیجیں گے۔ اس کی بنیاد پر، ہمیں پہلے تخمینہ کے طور پر درج ذیل ملتا ہے (یہاں زیور کے بغیر ترقی ہے): مجھے امید نہیں ہے کہ آپ میری لکھاوٹ کو سمجھیں گے: میں بالکل یہ دکھانا چاہتا ہوں کہ ترقی کیسے اور کہاں سے شروع ہوتی ہے۔ پہلا مرحلہ مکمل ہو چکا ہے: ہم نے کسی نہ کسی طرح فیصلہ کر لیا ہے کہ کیا ہوگا۔ ڈیٹا بیس میں ماڈل/ٹیبل اوپر بیان کیے گئے ہیں۔ لیکن یہ ایک مسودہ ہے: اسے پالش کیا جا سکتا ہے اور اسے مزید پڑھنے کے قابل شکل میں لایا جا سکتا ہے۔ جب میں پالش کر رہا تھا، مجھے یاد آیا کہ میں بوٹ کے کام کے اعدادوشمار بھی حاصل کرنا چاہتا تھا۔ یہ شامل کیا. اس ڈرائنگ میں یہ واضح ہے کہ اسے کیا اور کیسے ترتیب دیا جائے گا۔ یعنی ان میں کون سی ٹیبلز اور فیلڈز ہوں گی، ٹیبلز کے لیے کون سے ہستی کے نام ہوں گے۔ فیصلہ کیا گیا کہ ان میں سے کئی ہوں گے:
صارف - ٹیلیگرام صارف کے بارے میں معلومات جو ہمارے بوٹ کو استعمال کرے گا۔ جیسا کہ آپ دیکھ سکتے ہیں، ہم صرف چیٹ ID اور پرچم کو محفوظ کرتے ہیں چاہے صارف فعال ہو یا نہیں۔ کیوں؟ کیونکہ ہمارا مقصد صارفین کے بارے میں معلومات اکٹھا کرنا نہیں بلکہ ان کو فائدہ پہنچانا ہے۔
GroupSub - یہاں اس گروپ کے بارے میں معلومات ہوگی جس میں آپ کی رکنیت ہے اور تازہ ترین مضمون جو سبسکرائبرز کو بھیجا گیا تھا۔
اعداد و شمار - میں نے اس کے لیے کوئی اسکیما نہیں بنایا ہے - ہم اسے بعد میں کریں گے۔ یہ پروجیکٹ کے MVP میں بنیادی مقصد نہیں ہے۔
اس کے بعد، میں نئے مضامین کی تلاش کا طریقہ مزید تفصیل سے دکھانا چاہتا تھا۔ ایسا کرنے کے لیے، میں نے ایک BPMN ڈایاگرام استعمال کیا، جسے میں نے تصویر میں تبدیل کیا اور یہ حاصل کیا: یہاں سب کچھ زیادہ پڑھنے کے قابل اور قابل فہم ہے۔ ہم تلاش میں اس اسکیم کے مطابق کام کریں گے۔ مینیجرز کو واقعی یہ اسکیم پسند ہے، کیونکہ یہ نہ صرف پروگرامرز کے لیے قابل فہم ہے :D عام طور پر، ایک شروعات کی گئی ہے۔
کام کے لیے ایک ذخیرہ بنائیں
آخر میں، آپ ٹیلیگرام بوٹ کے ساتھ کام کرنے کے لیے ایک ذخیرہ بنا سکتے ہیں۔
ہم ان اشیاء کو بھرتے ہیں جو ہمارے لئے پہلے سے واقف ہیں - ذخیرہ کا نام، اس کی مختصر تفصیل۔
ایک لائسنس شامل کریں - Apache 2.0 (آپ اپنی صوابدید پر لائسنس کا انتخاب کر سکتے ہیں)۔
پروجیکٹ کے ساتھ کام کرنے کے لیے، گٹ ہب ٹولز، جیسے پروجیکٹ کا استعمال کرنا اچھا ہوگا۔ یہ کیا ہے؟ یہ وہ جگہ ہے جہاں آپ ٹاسک بنا سکتے ہیں، ان کی تکمیل کو ٹریک کر سکتے ہیں اور ٹاسک اسٹیٹس کو محفوظ کر سکتے ہیں۔ اس بات کا تعین کریں کہ کون ان کو انجام دے گا اور مزید۔ ایسا کرنے کے لیے، بنائے گئے پروجیکٹ میں ہمیں پروجیکٹس بٹن ملے گا ، اور وہاں ہم ایک نیا بنائیں گے: جیسا کہ آپ دیکھ سکتے ہیں، یہاں میں نے پروجیکٹ کے نام کی نشاندہی کی، اسے بیان کیا اور اس ٹیمپلیٹ کو منتخب کیا جس پر ہم کام کریں گے۔ خودکار کنبان۔ ہمارے لیے اب یہ اتنا اہم نہیں ہے کہ اس کا کیا مطلب ہے۔ اہم بات یہ ہے کہ ہمارے پاس ٹاسک کے ساتھ ایک بورڈ ہوگا، جسے کالموں میں تقسیم کیا جائے گا، جہاں ہر کالم ٹاسک کی حیثیت رکھتا ہے:
کرنے کے لئے - تمام کام جو کرنے کا منصوبہ بنایا گیا ہے؛
جاری ہے - وہ کام جن پر فی الحال کام کیا جا رہا ہے۔
ہو گیا - وہ کام جو اس پروجیکٹ کے اندر پہلے ہی مکمل ہو چکے ہیں۔
اس طرح ہم اپنے کاموں کی حیثیت کے بارے میں جان سکیں گے۔ کون سے کام جاری ہیں، کون سے کام ہو چکے ہیں۔ مزید یہ کہ، یہ نہ صرف ان صورتوں میں اہم اور آسان ہے جہاں ٹیم موجود ہے، بلکہ جب آپ خود کام کرتے ہیں۔ بورڈ پر کچھ ظاہر ہونے کے لیے، آپ کو ایشوز بنانے کی ضرورت ہے۔
ہم پروجیکٹ کے لیے ایشوز (مسائل) لکھتے ہیں۔
یہ سمجھنے کے لیے کہ کن کاموں کو لکھنا ہے، آئیے فیصلہ کریں کہ پروجیکٹ میں ہمارے پاس کیا ہوگا۔ ہمیں ایک ایسی ایپلیکیشن کی ضرورت ہے جو آسانی سے اور تیزی سے لانچ کی جا سکے، تاکہ ہم ڈیٹا بیس تک رسائی حاصل کر سکیں، تاکہ ہم ڈیٹا بیس کے اسکیما کو منظم اور تبدیل کر سکیں، تاکہ ہم مضامین پر ڈیٹا حاصل کرنے کے لیے JavaRush میں REST درخواستیں کر سکیں۔ اس کی بنیاد پر، آپ درج ذیل ٹیکنالوجیز کا انتخاب کر سکتے ہیں:
اسپرنگ بوٹ - ہماری درخواست کے فریم ورک کے طور پر،
بہار کا ڈیٹا - ڈیٹا بیس کے ساتھ کام کرنے کے لیے،
فلائی وے - ڈیٹا بیس کی منتقلی کے ساتھ کام کرنے کے لیے،
MySQL - پروجیکٹ کے ڈیٹا بیس کے طور پر،
ٹیلیگرام بوٹ سٹرنگ بوٹ اسٹارٹر - ٹیلیگرام بوٹ کے ساتھ کام کرنے کے لیے ایک لائبریری،
Unirest REST درخواستوں کے ساتھ کام کرنے کے لیے ایک لائبریری ہے۔
مندرجہ بالا سب سے، آئیے کام بنانا شروع کرتے ہیں۔
ٹاسک تخلیق ٹیمپلیٹ
ہم درج ذیل ٹیمپلیٹ کا استعمال کرتے ہوئے کام بنائیں گے۔
کام کا نام اس طرح نظر آئے گا: JRTB-{IssueNumber}:{IssueDescription} ، جہاں:
{IssueNumber} مسئلہ کا سیریل نمبر ہے۔ آئیے اسے آخری مسئلہ سے ایک اور لیتے ہیں۔
{IssueDescription} - مسئلے کی ایک مختصر وضاحت۔
ٹاسک کے باڈی میں ہم اس کی مزید تفصیلی وضاحت کریں گے (کبھی کبھی یہ ٹاسک کے نام میں دی گئی تفصیل کے ساتھ موافق بھی ہو سکتا ہے)۔
قبولیت کا معیار ضروریات کی ایک فہرست ہے، جس کے بعد کام کو مکمل سمجھا جا سکتا ہے۔ تو بات کرنے کے لیے، کام کو قبول کرنے کا معیار۔ ان کا استعمال کرتے ہوئے، ایک جائزہ لینے والا (انگریزی جائزہ لینے والے سے - جائزہ لینے والا - ایک شخص جو یہ دیکھتا ہے کہ کام کیسے مکمل ہوتا ہے) سمجھ سکتا ہے کہ کام مکمل طور پر مکمل ہوا ہے یا نہیں۔
اس ٹیمپلیٹ کو استعمال کرتے ہوئے، ہم اپنا پہلا ٹاسک بنائیں گے: یہ بات بھی قابل غور ہے کہ اسے بناتے وقت، میں نے فوراً طے کیا کہ یہ ٹاسک کس پروجیکٹ کے لیے موزوں ہے، کون اسے انجام دے گا (اسائنی) اور یہ کام کس لیبل (لیبل) سے تعلق رکھتا ہے۔ اس کے بعد، میں صرف ایک چھوٹی سی تفصیل اور ان کے لنکس کے ساتھ کاموں کے نام دکھاؤں گا۔ وہ سب یہاں ہیں ۔ ہم کاموں کو تقریباً اسی ترتیب میں انجام دیں گے جیسا کہ یہاں اشارہ کیا گیا ہے:
یہ پہلے سے ہی پروجیکٹ کے آغاز کی طرح لگتا ہے۔ تو بات کرنے کے لئے، ہم نے ایک پروجیکٹ آرکیٹیکٹ اور کاروباری تجزیہ کار کے طور پر کام کیا.
ذخیرہ کو بھرنا
کوڈنگ شروع کرنے سے پہلے اور کیا کرنے کی ضرورت ہے؟ - مصنف، آپ ان میں سے کتنے پیراگراف شامل کر سکتے ہیں، کیا آپ انہیں پاتال سے نکال رہے ہیں؟ - نہیں، کام کا معیار تفصیلات میں دکھایا گیا ہے۔ اور وہی ہیں جو معنی رکھتے ہیں۔ تو آئیے ایک اور تفصیل شامل کرتے ہیں۔ دوسرے ڈویلپرز کے لیے پراجیکٹ کو مقبول اور قابل فہم بننے کے لیے، اسے پُر کرنے کی ضرورت ہے۔ مجھے کیا شامل کرنا چاہئے؟ میں نے مضمون میں کیا کیا جا سکتا ہے اس کی مکمل فہرست بیان کی ہے GitHub پر آپ کے پروجیکٹس کے ساتھ کام کو بہتر بنانا: Github Template Repository کو جاننا ۔ میں اسے پڑھنے کی انتہائی سفارش کرتا ہوں۔ ہمارے لیے یہ ضروری ہے کہ ہم کیا کر رہے ہیں، اس کی واضح تفہیم کا واضح ورژن ہونا۔ لہذا، میں نے ایک RELEASE_NOTES فائل شامل کی ہے جس میں ہمارے پروجیکٹ میں تبدیلیاں ریکارڈ کی جائیں گی۔ مثال کے طور پر، آپ میرے پروجیکٹ سے RELEASE_NOTES کو دیکھ سکتے ہیں (ہاں، کیوں نہ دکھائیں کہ میں اپنی توانائی اور تخلیقی صلاحیتوں کو کس چیز میں ڈالتا ہوں)۔ ہر نئے ورژن کی تبدیلیاں وہاں بیان کی گئی ہیں۔ میں نے نئے کام بنانے کے لیے ٹیمپلیٹس بھی شامل کیے ہیں، جن میں 4 اختیارات ہیں:
بگ رپورٹ ایک ایسا کام ہے جسے ان صارفین/ٹیسٹرز نے تخلیق کیا ہے جو اپنے کام میں بگ ڈھونڈتے ہیں۔ یہ ایک بہت اہم چیز ہے: یہ بگ فکسس کا انتظام کرنے میں مدد کرتا ہے۔
خصوصیت کی درخواست نئی فعالیت کو شامل کرنے کا کام ہے۔ پروجیکٹ کے تمام پہلے کام فیچر کی درخواست کے کام ہیں۔
بہتری کی درخواست - درخواست کے عمل کو بہتر بنانے کا کام۔ مثال کے طور پر، بوٹ کے ساتھ کام کرتے وقت ٹیسٹ کے جوابات کو تبدیل کرنا۔ میں تکنیکی مصنف نہیں ہوں اور میں مکمل طور پر درست جوابات نہیں دے سکتا ہوں۔ اس لیے اگر آپ میں خواہش اور قابلیت ہے تو پیش کریں :)
سوال ڈویلپرز کے لیے ایپلی کیشن کے آپریشن کے بارے میں ایک سوال ہے۔ ایک بہت مفید چیز۔ فرض کریں کہ کام کی کوئی سمجھ نہیں ہے یا کسی سوال کے بارے میں شکوک و شبہات ہیں - آپ اس طرح سوال پوچھ سکتے ہیں اور پہلے ہاتھ سے جواب حاصل کر سکتے ہیں۔
اگر آپ GitHub کو دیکھیں تو یہ بالکل اس طرح نظر آئے گا: ہمارے پاس فی الحال جاوا رش API کے ساتھ گروپس کے ساتھ کام کرنے کے لیے ایک دستاویز موجود ہے۔
اس کے بعد کیا ہے؟
خیر ہم یہ تمام مراحل مکمل کر لیں اور کیا، پراجیکٹ بند ہو جائے گا؟ کوئی بالکل نہیں. یہ منصوبہ چلتا رہے گا۔ یہ میرے اور ان تمام JavaRush طلباء/گریجویٹس کے ذریعہ تیار کیا جائے گا جو حصہ لینا چاہتے ہیں۔ مستقبل کے لیے آپ کے کیا منصوبے ہیں؟ ان کی ایک بہت. پہلا منصوبہ JavaRush API کے لیے جاوا کلائنٹ بنانا ہے۔ ڈویلپرز نے وعدہ کیا کہ وہ اپنی سویگر کو کھلی رسائی فراہم کریں گے۔ ہم یہ بھی دیکھیں گے کہ اکڑ کیا ہے؟ ٹھنڈی اور بہت مفید چیز۔ اگلا ہم جاوا رش سائٹ کو ٹیلیگرام بوٹ کے ساتھ مربوط کریں گے۔ آئیے سبسکرپشنز کو سنکرونائز کرنے کے لیے صارف کو بوٹ سے جوڑتے ہیں۔ آئیے کورس کی تکمیل کے اعدادوشمار بناتے ہیں۔ اور ہر وہ چیز جو آپ JavaRush کمیونٹی کے طور پر چاہتے ہیں۔
نتائج
آج ہم نے اس منصوبے کی تخلیق سے پہلے پردے کے پیچھے کام کرنے کے بارے میں بات کی۔ یا زیادہ واضح طور پر، ایک کام کی منصوبہ بندی کے بارے میں، جس کے بغیر آپ بہت زیادہ توانائی ضائع کر سکتے ہیں. میں دہراتا ہوں، پروجیکٹ کا آغاز پہلے ہی یہاں عوامی طور پر دستیاب کر دیا گیا ہے ۔ ہمیشہ کی طرح، میں تجویز کرتا ہوں کہ آپ Github پر میرے اکاؤنٹ کو سبسکرائب کریں۔ اس طرح آپ مضمون کے شائع ہونے سے پہلے پروجیکٹ میں تبدیلیاں حاصل کر سکتے ہیں۔ میں پہلے ہی فرض کر لیتا ہوں کہ تمام دلچسپی رکھنے والی جماعتیں گیتوب پر رجسٹر ہو چکی ہیں۔ ہاں، پراجیکٹ اتنی تیزی سے آگے نہیں بڑھ رہا ہے جتنا ہم چاہتے ہیں۔ تاہم، کام پر حقیقی منصوبوں کی طرح. اگلے مضمون میں میں پہلے کاموں کو شامل کرنے کی وضاحت کروں گا۔ پڑھنے کے لئے سب کا شکریہ اور جلد ہی ملیں گے!
مجھے امید نہیں ہے کہ آپ میری لکھاوٹ کو سمجھیں گے: میں بالکل یہ دکھانا چاہتا ہوں کہ ترقی کیسے اور کہاں سے شروع ہوتی ہے۔ پہلا مرحلہ مکمل ہو چکا ہے: ہم نے کسی نہ کسی طرح فیصلہ کر لیا ہے کہ کیا ہوگا۔ ڈیٹا بیس میں ماڈل/ٹیبل اوپر بیان کیے گئے ہیں۔ لیکن یہ ایک مسودہ ہے: اسے پالش کیا جا سکتا ہے اور اسے مزید پڑھنے کے قابل شکل میں لایا جا سکتا ہے۔ جب میں پالش کر رہا تھا، مجھے یاد آیا کہ میں بوٹ کے کام کے اعدادوشمار بھی حاصل کرنا چاہتا تھا۔ یہ شامل کیا. اس ڈرائنگ میں یہ واضح ہے کہ اسے کیا اور کیسے ترتیب دیا جائے گا۔ یعنی ان میں کون سی ٹیبلز اور فیلڈز ہوں گی، ٹیبلز کے لیے کون سے ہستی کے نام ہوں گے۔ فیصلہ کیا گیا کہ ان میں سے کئی ہوں گے:
اس کے بعد، میں نئے مضامین کی تلاش کا طریقہ مزید تفصیل سے دکھانا چاہتا تھا۔ ایسا کرنے کے لیے، میں نے ایک BPMN ڈایاگرام استعمال کیا، جسے میں نے تصویر میں تبدیل کیا اور یہ حاصل کیا: 
یہاں سب کچھ زیادہ پڑھنے کے قابل اور قابل فہم ہے۔ ہم تلاش میں اس اسکیم کے مطابق کام کریں گے۔ مینیجرز کو واقعی یہ اسکیم پسند ہے، کیونکہ یہ نہ صرف پروگرامرز کے لیے قابل فہم ہے :D عام طور پر، ایک شروعات کی گئی ہے۔
جیسا کہ آپ دیکھ سکتے ہیں، یہاں میں نے پروجیکٹ کے نام کی نشاندہی کی، اسے بیان کیا اور اس ٹیمپلیٹ کو منتخب کیا جس پر ہم کام کریں گے۔ خودکار کنبان۔ ہمارے لیے اب یہ اتنا اہم نہیں ہے کہ اس کا کیا مطلب ہے۔ اہم بات یہ ہے کہ ہمارے پاس ٹاسک کے ساتھ ایک بورڈ ہوگا، جسے کالموں میں تقسیم کیا جائے گا، جہاں ہر کالم ٹاسک کی حیثیت رکھتا ہے:
یہ بات بھی قابل غور ہے کہ اسے بناتے وقت، میں نے فوراً طے کیا کہ یہ ٹاسک کس پروجیکٹ کے لیے موزوں ہے، کون اسے انجام دے گا (اسائنی) اور یہ کام کس لیبل (لیبل) سے تعلق رکھتا ہے۔ اس کے بعد، میں صرف ایک چھوٹی سی تفصیل اور ان کے لنکس کے ساتھ کاموں کے نام دکھاؤں گا۔ وہ سب یہاں ہیں ۔ ہم کاموں کو تقریباً اسی ترتیب میں انجام دیں گے جیسا کہ یہاں اشارہ کیا گیا ہے:
ہمارے پاس فی الحال جاوا رش API کے ساتھ گروپس کے ساتھ کام کرنے کے لیے ایک دستاویز موجود ہے۔
GO TO FULL VERSION