اس موسم بہار میں ہم نے خود کو بہت خوشگوار حالات میں پایا۔ وبائی مرض کی وجہ سے، یہ واضح ہو گیا کہ ہماری سمر کانفرنسوں کو آن لائن منتقل کرنے کی ضرورت ہے۔ اور ان کو آن لائن موثر طریقے سے چلانے کے لیے، تیار سافٹ ویئر حل ہمارے لیے موزوں نہیں تھے؛ ہمیں خود لکھنے کی ضرورت تھی۔ اور یہ کام کرنے کے لیے ہمارے پاس تین مہینے تھے۔
یہ واضح ہے کہ یہ ایک دلچسپ تین ماہ رہا ہے۔ لیکن باہر سے یہ مکمل طور پر واضح نہیں ہے: آن لائن کانفرنس پلیٹ فارم کیا ہے؟ یہ کن حصوں پر مشتمل ہے؟ لہذا، موسم گرما کے آخری ڈیو اوپس کانفرنسوں میں، میں نے ان لوگوں سے پوچھا جو اس کام کے ذمہ دار تھے:
- Nikolay Molchanov - JUG Ru گروپ کے تکنیکی ڈائریکٹر؛
- Vladimir Krasilshchik بیک اینڈ پر کام کرنے والا ایک عملی جاوا پروگرامر ہے (آپ ہماری جاوا کانفرنسوں میں اس کی رپورٹس بھی دیکھ سکتے ہیں)؛
- Artyom Nikonov ہماری تمام ویڈیو سٹریمنگ کے لیے ذمہ دار ہے۔
ویسے، موسم خزاں اور موسم سرما کی کانفرنسوں میں ہم اسی پلیٹ فارم کا ایک بہتر ورژن استعمال کریں گے - بہت سارے ہابرا ریڈرز اب بھی اس کے استعمال کنندہ ہوں گے۔
مجموعی طور پر تصویر
- ٹیم کی ساخت کیا تھی؟
نکولے مولچانوف: ہمارے پاس ایک تجزیہ کار، ایک ڈیزائنر، ایک ٹیسٹر، تین فرنٹ اینڈرز اور ایک بیک اینڈ ہے۔ اور، بلاشبہ، ایک ٹی کے سائز کا ماہر!
- عمل عام طور پر کیسا لگتا تھا؟
نیکولے: مارچ کے وسط تک، ہمارے پاس آن لائن کے لیے بالکل بھی تیار نہیں تھا۔ اور 15 مارچ کو، پورا آن لائن carousel گھومنے لگا۔ ہم نے کئی ذخیرے بنائے، منصوبہ بنایا، بنیادی فن تعمیر پر تبادلہ خیال کیا اور تین ماہ میں سب کچھ کیا۔
بلاشبہ یہ منصوبہ بندی، فن تعمیر، خصوصیت کے انتخاب، ان خصوصیات کے لیے ووٹنگ، ان خصوصیات کے لیے پالیسی، ان کے ڈیزائن، ترقی، جانچ کے کلاسک مراحل سے گزرا۔ نتیجے کے طور پر، 6 جون کو، ہم نے ہر چیز کو پروڈکشن کے لیے تیار کر دیا۔ . ہر چیز کے لیے 90 دن تھے۔
- کیا ہم نے اس کو پورا کرنے کا انتظام کیا جس کا ہم نے وعدہ کیا تھا؟
نیکولے: چونکہ اب ہم آن لائن DevOops کانفرنس میں شرکت کر رہے ہیں، اس کا مطلب ہے کہ اس نے کام کیا۔ میں نے ذاتی طور پر اہم بات کا عہد کیا: میں صارفین کو ایک ایسا ٹول لاؤں گا جس کے ساتھ وہ آن لائن کانفرنس کر سکیں۔
چیلنج یہ تھا: ہمیں ایک ٹول دیں جس سے ہم ٹکٹ ہولڈرز کو اپنی کانفرنسیں نشر کر سکیں۔
تمام منصوبہ بندی کو کئی مراحل میں تقسیم کیا گیا تھا، اور تمام خصوصیات (تقریباً 30 عالمی) کو 4 زمروں میں تقسیم کیا گیا تھا:
- جو ہم ضرور کریں گے (ہم ان کے بغیر نہیں رہ سکتے)
- جو ہم دوسرا کریں گے،
- جو ہم کبھی نہیں کریں گے،
- اور جو ہم کبھی نہیں کریں گے۔
ہم نے پہلی دو قسموں سے تمام خصوصیات بنائی ہیں۔
— میں جانتا ہوں کہ کل 600 JIRA ایشوز بنائے گئے تھے۔ تین مہینوں میں، آپ نے 13 مائیکرو سروسز بنائیں، اور مجھے شبہ ہے کہ وہ نہ صرف جاوا میں لکھی گئی تھیں۔ آپ نے مختلف ٹیکنالوجیز کا استعمال کیا، آپ کے پاس تین دستیابی زونز میں دو Kubernetes کلسٹرز اور Amazon میں 5 RTMP اسٹریمز ہیں۔
آئیے اب سسٹم کے ہر جزو کو الگ الگ دیکھتے ہیں۔
سلسلہ بندی
- آئیے اس وقت سے شروع کریں جب ہمارے پاس پہلے سے ہی ایک ویڈیو امیج موجود ہو، اور یہ کچھ سروسز میں منتقل ہو جائے۔ آرٹیوم، ہمیں بتائیں کہ یہ سلسلہ کیسے ہوتا ہے؟
آرٹیم نیکونوف: ہماری عمومی اسکیم اس طرح نظر آتی ہے: کیمرے سے تصویر -> ہمارے کنٹرول روم -> مقامی RTMP سرور -> Amazon -> ویڈیو پلیئر۔ مزید تفصیلات جون میں Habré پر۔
عام طور پر، ایسا کرنے کے دو عالمی طریقے ہیں: یا تو ہارڈ ویئر پر یا سافٹ ویئر کے حل پر مبنی۔ ہم نے سافٹ ویئر کے راستے کا انتخاب کیا کیونکہ ریموٹ اسپیکر کے معاملے میں یہ آسان ہے۔ کسی دوسرے ملک میں اسپیکر تک ہارڈ ویئر لانا ہمیشہ ممکن نہیں ہوتا، لیکن اسپیکر تک سافٹ ویئر پہنچانا آسان اور زیادہ قابل اعتماد لگتا ہے۔
ہارڈ ویئر کے نقطہ نظر سے، ہمارے پاس کیمرے کی ایک خاص تعداد ہے (ہمارے اسٹوڈیوز میں اور ریموٹ اسپیکرز پر)، اسٹوڈیو میں ایک مخصوص تعداد میں ریموٹ کنٹرولز ہیں، جنہیں بعض اوقات براڈکاسٹ کے دوران میز کے نیچے ٹھیک کرنا پڑتا ہے۔
ان آلات سے سگنلز کیپچر کارڈز، ان پٹ/آؤٹ پٹ کارڈز، اور ساؤنڈ کارڈز کے ساتھ کمپیوٹر میں داخل ہوتے ہیں۔ وہاں سگنلز کو ملایا جاتا ہے اور ترتیب میں جمع کیا جاتا ہے:
4 مقررین کے لے آؤٹ کی مثال
4 مقررین کے لے آؤٹ کی مثال
مزید، تین کمپیوٹرز کی مدد سے مسلسل نشریات فراہم کی جاتی ہیں: ایک اہم مشین اور باری میں کام کرنے والوں کا ایک جوڑا ہے۔ پہلا کمپیوٹر پہلی رپورٹ جمع کرتا ہے، دوسری - وقفہ، پہلی - اگلی رپورٹ، دوسری - اگلی بریک، وغیرہ۔ اور مین مشین پہلی کو دوسری کے ساتھ ملا دیتی ہے۔
اس سے ایک قسم کا مثلث بنتا ہے، اور اگر ان میں سے کوئی نوڈ ناکام ہو جاتا ہے، تو ہم تیزی سے اور معیار کے نقصان کے بغیر کلائنٹس کو مواد فراہم کرنا جاری رکھ سکتے ہیں۔ ہماری ایسی ہی حالت تھی۔ کانفرنسوں کے پہلے ہفتے کے دوران، ہم نے ایک مشین کو ٹھیک کیا، اسے آن/آف کیا۔ لوگ ہماری لچک سے خوش دکھائی دیتے ہیں۔
اس کے بعد، کمپیوٹرز سے اسٹریمز مقامی سرور پر جاتی ہیں، جس کے دو کام ہوتے ہیں: روٹ RTMP اسٹریمز اور ریکارڈ بیک اپ۔ لہذا ہمارے پاس متعدد ریکارڈنگ پوائنٹس ہیں۔ اس کے بعد ویڈیو اسٹریمز کو ہمارے سسٹم کے اس حصے میں بھیجا جاتا ہے جو Amazon SaaS سروسز پر بنایا گیا ہے۔ ہم استعمال کرتے ہیں ، S3، کلاؤڈ فرنٹ۔
نیکولے: ویڈیو سامعین تک پہنچنے سے پہلے وہاں کیا ہوتا ہے؟ آپ کو اسے کسی طرح کاٹنا ہوگا، ٹھیک ہے؟
آرٹیوم: ہم اپنی طرف سے ویڈیو کو کمپریس کرتے ہیں اور میڈیا لائیو کو بھیجتے ہیں۔ ہم وہاں ٹرانس کوڈر لانچ کرتے ہیں۔ وہ ویڈیوز کو حقیقی وقت میں کئی ریزولوشنز میں ٹرانس کوڈ کرتے ہیں تاکہ لوگ انہیں اپنے فون پر، ملک میں خراب انٹرنیٹ کے ذریعے، وغیرہ دیکھ سکیں۔ پھر ان ندیوں کو کاٹ دیا جاتا ہے۔ اس طرح پروٹوکول کام کرتا ہے۔ . ہم فرنٹ اینڈ پر ایک پلے لسٹ بھیجتے ہیں جس میں ان حصوں کی طرف اشارہ ہوتا ہے۔
- کیا ہم 1080p ریزولوشن استعمال کر رہے ہیں؟
آرٹیوم: ہمارے ویڈیو کی چوڑائی 1080p - 1920 پکسلز کے برابر ہے، اور اونچائی تھوڑی کم ہے، تصویر زیادہ لمبی ہے - اس کی وجوہات ہیں۔
پلیئر
- آرٹیوم نے بتایا کہ ویڈیو کس طرح اسٹریمز میں آتی ہے، اسے مختلف اسکرین ریزولوشنز کے لیے مختلف پلے لسٹس میں کیسے تقسیم کیا جاتا ہے، ٹکڑوں میں کاٹ کر پلیئر میں داخل کیا جاتا ہے۔ کولیا، اب مجھے بتائیں کہ یہ کس قسم کا کھلاڑی ہے، یہ ندی کو کیسے کھاتا ہے، کیوں HLS؟
نیکولے: ہمارے پاس ایک کھلاڑی ہے جسے تمام کانفرنس کے ناظرین دیکھ سکتے ہیں۔
بنیادی طور پر، یہ لائبریری کے ارد گرد ایک ریپر ہے جس پر بہت سے دوسرے کھلاڑی لکھے ہوئے ہیں۔ لیکن ہمیں بہت مخصوص فعالیت کی ضرورت ہے: ریوائنڈنگ اور اس جگہ کو نشان زد کرنا جہاں وہ شخص ہے، وہ فی الحال کون سی رپورٹ دیکھ رہا ہے۔ ہمیں اپنے لے آؤٹس، ہر طرح کے لوگو اور ہر وہ چیز درکار تھی جو ہمارے ساتھ بنی ہوئی تھی۔ لہذا، ہم نے اپنی لائبریری (HLS پر ایک ریپر) لکھنے اور اسے سائٹ پر شامل کرنے کا فیصلہ کیا۔
یہ جڑ کی فعالیت ہے، لہذا یہ تقریبا پہلے لاگو کیا گیا تھا. اور پھر سب کچھ اس کے ارد گرد بڑھ گیا.
درحقیقت، اجازت کے ذریعے، کھلاڑی کو بیک اینڈ سے ایک پلے لسٹ موصول ہوتی ہے جس میں وقت اور معیار کے ساتھ منسلک ٹکڑوں کے لنک ہوتے ہیں، ضروری کو ڈاؤن لوڈ کرتے ہیں اور راستے میں کچھ "جادو" کرتے ہوئے صارف کو دکھاتے ہیں۔
ٹائم لائن کی مثال
- تمام رپورٹس کی ٹائم لائن ظاہر کرنے کے لیے پلیئر میں ایک بٹن بنایا گیا ہے...
نیکولے: جی ہاں، ہم نے فوری طور پر صارف نیویگیشن کا مسئلہ حل کر دیا۔ اپریل کے وسط میں، ہم نے فیصلہ کیا کہ ہم اپنی ہر کانفرنس کو ایک الگ ویب سائٹ پر نشر نہیں کریں گے، بلکہ ہر چیز کو ایک پر یکجا کریں گے۔ تاکہ فل پاس ٹکٹ استعمال کرنے والے مختلف کانفرنسوں کے درمیان آزادانہ طور پر سوئچ کر سکیں: دونوں لائیو نشریات اور ماضی کی ریکارڈنگز۔
اور صارفین کے لیے موجودہ اسٹریم کو نیویگیٹ کرنا اور ٹریکس کے درمیان سوئچ کرنا آسان بنانے کے لیے، ہم نے ٹریکس اور رپورٹس کے درمیان سوئچ کرنے کے لیے "پورا براڈکاسٹ" بٹن اور افقی رپورٹ کارڈ بنانے کا فیصلہ کیا۔ کی بورڈ کنٹرول ہے۔
- کیا اس میں کوئی تکنیکی دشواری تھی؟
نیکولے: ان کے پاس ایک اسکرول بار تھا جس پر مختلف رپورٹس کے ابتدائی نکات کو نشان زد کیا گیا تھا۔
- آخر میں، کیا آپ نے ان نشانات کو اسکرول بار پر لاگو کیا اس سے پہلے کہ یوٹیوب کچھ ایسا ہی کرے؟
آرٹیوم: تب ان کے پاس یہ بیٹا تھا۔ ایسا لگتا ہے کہ یہ ایک بہت پیچیدہ خصوصیت ہے کیونکہ وہ پچھلے سال سے صارفین کے ساتھ جزوی طور پر اس کی جانچ کر رہے ہیں۔ اور اب یہ فروخت تک پہنچ گیا ہے۔
نیکولے: لیکن ہمیں اصل میں اسے تیزی سے فروخت کرنے کے لیے مل گیا۔ سچ میں، اس سادہ خصوصیت کے پیچھے پلیئر کے اندر بیک اینڈ، فرنٹ اینڈ، حسابات اور ریاضی کی ایک بڑی مقدار ہے۔
فرنٹ اینڈ
- آئیے یہ معلوم کریں کہ یہ مواد جو ہم دکھاتے ہیں (اسپیچ کارڈ، اسپیکر، ویب سائٹ، شیڈول) سامنے کے آخر تک کیسے پہنچتا ہے؟
ولادیمیر کراسیلشیک: ہمارے پاس کئی اندرونی آئی ٹی سسٹمز ہیں۔ ایک ایسا نظام ہے جس میں تمام رپورٹس اور تمام مقررین داخل ہیں۔ ایک ایسا عمل ہے جس کے ذریعے ایک اسپیکر کانفرنس میں حصہ لیتا ہے۔ اسپیکر ایک درخواست جمع کرتا ہے، سسٹم اسے پکڑتا ہے، پھر ایک مخصوص پائپ لائن ہوتی ہے جس کے مطابق رپورٹ بنتی ہے۔
اسپیکر پائپ لائن کو اس طرح دیکھتا ہے۔
یہ نظام ہماری اندرونی ترقی ہے۔
اگلا، آپ کو انفرادی رپورٹس سے ایک شیڈول بنانے کی ضرورت ہے۔ جیسا کہ آپ جانتے ہیں، یہ ایک NP- مشکل مسئلہ ہے، لیکن ہم اسے کسی نہ کسی طرح حل کرتے ہیں۔ ایسا کرنے کے لیے، ہم ایک اور جزو لانچ کرتے ہیں جو ایک شیڈول تیار کرتا ہے اور اسے تھرڈ پارٹی کلاؤڈ سروس Contentful پر اپ لوڈ کرتا ہے۔ وہاں، سب کچھ ایک میز کی طرح لگتا ہے جس میں کانفرنس کے دن ہوتے ہیں، دنوں میں ٹائم سلاٹ ہوتے ہیں، اور سلاٹس میں رپورٹس، وقفے یا سپانسرشپ کی سرگرمیاں ہوتی ہیں۔ لہذا جو مواد ہم دیکھتے ہیں وہ فریق ثالث کی خدمت میں موجود ہے۔ اور کام اس کو سائٹ تک پہنچانا ہے۔
ایسا لگتا ہے کہ سائٹ صرف ایک پلیئر کے ساتھ ایک صفحہ ہے، اور یہاں کچھ بھی پیچیدہ نہیں ہے. سوائے اس کے کہ ایسا نہیں ہے۔ اس صفحہ کے پیچھے والا بیک اینڈ Contentful پر جاتا ہے، وہاں سے شیڈول حاصل کرتا ہے، کچھ اشیاء تیار کرتا ہے اور اسے فرنٹ اینڈ پر بھیجتا ہے۔ ایک ویب ساکٹ کنکشن کا استعمال کرتے ہوئے، جو ہمارے پلیٹ فارم کا ہر کلائنٹ بناتا ہے، ہم اسے بیک اینڈ سے فرنٹ اینڈ تک شیڈول میں اپ ڈیٹ بھیجتے ہیں۔
حقیقی معاملہ: اسپیکر نے کانفرنس کے دوران ہی ملازمتیں تبدیل کیں۔ ہمیں اس کے آجر کی کمپنی کا بیج تبدیل کرنے کی ضرورت ہے۔ پسدید سے یہ کیسے ہوتا ہے؟ ویب ساکٹ کے ذریعے تمام کلائنٹس کو ایک اپ ڈیٹ بھیجا جاتا ہے، اور پھر فرنٹ اینڈ خود ہی ٹائم لائن کو دوبارہ بناتا ہے۔ یہ سب کچھ بغیر کسی رکاوٹ کے ہوتا ہے۔ کلاؤڈ سروس اور ہمارے کئی اجزاء کا امتزاج ہمیں یہ تمام مواد تیار کرنے اور اسے سامنے فراہم کرنے کا موقع فراہم کرتا ہے۔
نیکولے: یہاں یہ واضح کرنا ضروری ہے کہ ہماری سائٹ ایک کلاسک SPA ایپلیکیشن نہیں ہے۔ یہ ترتیب پر مبنی، پیش کردہ ویب سائٹ اور ایک SPA دونوں ہے۔ گوگل دراصل اس سائٹ کو رینڈر شدہ HTML کے طور پر دیکھتا ہے۔ یہ SEO اور صارف کو مواد پہنچانے کے لیے اچھا ہے۔ یہ صفحہ دیکھنے سے پہلے 1,5 میگا بائٹس جاوا اسکرپٹ کے لوڈ ہونے کا انتظار نہیں کرتا، یہ پہلے سے پیش کردہ صفحہ کو فوری طور پر دیکھتا ہے، اور جب بھی آپ رپورٹ کو تبدیل کرتے ہیں تو آپ اسے محسوس کرتے ہیں۔ سب کچھ آدھے سیکنڈ میں ہوتا ہے، کیونکہ مواد پہلے سے ہی تیار ہے اور صحیح جگہ پر پوسٹ کیا جاتا ہے۔
- آئیے ٹیکنالوجیز کی فہرست بنا کر مذکورہ بالا سبھی کے نیچے ایک لکیر کھینچتے ہیں۔ ٹیوما نے کہا کہ ہمارے پاس ایمیزون کے 5 سلسلے ہیں، اور ہم وہاں ویڈیو اور آواز فراہم کرتے ہیں۔ ہمارے پاس وہاں bash اسکرپٹس ہیں، ہم انہیں لانچ اور کنفیگر کرنے کے لیے استعمال کرتے ہیں...
آرٹیوم: یہ AWS API کے ذریعے ہوتا ہے، وہاں بہت ساری تکنیکی سائیڈ سروسز موجود ہیں۔ ہم نے اپنی ذمہ داریوں کو تقسیم کیا تاکہ میں ان کو پہنچا سکوں ، اور فرنٹ اینڈ اور بیک اینڈ ڈویلپر اسے وہاں سے لے جاتے ہیں۔ مواد کے لے آؤٹ کو آسان بنانے کے لیے ہمارے پاس اپنی کئی پابندیاں ہیں، جنہیں ہم پھر 4K وغیرہ میں بناتے ہیں۔ چونکہ آخری تاریخیں بہت سخت تھیں، اس لیے ہم نے اسے تقریباً مکمل طور پر AWS پر کیا۔
- پھر یہ سب بیک اینڈ سسٹم کا استعمال کرتے ہوئے پلیئر میں جاتا ہے۔ ہمارے پلیئر میں TypeScript، React، Next.JS ہے۔ اور بیک اینڈ پر ہمارے پاس C#، Java، Spring Boot اور Node.js میں کئی سروسز ہیں۔ یہ سب Yandex.Cloud انفراسٹرکچر کا استعمال کرتے ہوئے Kubernetes کا استعمال کرتے ہوئے تعینات کیا گیا ہے۔
میں یہ بھی نوٹ کرنا چاہتا ہوں کہ جب مجھے پلیٹ فارم سے واقف ہونے کی ضرورت تھی، تو یہ آسان نکلا: تمام ذخیرے گٹ لیب پر ہیں، ہر چیز کا نام اچھا ہے، ٹیسٹ لکھے گئے ہیں، دستاویزات موجود ہیں۔ یعنی ایمرجنسی موڈ میں بھی انہوں نے ایسی چیزوں کا خیال رکھا۔
کاروباری پابندیاں اور تجزیات
— ہم نے کاروباری ضروریات کی بنیاد پر 10 صارفین کو نشانہ بنایا۔ یہ کاروباری پابندیوں کے بارے میں بات کرنے کا وقت ہے جو ہم پر تھیں۔ ہمیں کام کا زیادہ بوجھ یقینی بنانا تھا، ذاتی ڈیٹا کے تحفظ سے متعلق قانون کی تعمیل کو یقینی بنانا تھا۔ اور کیا؟
نیکولے: ابتدائی طور پر، ہم نے ویڈیو کی ضروریات سے شروع کیا. سب سے اہم چیز کلائنٹ کو تیزی سے ڈیلیوری کے لیے پوری دنیا میں ویڈیو اسٹوریج کی تقسیم ہے۔ دیگر میں 1080p ریزولوشن کے ساتھ ساتھ ریوائنڈ بھی شامل ہے، جسے بہت سے دوسرے لائیو موڈ میں نافذ نہیں کرتے ہیں۔ بعد میں ہم نے 2x رفتار کو فعال کرنے کی صلاحیت کو شامل کیا، اس کی مدد سے آپ لائیو کے ساتھ "کیچ اپ" کر سکتے ہیں اور حقیقی وقت میں کانفرنس دیکھنا جاری رکھ سکتے ہیں۔ اور راستے میں، ٹائم لائن مارکنگ کی فعالیت ظاہر ہوئی۔ اس کے علاوہ، ہمیں غلطی کو برداشت کرنا پڑا اور 10 کنکشنز کے بوجھ کو برداشت کرنا پڑا۔ پس منظر کے نقطہ نظر سے، یہ تقریباً 000 کنکشنز ہیں جو ہر صفحہ کی تازہ کاری کے لیے 10 درخواستوں سے ضرب کرتے ہیں۔ اور یہ پہلے ہی 000 RPS/sec ہے۔ کافی تھوڑا سا.
- کیا شراکت داروں کے آن لائن اسٹینڈز کے ساتھ "ورچوئل نمائش" کے لیے کوئی اور تقاضے تھے؟
نیکولے: جی ہاں، یہ بہت تیزی سے اور عالمی سطح پر کرنا تھا۔ ہمارے پاس ہر کانفرنس کے لیے 10 پارٹنر کمپنیاں تھیں، اور ان سب کو ایک یا دو ہفتے میں مکمل ہونا تھا۔ تاہم، ان کا مواد فارمیٹ میں قدرے مختلف ہے۔ لیکن ایک مخصوص ٹیمپلیٹ انجن بنایا گیا تھا جو ان صفحات کو اڑان بھرتا ہے، جس میں عملی طور پر مزید ترقی کی شرکت نہیں تھی۔
- ریئل ٹائم آراء اور شماریات کے تجزیات کے لیے بھی تقاضے تھے۔ میں جانتا ہوں کہ ہم اس کے لیے Prometheus کا استعمال کرتے ہیں، لیکن ہمیں مزید تفصیل سے بتائیں: ہم تجزیات کے لیے کن تقاضوں کو پورا کرتے ہیں، اور یہ کیسے لاگو ہوتا ہے؟
نیکولے: ابتدائی طور پر، ہمارے پاس A/B ٹیسٹنگ کے لیے جمع کرنے اور معلومات جمع کرنے کے لیے مارکیٹنگ کے تقاضے ہیں تاکہ یہ سمجھنے کے لیے کہ مستقبل میں کلائنٹ کو بہترین مواد کیسے پہنچایا جائے۔ پارٹنر کی سرگرمیوں اور آپ جو تجزیات دیکھتے ہیں اس پر کچھ تجزیات کے لیے بھی تقاضے ہیں (کاؤنٹر پر جائیں)۔ تمام معلومات حقیقی وقت میں جمع کی جاتی ہیں۔
ہم یہ معلومات مجموعی شکل میں مقررین کو بھی فراہم کر سکتے ہیں: ایک خاص وقت پر کتنے لوگ آپ کو دیکھ رہے تھے۔ اسی وقت، وفاقی قانون 152 کی تعمیل کرنے کے لیے، آپ کے ذاتی اکاؤنٹ اور ذاتی ڈیٹا کو کسی بھی طرح سے ٹریک نہیں کیا جاتا ہے۔
پلیٹ فارم کے پاس پہلے سے ہی مارکیٹنگ ٹولز اور صارف کی سرگرمی کو حقیقی وقت میں ماپنے کے لیے ہمارے میٹرکس موجود ہیں (جس نے رپورٹ کا دوسرا حصہ دیکھا) تاکہ رپورٹس میں حاضری کا گراف بنایا جا سکے۔ اس ڈیٹا کی بنیاد پر تحقیق کی جا رہی ہے جس سے اگلی کانفرنسیں بہتر ہوں گی۔
دھوکہ
- کیا ہمارے پاس اینٹی فراڈ میکانزم ہے؟
نیکولے: کاروباری نقطہ نظر سے سخت ٹائم فریم کی وجہ سے، یہ کام ابتدائی طور پر غیر ضروری رابطوں کو فوری طور پر بلاک کرنے کے لیے مقرر نہیں کیا گیا تھا۔ اگر دو صارفین ایک ہی اکاؤنٹ کے تحت لاگ ان ہوتے ہیں، تو وہ مواد دیکھ سکتے ہیں۔ لیکن ہم جانتے ہیں کہ ایک اکاؤنٹ سے بیک وقت کتنے خیالات تھے۔ اور ہم نے کئی خاص طور پر بدنیتی پر مبنی خلاف ورزی کرنے والوں پر پابندی لگا دی۔
ولادیمیر: اس کے کریڈٹ پر، ممنوعہ صارفین میں سے ایک سمجھ گیا کہ ایسا کیوں ہوا۔ وہ آیا، معافی مانگی اور ٹکٹ خریدنے کا وعدہ کیا۔
— یہ سب ہونے کے لیے، آپ کو داخلے سے باہر نکلنے تک تمام صارفین کو مکمل طور پر ٹریس کرنا چاہیے، ہمیشہ جاننا چاہیے کہ وہ کیا کر رہے ہیں۔ یہ نظام کیسے کام کرتا ہے؟
ولادیمیر: میں تجزیات اور اعدادوشمار کے بارے میں بات کرنا چاہوں گا، جن کا تجزیہ ہم رپورٹ کی کامیابی کے لیے کرتے ہیں یا پھر شراکت داروں کو فراہم کر سکتے ہیں۔ تمام کلائنٹس ایک مخصوص بیک اینڈ کلسٹر سے ویب ساکٹ کنکشن کے ذریعے جڑے ہوئے ہیں۔ یہ وہیں کھڑا ہے۔ . ہر کلائنٹ ہر ٹائم پیریڈ میں بھیجتا ہے کہ وہ کیا کر رہا ہے اور کون سا ٹریک دیکھ رہا ہے۔ پھر اس معلومات کو تیز ہیزل کاسٹ جابز کا استعمال کرتے ہوئے جمع کیا جاتا ہے اور ان ٹریکس کو دیکھنے والے ہر فرد کو واپس بھیج دیا جاتا ہے۔ ہم کونے میں دیکھتے ہیں کہ اب کتنے لوگ ہمارے ساتھ ہیں۔
اسی معلومات میں ذخیرہ کیا جاتا ہے اور ہماری ڈیٹا جھیل پر جاتا ہے، جہاں سے ہمیں ایک اور دلچسپ گراف بنانے کا موقع ملتا ہے۔ سوال یہ پیدا ہوتا ہے کہ کتنے منفرد صارفین نے اس رپورٹ کو دیکھا؟ ہم جاتے ہیں اس رپورٹ کی آئی ڈی کے ذریعے آنے والے تمام لوگوں کے پنگ ہیں۔ ہم نے منفرد کو جمع کیا، جمع کیا، اور اب ہم سمجھ سکتے ہیں۔
نیکولے: لیکن ایک ہی وقت میں، ہم Prometheus سے ریئل ٹائم ڈیٹا بھی وصول کرتے ہیں۔ یہ تمام Kubernetes سروسز کے خلاف، خود Kubernetes کے خلاف ترتیب دیا گیا ہے۔ یہ بالکل سب کچھ جمع کرتا ہے، اور گرافانا کے ساتھ ہم حقیقی وقت میں کوئی بھی گراف بنا سکتے ہیں۔
ولادیمیر: ایک طرف، ہم اسے مزید OLAP پروسیسنگ کے لیے ڈاؤن لوڈ کرتے ہیں۔ اور OLTP کے لیے، ایپلی کیشن پوری چیز کو Prometheus، Grafana پر ڈاؤن لوڈ کرتی ہے اور گرافس بھی آپس میں مل جاتے ہیں!
- یہ معاملہ اس وقت ہوتا ہے جب گراف آپس میں مل جاتے ہیں۔
متحرک تبدیلیاں
— ہمیں بتائیں کہ متحرک تبدیلیاں کیسے لائی جاتی ہیں: اگر رپورٹ شروع ہونے سے 6 منٹ پہلے منسوخ کر دی گئی تھی، تو عمل کا سلسلہ کیا ہے؟ کون سی پائپ لائن کام کرتی ہے؟
ولادیمیر: پائپ لائن بہت مشروط ہے۔ کئی امکانات ہیں۔ پہلا یہ کہ شیڈول جنریشن پروگرام نے کام کیا اور شیڈول میں تبدیلی کی۔ ترمیم شدہ شیڈول کو Contentful پر اپ لوڈ کر دیا گیا ہے۔ جس کے بعد بیک اینڈ سمجھتا ہے کہ Contentful میں اس کانفرنس کے لیے تبدیلیاں ہیں، اسے لیتا ہے اور اسے دوبارہ بناتا ہے۔ سب کچھ جمع کیا جاتا ہے اور ویب ساکٹ کے ذریعے بھیجا جاتا ہے۔
دوسرا امکان، جب سب کچھ انتہائی تیز رفتاری سے ہوتا ہے: ایڈیٹر دستی طور پر Contentful میں معلومات کو تبدیل کرتا ہے (ٹیلیگرام کا لنک، اسپیکر کی پیشکش وغیرہ) اور وہی منطق پہلی بار کی طرح کام کرتی ہے۔
نیکولے: صفحہ کو تازہ کیے بغیر سب کچھ ہوتا ہے۔ تمام تبدیلیاں کلائنٹ کے لیے بالکل بغیر کسی رکاوٹ کے ہوتی ہیں۔ رپورٹوں کو تبدیل کرنے کے لئے بھی یہی ہے۔ وقت آنے پر رپورٹ اور انٹرفیس بدل جاتا ہے۔
ولادیمیر: نیز، ٹائم لائن میں رپورٹس کے آغاز کے لیے ٹائم کٹ آف ہیں۔ بالکل شروع میں کچھ بھی نہیں ہے۔ اور اگر آپ اپنے ماؤس کو سرخ پٹی پر گھماتے ہیں، تو کسی وقت، براڈکاسٹ ڈائریکٹر کا شکریہ، کٹ آف ظاہر ہوں گے۔ ڈائریکٹر براڈکاسٹ کا صحیح آغاز سیٹ کرتا ہے، بیک اینڈ اس تبدیلی کو اٹھاتا ہے، کانفرنس کے شیڈول کے مطابق پورے ٹریک کی پیشکشوں کے آغاز اور اختتام کے اوقات کا حساب لگاتا ہے، اسے ہمارے کلائنٹس کو بھیجتا ہے، اور کھلاڑی کٹ آف کھینچتا ہے۔ اب صارف آسانی سے رپورٹ کے آغاز اور اختتام تک جا سکتا ہے۔ یہ ایک سخت کاروباری ضرورت تھی، بہت آسان اور مفید تھی۔ آپ رپورٹ کے آغاز کا اصل وقت تلاش کرنے میں وقت ضائع نہیں کرتے ہیں۔ اور جب ہم ایک پیش نظارہ کرتے ہیں، تو یہ بالکل شاندار ہوگا۔
تعیناتی
- میں تعیناتی کے بارے میں پوچھنا چاہوں گا۔ Kolya اور ٹیم نے شروع میں پورے انفراسٹرکچر کو ترتیب دینے کے لیے کافی وقت صرف کیا جس میں ہمارے لیے سب کچھ سامنے آتا ہے۔ بتاؤ یہ سب کس چیز سے بنا ہے؟
نیکولے: تکنیکی نقطہ نظر سے، ہمارے پاس ابتدائی طور پر کسی بھی وینڈر سے پروڈکٹ کو ممکنہ حد تک خلاصہ ہونے کی ضرورت تھی۔ خاص طور پر AWS سے، یا خاص طور پر Yandex، یا Azure وغیرہ سے Terraform اسکرپٹس بنانے کے لیے AWS پر آئیں۔ واقعی فٹ نہیں تھا. ہمیں کسی وقت کہیں منتقل ہونا تھا۔
پہلے تین ہفتوں تک ہم اسے بہتر طریقے سے کرنے کے لیے مسلسل تلاش کر رہے تھے۔ نتیجے کے طور پر، ہم اس نتیجے پر پہنچے کہ اس معاملے میں Kubernetes ہی ہمارا سب کچھ ہے، کیونکہ یہ ہمیں خود کار طریقے سے اسکیلنگ کی خدمات، آٹو رول آؤٹ بنانے اور تقریباً تمام خدمات کو باکس سے باہر کرنے کی اجازت دیتا ہے۔ قدرتی طور پر، تمام خدمات کو کبرنیٹس، ڈوکر کے ساتھ کام کرنے کی تربیت دینی پڑتی تھی، اور ٹیم کو بھی سیکھنا پڑتا تھا۔
ہمارے پاس دو کلسٹر ہیں۔ ٹیسٹ اور پیداوار۔ وہ ہارڈ ویئر اور سیٹنگز کے لحاظ سے بالکل ایک جیسے ہیں۔ ہم بنیادی ڈھانچے کو کوڈ کے طور پر نافذ کرتے ہیں۔ تمام خدمات خود بخود ایک خودکار پائپ لائن کا استعمال کرتے ہوئے فیچر برانچز، ماسٹر برانچز، ٹیسٹ برانچز اور GitLab سے تین ماحول میں رول آؤٹ ہو جاتی ہیں۔ یہ زیادہ سے زیادہ GitLab میں مربوط ہے، زیادہ سے زیادہ لچکدار، Prometheus کے ساتھ مربوط ہے۔
ہمیں فوری طور پر (10 منٹ کے اندر بیک اینڈ کے لیے، 5 منٹ کے اندر فرنٹ اینڈ کے لیے) تمام ٹیسٹوں، انضمام، چلانے والے فنکشنل ٹیسٹ، ماحول پر انٹیگریشن ٹیسٹ، اور لوڈ ٹیسٹ کے ساتھ ٹیسٹ کے ساتھ کسی بھی ماحول میں تبدیلیوں کو رول آؤٹ کرنے کا موقع ملتا ہے۔ ایک امتحانی ماحول تقریباً وہی چیز ہے جسے ہم پیداوار میں حاصل کرنا چاہتے ہیں۔
ٹیسٹ کے بارے میں
- آپ تقریباً ہر چیز کی جانچ کرتے ہیں، یہ یقین کرنا مشکل ہے کہ آپ نے سب کچھ کیسے لکھا۔ کیا آپ ہمیں بیک اینڈ ٹیسٹ کے بارے میں بتا سکتے ہیں: ہر چیز کا کتنا احاطہ کیا گیا ہے، کون سے ٹیسٹ؟
ولادیمیر: دو قسم کے ٹیسٹ لکھے گئے ہیں۔ سب سے پہلے اجزاء کے ٹیسٹ ہیں۔ پورے موسم بہار کی درخواست کے لفٹ لیول ٹیسٹ اور بیس ان . یہ اعلیٰ ترین کاروباری منظرناموں کا امتحان ہے۔ میں افعال کی جانچ نہیں کرتا ہوں۔ ہم صرف کچھ بڑی چیزوں کی جانچ کرتے ہیں۔ مثال کے طور پر، بالکل ٹیسٹ میں، صارف میں لاگ ان کرنے کے عمل کی تقلید کی جاتی ہے، صارف کی ٹکٹوں کی درخواست جہاں وہ جا سکتا ہے، اور سلسلہ دیکھنے کے لیے رسائی کی درخواست۔ بہت واضح صارف کے منظرنامے۔
تقریباً ایک ہی چیز کو نام نہاد انضمام کے ٹیسٹوں میں لاگو کیا جاتا ہے، جو دراصل ماحول پر چلتے ہیں۔ درحقیقت، جب پیداوار میں اگلی تعیناتی شروع کی جاتی ہے، حقیقی بنیادی منظرنامے بھی پیداوار میں چل رہے ہوتے ہیں۔ وہی لاگ ان، ٹکٹوں کی درخواست، CloudFront تک رسائی کی درخواست، یہ چیک کرنا کہ سٹریم واقعی میری اجازتوں سے جڑتا ہے، ڈائریکٹر کے انٹرفیس کو چیک کرنا۔
اس وقت میرے پاس بورڈ پر تقریباً 70 اجزاء کے ٹیسٹ اور تقریباً 40 انضمام کے ٹیسٹ ہیں۔ کوریج 95٪ کے بہت قریب ہے۔ یہ جزو والوں کے لیے ہے، انضمام والوں کے لیے کم، بس اتنی زیادہ ضرورت نہیں ہے۔ اس بات کو مدنظر رکھتے ہوئے کہ پروجیکٹ میں ہر طرح کے کوڈ جنریشن شامل ہیں، یہ ایک بہت اچھا اشارہ ہے۔ ہم نے تین مہینوں میں جو کچھ کیا اسے کرنے کا کوئی دوسرا راستہ نہیں تھا۔ کیونکہ اگر ہم دستی طور پر جانچ کرتے ہیں، اپنے ٹیسٹر کو خصوصیات دیتے ہیں، اور وہ کیڑے ڈھونڈ کر ہمیں درست کرنے کے لیے واپس کر دیتی ہے، تو کوڈ کو ڈیبگ کرنے کے لیے یہ راؤنڈ ٹرپ بہت طویل ہو گا، اور ہم کسی ڈیڈ لائن کو پورا نہیں کریں گے۔
نیکولے: روایتی طور پر، کسی فنکشن کو تبدیل کرتے وقت پورے پلیٹ فارم پر ریگریشن کرنے کے لیے، آپ کو دو دن کے لیے ہر جگہ بیٹھ کر پوک کرنے کی ضرورت ہے۔
ولادیمیر: لہذا، یہ ایک بڑی کامیابی ہے کہ جب میں کسی خصوصیت کا تخمینہ لگاتا ہوں، میں کہتا ہوں کہ مجھے دو سادہ قلم اور 4 ویب ساکٹ کے لیے 1 دن درکار ہیں، کولیا اجازت دیتا ہے۔ وہ پہلے سے ہی اس حقیقت کا عادی ہے کہ ان 4 دنوں میں 2 قسم کے ٹیسٹ شامل ہیں، اور پھر، زیادہ تر امکان ہے، یہ کام کرے گا۔
نیکولے: میرے پاس 140 ٹیسٹ بھی لکھے گئے ہیں: component + functional، جو ایک ہی کام کرتے ہیں۔ تمام یکساں منظرناموں کو پیداوار، ٹیسٹ اور پیداوار میں جانچا جاتا ہے۔ ہم نے حال ہی میں فنکشنل بنیادی UI ٹیسٹ بھی شامل کیے ہیں۔ اس طرح ہم سب سے بنیادی فعالیت کا احاطہ کرتے ہیں جو ٹوٹ سکتی ہے۔
ولادیمیر: یقینا، یہ لوڈ ٹیسٹ کے بارے میں بات کرنے کے قابل ہے. یہ سمجھنے کے لیے کہ سب کچھ کیسا ہے، خرگوش کے ساتھ کیا ہو رہا ہے، JVMs کے ساتھ کیا ہو رہا ہے، اصل میں کتنی میموری کی ضرورت ہے۔
- میں یقینی طور پر نہیں جانتا کہ آیا ہم اسٹریم سائیڈ پر کسی چیز کی جانچ کر رہے ہیں، لیکن مجھے یاد ہے کہ جب ہم میٹنگ کرتے تھے تو ٹرانس کوڈرز کے ساتھ مسائل تھے۔ کیا ہم نے ندیوں کا تجربہ کیا ہے؟
آرٹیوم: بار بار تجربہ کیا۔ ملاقاتوں کا اہتمام کرنا۔ میٹ اپس کو منظم کرنے کے عمل میں، تقریباً 2300 JIRA ٹکٹس تھے۔ یہ صرف عام چیزیں ہیں جو لوگوں نے ملاقاتیں کرنے کے لیے کیں۔ ہم نے پلیٹ فارم کے کچھ حصوں کو ملاقاتوں کے لیے ایک علیحدہ صفحہ پر لے لیا، جسے کیرل ٹولکاچیف چلا رہے تھے۔).
سچ پوچھیں تو کوئی بڑا مسئلہ نہیں تھا۔ لفظی طور پر ایک دو بار ہم نے CloudFront پر کیشنگ کیڑے پکڑے، ہم نے اسے کافی تیزی سے حل کیا - ہم نے صرف پالیسیوں کو دوبارہ ترتیب دیا۔ سائٹ پر اسٹریمنگ سسٹمز میں لوگوں میں نمایاں طور پر زیادہ کیڑے تھے۔
کانفرنسوں کے دوران، مجھے مزید سامان اور خدمات کا احاطہ کرنے کے لیے کئی اور برآمد کنندگان کو لکھنا پڑا۔ کچھ جگہوں پر مجھے صرف میٹرکس کی خاطر اپنی سائیکلیں خود بنانا پڑیں۔ اے وی (آڈیو-ویڈیو) ہارڈویئر کی دنیا زیادہ گلابی نہیں ہے - آپ کے پاس کچھ قسم کا "API" سامان ہے جس پر آپ اثر انداز نہیں ہو سکتے۔ اور یہ حقیقت سے بعید ہے کہ آپ اپنی مطلوبہ معلومات حاصل کر سکیں گے۔ ہارڈ ویئر فروش واقعی سست ہیں، اور آپ ان سے جو چاہتے ہیں اسے حاصل کرنا تقریباً ناممکن ہے۔ مجموعی طور پر ہارڈ ویئر کے 100 سے زیادہ ٹکڑے ہیں، وہ آپ کی ضرورت کو واپس نہیں کرتے، اور آپ عجیب اور بے کار برآمد کنندگان لکھتے ہیں، جس کی بدولت آپ کم از کم کسی نہ کسی طرح سسٹم کو ڈیبگ کر سکتے ہیں۔
سامان
- مجھے یاد ہے کہ کس طرح کانفرنسوں کے آغاز سے پہلے ہم نے جزوی طور پر اضافی سامان خریدا تھا۔
آرٹیوم: ہم نے کمپیوٹر، لیپ ٹاپ اور بیٹری پیک خریدے۔ اس وقت ہم 40 منٹ تک بجلی کے بغیر رہ سکتے ہیں۔ جون میں سینٹ پیٹرزبرگ میں شدید گرج چمک کے ساتھ طوفان آیا تھا - اس لیے ہمارے پاس ایسا بلیک آؤٹ تھا۔ ایک ہی وقت میں، کئی فراہم کنندگان مختلف پوائنٹس سے آپٹیکل لنکس کے ساتھ ہمارے پاس آتے ہیں۔ یہ واقعی 40 منٹ کا بلڈنگ ڈاؤن ٹائم ہے، جس کے دوران ہمارے پاس لائٹس آن، ساؤنڈ، کیمرے وغیرہ کام کر رہے ہوں گے۔
- ہمارے پاس انٹرنیٹ کے ساتھ بھی ایسی ہی کہانی ہے۔ دفتر میں جہاں ہمارے سٹوڈیو واقع ہیں، ہم نے فرشوں کے درمیان ایک زبردست جال گھسیٹا۔
آرٹیوم: ہمارے پاس فرش کے درمیان 20 Gbit فائبر ہے۔ فرش کے ساتھ ساتھ، کہیں آپٹکس ہے، کہیں آپٹکس نہیں ہے، لیکن پھر بھی گیگابٹ چینلز سے کم چینلز ہیں - ہم کانفرنس کے پٹریوں کے درمیان ان پر ویڈیو چلاتے ہیں۔ عام طور پر، آپ کے اپنے بنیادی ڈھانچے پر کام کرنا بہت آسان ہے؛ سائٹس پر آف لائن کانفرنسوں میں آپ شاذ و نادر ہی ایسا کر سکتے ہیں۔
— اس سے پہلے کہ میں نے JUG Ru گروپ میں کام کیا، میں نے دیکھا کہ کس طرح آف لائن کانفرنسوں میں ہارڈویئر رومز راتوں رات قائم کیے جاتے ہیں، جہاں آپ گرافانا میں بنائے گئے تمام میٹرکس کے ساتھ ایک بڑا مانیٹر ہوتا ہے۔ اب ایک ہیڈ کوارٹر روم بھی ہے جس میں ترقیاتی ٹیم بیٹھتی ہے جو کانفرنس کے دوران کچھ کیڑے ٹھیک کرتی ہے اور خصوصیات تیار کرتی ہے۔ ایک ہی وقت میں، ایک نگرانی کا نظام ہے جو ایک بڑی اسکرین پر ظاہر ہوتا ہے. Artyom، Kolya اور دوسرے لوگ بیٹھتے ہیں اور اس بات کو یقینی بناتے ہیں کہ یہ سب گر نہ جائے اور خوبصورتی سے کام کرے۔
تجسس اور مسائل
- آپ نے اس حقیقت کے بارے میں اچھی بات کی کہ ہمارے پاس ایمیزون کے ساتھ سلسلہ بندی ہے، ویب کے ساتھ ایک پلیئر ہے، ہر چیز مختلف پروگرامنگ زبانوں میں لکھی جاتی ہے، غلطی کو برداشت کرنے اور دیگر کاروباری ضروریات فراہم کی جاتی ہیں، بشمول ایک ذاتی اکاؤنٹ جو قانونی اداروں اور افراد، اور ہم OAuth 2.0 کا استعمال کرتے ہوئے کسی کے ساتھ ضم کر سکتے ہیں، اینٹی فراڈ، صارف کو بلاک کرنا ہے۔ ہم تبدیلیوں کو متحرک طور پر رول آؤٹ کر سکتے ہیں کیونکہ ہم نے اسے اچھی طرح سے انجام دیا، اور یہ سب آزمایا گیا ہے۔
مجھے یہ جاننے میں دلچسپی ہے کہ کچھ شروع کرنے میں کون سی عجیب و غریب چیزیں شامل تھیں۔ کیا کوئی عجیب و غریب حالات پیش آئے ہیں جب آپ بیک اینڈ، فرنٹ اینڈ تیار کر رہے تھے، کچھ پاگل نکلا اور آپ کو سمجھ نہیں آرہی تھی کہ اس کا کیا کریں؟
ولادیمیر: مجھے لگتا ہے کہ یہ صرف پچھلے تین ماہ سے ہوا ہے۔ ہر روز. جیسا کہ آپ دیکھ سکتے ہیں، میرے تمام بال نکالے گئے ہیں.
Vladimir Krasilshchik 3 ماہ کے بعد، جب کسی قسم کا کھیل نکلا اور کسی کو سمجھ نہیں آیا کہ اس کا کیا کرنا ہے
ہر روز کچھ ایسا ہوتا تھا، جب کوئی ایسا لمحہ آتا تھا جب آپ اسے لے کر اپنے بال پھاڑ دیتے تھے، یا یہ احساس ہوتا تھا کہ کوئی اور نہیں ہے، اور صرف آپ ہی یہ کر سکتے ہیں۔ ہمارا پہلا بڑا ایونٹ TechTrain تھا۔ 6 جون کو دوپہر 2 بجے ہم نے ابھی تک پیداواری ماحول کو تیار نہیں کیا تھا، کولیا اسے رول آؤٹ کر رہا تھا۔ اور ذاتی اکاؤنٹ OAuth2.0 کا استعمال کرتے ہوئے اجازت دینے والے سرور کے طور پر کام نہیں کرتا تھا۔ پلیٹ فارم کو اس سے مربوط کرنے کے لیے ہم نے اسے OAuth2.0 فراہم کنندہ میں تبدیل کر دیا۔ میں شاید 18 گھنٹے تک کام کر رہا تھا، میں نے کمپیوٹر کو دیکھا اور مجھے کچھ نظر نہیں آیا، مجھے سمجھ نہیں آ رہی تھی کہ یہ کیوں کام نہیں کر رہا ہے، اور کولیا نے دور سے میرے کوڈ کو دیکھا، اسپرنگ کنفیگریشن میں ایک بگ تلاش کیا۔ ، اسے مل گیا، اور LC نے کام کیا، اور پیداوار میں بھی۔
نیکولے: اور TechTrain کی ریلیز سے ایک گھنٹہ پہلے ہوا۔
بہت سارے ستارے یہاں منسلک تھے۔ ہم بہت خوش قسمت تھے کیونکہ ہمارے پاس ایک سپر ٹیم تھی، اور ہر کوئی اسے آن لائن کرنے کے خیال سے متاثر تھا۔ ان تینوں مہینوں میں ہم اس حقیقت سے متاثر تھے کہ ہم نے "YouTube بنایا"۔ میں نے خود کو اپنے بالوں کو پھاڑنے کی اجازت نہیں دی، لیکن سب کو بتایا کہ سب کچھ ٹھیک ہو جائے گا، کیونکہ حقیقت میں، ہر چیز کا حساب بہت پہلے ہو چکا تھا۔
کارکردگی کے بارے میں
— کیا آپ مجھے بتا سکتے ہیں کہ ایک ٹریک پر سائٹ پر کتنے لوگ تھے؟ کیا کارکردگی کا کوئی مسئلہ تھا؟
نیکولے: کارکردگی کا کوئی مسئلہ نہیں تھا، جیسا کہ ہم پہلے ہی کہہ چکے ہیں۔ ایک رپورٹ میں شرکت کرنے والے لوگوں کی زیادہ سے زیادہ تعداد 1300 افراد تھی، یہ ہائیزن بگ پر ہے۔
- کیا مقامی دیکھنے کے ساتھ کوئی مسئلہ تھا؟ اور کیا یہ ممکن ہے کہ خاکوں کے ساتھ تکنیکی وضاحت ہو کہ یہ سب کیسے کام کرتا ہے؟
نیکولے: اس کے بارے میں ہم بعد میں ایک مضمون بنائیں گے۔
یہاں تک کہ آپ اسٹریمز کو مقامی طور پر ڈیبگ کر سکتے ہیں۔ ایک بار کانفرنسیں شروع ہونے کے بعد، یہ اور بھی آسان ہو گیا، کیونکہ پروڈکشن اسٹریمز نمودار ہوئیں جنہیں ہم ہر وقت دیکھ سکتے ہیں۔
ولادیمیر: جیسا کہ میں اسے سمجھتا ہوں، فرنٹ اینڈ ڈویلپرز نے مقامی طور پر طنز کے ساتھ کام کیا، اور پھر، چونکہ فرنٹ میں ڈیویس کو رول آؤٹ کرنے کا وقت بھی کم ہے (5 منٹ)، سرٹیفکیٹس کے ساتھ کیا ہو رہا ہے اس کی جانچ کرنے میں کوئی مسئلہ نہیں ہے۔
- ہر چیز کا تجربہ کیا جاتا ہے اور ڈیبگ کیا جاتا ہے، یہاں تک کہ مقامی طور پر۔ اس کا مطلب ہے کہ ہم تمام تکنیکی خصوصیات کے ساتھ ایک مضمون لکھیں گے، آپ کو دکھائیں گے، آپ کو خاکوں کے ساتھ سب کچھ بتائیں گے، یہ کیسا تھا۔
ولادیمیر: آپ اسے لے سکتے ہیں اور اسے دوبارہ کر سکتے ہیں.
- 3 ماہ میں۔
کل
- ایک ساتھ بیان کردہ ہر چیز اچھی لگتی ہے، اس بات پر غور کرتے ہوئے کہ یہ ایک چھوٹی ٹیم نے تین مہینوں میں کیا تھا۔
نیکولے: ایک بڑی ٹیم ایسا نہیں کرے گی۔ لیکن لوگوں کا ایک چھوٹا گروپ جو ایک دوسرے کے ساتھ بہت قریب سے اور اچھی طرح سے بات چیت کرتے ہیں اور ایک معاہدے پر آسکتے ہیں۔ ان میں کوئی تضاد نہیں ہے، فن تعمیر دو دن میں ایجاد ہوا، حتمی شکل دی گئی اور حقیقت میں اس میں کوئی تبدیلی نہیں آئی۔ خصوصیت کی درخواستوں اور تبدیلیوں کو جمع کرنے کے سلسلے میں آنے والی کاروباری ضروریات کی بہت سخت سہولت ہے۔
- جب موسم گرما کی کانفرنسیں ہو چکی تھیں تو آپ کے مزید کاموں کی فہرست میں کیا تھا؟
نیکولے: مثال کے طور پر، کریڈٹس۔ ویڈیو پر رینگتی لکیریں، دکھائے جانے والے مواد کے لحاظ سے ویڈیو میں کچھ جگہوں پر پاپ اپس۔ مثال کے طور پر، اسپیکر سامعین سے ایک سوال پوچھنا چاہتا ہے، اور ایک ووٹ اسکرین پر ظاہر ہوتا ہے، جو اسپیکر کو ووٹنگ کے نتائج کی بنیاد پر پیچھے کی طرف جاتا ہے۔ پریزنٹیشن کے دوران ہی رپورٹ کی پسندیدگیوں، دلوں، درجہ بندیوں کی شکل میں کسی قسم کی سماجی سرگرمی، تاکہ آپ فیڈ بیک فارمز سے بعد میں پریشان ہوئے بغیر صحیح وقت پر فیڈ بیک پُر کرسکیں۔ شروع میں اس طرح۔
اور پورے پلیٹ فارم میں شامل کرنا، سوائے اسٹریمنگ اور کانفرنس کے، کانفرنس کے بعد کی حالت بھی۔ یہ پلے لسٹس ہیں (بشمول صارفین کی طرف سے مرتب کردہ)، ممکنہ طور پر ماضی کی دیگر کانفرنسوں کا مواد، مربوط، لیبل لگا ہوا، صارف کے لیے قابل رسائی، اور ہماری ویب سائٹ پر دیکھنے کے لیے بھی دستیاب ہے۔).
- دوستو، آپ کے جوابات کے لیے بہت بہت شکریہ!
اگر قارئین میں ایسے لوگ ہیں جنہوں نے ہماری سمر کانفرنسوں میں شرکت کی، تو پلیئر اور براڈکاسٹ کے بارے میں اپنے تاثرات شیئر کریں۔ کیا سہولت تھی، آپ کو کس چیز نے پریشان کیا، آپ مستقبل میں کیا دیکھنا چاہیں گے؟
اگر آپ پلیٹ فارم میں دلچسپی رکھتے ہیں اور اسے "جنگ میں" دیکھنا چاہتے ہیں، تو ہم اسے دوبارہ استعمال کرتے ہیں۔ . ان میں سے ایک پوری رینج ہے، لہذا تقریباً یقینی طور پر ایک ایسا ہے جو آپ کے لیے صحیح ہے۔
ماخذ: www.habr.com