Habr فرنٹ اینڈ ڈویلپر لاگز: ریفیکٹرنگ اور عکاسی کرنا

میں ہمیشہ سے اس بات میں دلچسپی رکھتا ہوں کہ Habr کو اندر سے کیسے بنایا جاتا ہے، ورک فلو کی ساخت کیسے ہوتی ہے، کمیونیکیشنز کی ساخت کیسے ہوتی ہے، کون سے معیارات استعمال کیے جاتے ہیں اور عام طور پر یہاں کوڈ کیسے لکھا جاتا ہے۔ خوش قسمتی سے، مجھے ایسا موقع ملا، کیونکہ میں حال ہی میں ہابرا ٹیم کا حصہ بنا ہوں۔ موبائل ورژن کی ایک چھوٹی سی ریفیکٹرنگ کی مثال کا استعمال کرتے ہوئے، میں اس سوال کا جواب دینے کی کوشش کروں گا: یہاں سامنے کام کرنا کیسا ہے۔ پروگرام میں: نوڈ، ویو، ویویکس اور ایس ایس آر کے ساتھ چٹنی کے ساتھ ہابر میں ذاتی تجربے کے بارے میں نوٹس۔

ڈیولپمنٹ ٹیم کے بارے میں آپ کو سب سے پہلے جاننے کی ضرورت یہ ہے کہ ہم میں سے کچھ لوگ ہیں۔ کافی نہیں - یہ تین محاذ، دو پشتیں اور تمام ہیبر کی تکنیکی قیادت - بیکسلے ہیں۔ بلاشبہ، ایک ٹیسٹر، ایک ڈیزائنر، تین وادیم، ایک معجزہ جھاڑو، ایک مارکیٹنگ ماہر اور دیگر بمبورم بھی ہے۔ لیکن حبر کے ذرائع میں صرف چھ براہ راست تعاون کرنے والے ہیں۔ یہ کافی نایاب ہے - ملین ڈالر کے سامعین کے ساتھ ایک پروجیکٹ، جو باہر سے ایک دیو ہیکل انٹرپرائز کی طرح لگتا ہے، حقیقت میں ایک آرام دہ آغاز کی طرح لگتا ہے جس میں سب سے فلیٹ تنظیمی ڈھانچہ ممکن ہے۔

بہت سی دوسری IT کمپنیوں کی طرح، Habr بھی چست آئیڈیاز، CI پریکٹسز، اور بس اتنا ہی ہے۔ لیکن میرے احساسات کے مطابق، حبر ایک مصنوعات کے طور پر مسلسل سے زیادہ لہروں میں ترقی کر رہا ہے۔ لہذا، لگاتار کئی سپرنٹ کے لیے، ہم پوری تندہی سے کسی چیز کو کوڈ کرتے ہیں، ڈیزائن اور نئے سرے سے ڈیزائن کرتے ہیں، کسی چیز کو توڑتے ہیں اور اسے ٹھیک کرتے ہیں، ٹکٹوں کو حل کرتے ہیں اور نئی تخلیق کرتے ہیں، ایک ریک پر قدم رکھتے ہیں اور خود کو پیروں میں گولی مار دیتے ہیں، تاکہ آخر کار اس خصوصیت کو جاری کیا جا سکے۔ پیداوار اور پھر ایک خاص خاموشی، دوبارہ ترقی کی مدت، وہ کام کرنے کا وقت آتا ہے جو "اہم - ضروری نہیں" کواڈرینٹ میں ہے۔

یہ خاص طور پر یہ "آف سیزن" سپرنٹ ہے جس پر ذیل میں تبادلہ خیال کیا جائے گا۔ اس بار اس میں حبر کے موبائل ورژن کی ری فیکٹرنگ شامل تھی۔ عام طور پر، کمپنی کو اس سے بہت زیادہ امیدیں ہیں، اور مستقبل میں اسے Habr کے اوتاروں کے پورے چڑیا گھر کی جگہ لے لینی چاہیے اور ایک عالمگیر کراس پلیٹ فارم حل بن جانا چاہیے۔ کسی دن انکولی لے آؤٹ، PWA، آف لائن موڈ، صارف کی تخصیص، اور بہت سی دوسری دلچسپ چیزیں ہوں گی۔

آئیے ٹاسک سیٹ کریں۔

ایک بار، ایک عام اسٹینڈ اپ میں، سامنے والے میں سے ایک نے موبائل ورژن کے تبصرے کے اجزاء کے فن تعمیر میں مسائل کے بارے میں بات کی۔ اس کو ذہن میں رکھتے ہوئے، ہم نے گروپ سائیکو تھراپی کی شکل میں ایک مائیکرو میٹنگ کا اہتمام کیا۔ سب نے باری باری یہ کہتے ہوئے کہا کہ کہاں تکلیف ہوئی، انہوں نے سب کچھ کاغذ پر درج کیا، ہمدردی کی، وہ سمجھ گئے، سوائے اس کے کہ کسی نے تالی نہیں بجائی۔ نتیجہ 20 مسائل کی ایک فہرست تھی، جس نے یہ واضح کیا کہ موبائل ہیبر کے پاس کامیابی کا ایک طویل اور کانٹوں والا راستہ ہے۔

میں بنیادی طور پر وسائل کی کارکردگی اور ہموار انٹرفیس کے بارے میں فکر مند تھا۔ ہر روز، گھر کے کام کے گھر کے راستے پر، میں نے اپنے پرانے فون کو فیڈ میں 20 سرخیاں دکھانے کی شدت سے کوشش کرتے دیکھا۔ یہ کچھ اس طرح نظر آیا:

ری فیکٹرنگ سے پہلے موبائل ہیبر انٹرفیس

یہاں کیا ہو رہا ہے؟ مختصراً، سرور نے HTML صفحہ سب کو اسی طرح پیش کیا، قطع نظر اس سے کہ صارف لاگ ان ہوا ہے یا نہیں۔ پھر کلائنٹ JS لوڈ ہوتا ہے اور دوبارہ ضروری ڈیٹا کی درخواست کرتا ہے، لیکن اجازت کے لیے ایڈجسٹ کیا جاتا ہے۔ یعنی ہم نے دراصل ایک ہی کام دو بار کیا۔ انٹرفیس جھلملاتا ہے، اور صارف نے ایک اچھا سو اضافی کلو بائٹس ڈاؤن لوڈ کیا۔ تفصیل سے سب کچھ اور بھی خوفناک لگ رہا تھا۔

پرانی SSR-CSR اسکیم۔ اجازت صرف C3 اور C4 مراحل پر ہی ممکن ہے، جب نوڈ جے ایس ایچ ٹی ایم ایل بنانے میں مصروف نہیں ہے اور API کو پراکسی درخواستیں دے سکتا ہے۔

اس وقت کے ہمارے فن تعمیر کو حبر استعمال کرنے والوں میں سے ایک نے بہت درست طریقے سے بیان کیا تھا:

موبائل ورژن گھٹیا ہے۔ میں اسے ایسے ہی بتا رہا ہوں۔ SSR اور CSR کا ایک خوفناک امتزاج۔

ہمیں اسے تسلیم کرنا پڑا، چاہے یہ کتنا ہی دکھ کی بات ہو۔

میں نے آپشنز کا جائزہ لیا، جیرا میں ایک ٹکٹ بنایا جس میں "ابھی برا ہے، ٹھیک کرو" کی سطح پر وضاحت کی اور کام کو وسیع اسٹروک میں گل کر دیا:

• ڈیٹا کا دوبارہ استعمال،
• دوبارہ ڈرا کی تعداد کو کم سے کم کریں،
• نقل کی درخواستوں کو ختم کریں،
• لوڈنگ کے عمل کو مزید واضح کریں۔

آئیے ڈیٹا کو دوبارہ استعمال کریں۔

نظریہ میں، سرور سائیڈ رینڈرنگ کو دو مسائل کو حل کرنے کے لیے ڈیزائن کیا گیا ہے: تلاش کے انجن کی حدود کا شکار نہ ہونا SPA انڈیکسنگ اور میٹرک کو بہتر بنائیں ایف ایم پی (لامحالہ بگڑنا ٹی ٹی آئی)۔ ایک کلاسک منظر نامے میں جو آخر کار 2013 میں Airbnb میں تیار کیا گیا۔ سال (اب بھی Backbone.js پر)، SSR وہی isomorphic JS ایپلیکیشن ہے جو نوڈ ماحول میں چل رہی ہے۔ سرور صرف درخواست کے جواب کے طور پر تیار کردہ ترتیب بھیجتا ہے۔ پھر کلائنٹ کی طرف سے ری ہائیڈریشن ہوتی ہے، اور پھر صفحہ دوبارہ لوڈ کیے بغیر سب کچھ کام کرتا ہے۔ Habr کے لیے، جیسا کہ متنی مواد کے ساتھ بہت سے دوسرے وسائل کے لیے، سرور رینڈرنگ سرچ انجنوں کے ساتھ دوستانہ تعلقات استوار کرنے میں ایک اہم عنصر ہے۔

اس حقیقت کے باوجود کہ ٹیکنالوجی کی آمد کو چھ سال سے زیادہ کا عرصہ گزر چکا ہے، اور اس وقت کے دوران سامنے کی دنیا میں پل کے نیچے سے بہت سا پانی بہہ چکا ہے، بہت سے ڈویلپرز کے لیے یہ خیال اب بھی رازداری میں ڈوبا ہوا ہے۔ ہم ایک طرف نہیں کھڑے ہوئے اور پیداوار کے لیے SSR سپورٹ کے ساتھ Vue ایپلیکیشن کو رول آؤٹ کیا، جس میں ایک چھوٹی سی تفصیل غائب تھی: ہم نے کلائنٹ کو ابتدائی حالت نہیں بھیجی۔

کیوں؟ اس سوال کا کوئی صحیح جواب نہیں ہے۔ یا تو وہ سرور سے ردعمل کے سائز میں اضافہ نہیں کرنا چاہتے تھے، یا دیگر تعمیراتی مسائل کے ایک گروپ کی وجہ سے، یا یہ آسانی سے ختم نہیں ہوا۔ کسی نہ کسی طرح، حالت کو باہر پھینکنا اور سرور نے جو کچھ کیا اسے دوبارہ استعمال کرنا کافی مناسب اور مفید معلوم ہوتا ہے۔ کام دراصل معمولی ہے - ریاست صرف انجکشن ہے عملدرآمد کے سیاق و سباق میں، اور Vue خود بخود اسے عالمی متغیر کے طور پر تیار کردہ ترتیب میں شامل کرتا ہے: window.__INITIAL_STATE__.

پیدا ہونے والے مسائل میں سے ایک سائیکلک ڈھانچے کو JSON میں تبدیل کرنے میں ناکامی ہے (سرکلر حوالہ); صرف اس طرح کے ڈھانچے کو ان کے فلیٹ ہم منصبوں سے تبدیل کرکے حل کیا گیا تھا۔

اس کے علاوہ، UGC مواد کے ساتھ کام کرتے وقت، آپ کو یاد رکھنا چاہیے کہ ڈیٹا کو HTML اداروں میں تبدیل کیا جانا چاہیے تاکہ HTML ٹوٹ نہ جائے۔ ان مقاصد کے لیے ہم استعمال کرتے ہیں۔ he.

دوبارہ ڈراز کو کم سے کم کرنا

جیسا کہ آپ اوپر دیے گئے خاکے سے دیکھ سکتے ہیں، ہمارے معاملے میں، ایک نوڈ JS مثال دو افعال انجام دیتا ہے: API میں SSR اور "proxy"، جہاں صارف کی اجازت ہوتی ہے۔ یہ صورت حال اجازت دینا ناممکن بناتی ہے جب JS کوڈ سرور پر چل رہا ہو، کیونکہ نوڈ سنگل تھریڈڈ ہے، اور SSR فنکشن مطابقت پذیر ہے۔ یعنی، سرور صرف اپنے آپ کو درخواستیں نہیں بھیج سکتا جب کہ کال اسٹیک کسی چیز میں مصروف ہو۔ یہ پتہ چلا کہ ہم نے ریاست کو اپ ڈیٹ کیا، لیکن انٹرفیس نے مروڑنا بند نہیں کیا، کیونکہ صارف کے سیشن کو مدنظر رکھتے ہوئے کلائنٹ کے ڈیٹا کو اپ ڈیٹ کرنا پڑتا ہے۔ ہمیں صارف کے لاگ ان کو مدنظر رکھتے ہوئے اپنی درخواست کو ابتدائی حالت میں درست ڈیٹا ڈالنا سکھانے کی ضرورت تھی۔

مسئلے کے صرف دو ہی حل تھے:

• کراس سرور کی درخواستوں کے ساتھ اجازت کا ڈیٹا منسلک کریں۔
• نوڈ جے ایس پرتوں کو دو الگ الگ مثالوں میں تقسیم کریں۔

پہلے حل کے لیے سرور پر عالمی متغیرات کے استعمال کی ضرورت تھی، اور دوسرے نے کام کو مکمل کرنے کی آخری تاریخ کو کم از کم ایک ماہ تک بڑھا دیا۔

انتخاب کیسے کریں؟ حبر اکثر کم سے کم مزاحمت کے راستے پر چلتا ہے۔ غیر رسمی طور پر، خیال سے پروٹو ٹائپ تک سائیکل کو کم سے کم کرنے کی عمومی خواہش ہے۔ پروڈکٹ کے تئیں رویہ کا ماڈل کسی حد تک booking.com کی پوسٹولیٹس کی یاد دلاتا ہے، فرق صرف اتنا ہے کہ Habr صارف کے تاثرات کو بہت زیادہ سنجیدگی سے لیتا ہے اور ایک ڈویلپر کے طور پر، ایسے فیصلے کرنے کے لیے آپ پر بھروسہ کرتا ہے۔

اس منطق اور مسئلہ کو جلد حل کرنے کی میری اپنی خواہش کے بعد، میں نے عالمی متغیرات کا انتخاب کیا۔ اور، جیسا کہ اکثر ہوتا ہے، آپ کو جلد یا بدیر ان کے لیے ادائیگی کرنی ہوگی۔ ہم نے تقریبا فوری طور پر ادائیگی کی: ہم نے ہفتے کے آخر میں کام کیا، نتائج کو صاف کیا، لکھا پوسٹ مارٹم اور سرور کو دو حصوں میں تقسیم کرنا شروع کر دیا۔ غلطی بہت احمقانہ تھی، اور اس میں شامل بگ کو دوبارہ پیدا کرنا آسان نہیں تھا۔ اور ہاں، یہ اس کے لیے شرم کی بات ہے، لیکن ایک یا دوسرے طریقے سے، ٹھوکریں کھاتے ہوئے اور کراہتے ہوئے، عالمی متغیرات کے ساتھ میرا PoC اس کے باوجود پروڈکشن میں چلا گیا اور نئے "ٹو نوڈ" فن تعمیر میں منتقل ہونے کا انتظار کرتے ہوئے کافی کامیابی سے کام کر رہا ہے۔ یہ ایک اہم قدم تھا، کیونکہ باضابطہ طور پر مقصد حاصل کر لیا گیا تھا - SSR نے مکمل طور پر استعمال کے لیے تیار صفحہ فراہم کرنا سیکھ لیا، اور UI کافی پرسکون ہو گیا۔

ریفیکٹرنگ کے پہلے مرحلے کے بعد موبائل ہیبر انٹرفیس

بالآخر، موبائل ورژن کا SSR-CSR فن تعمیر اس تصویر کی طرف لے جاتا ہے:

"دو نوڈ" SSR-CSR سرکٹ۔ نوڈ جے ایس API ہمیشہ غیر مطابقت پذیر I/O کے لیے تیار ہوتا ہے اور اسے SSR فنکشن کے ذریعے بلاک نہیں کیا جاتا ہے، کیونکہ مؤخر الذکر ایک الگ مثال میں واقع ہے۔ سوال سلسلہ نمبر 3 کی ضرورت نہیں ہے۔

ڈپلیکیٹ درخواستوں کو ختم کرنا

ہیرا پھیری کے انجام دینے کے بعد، صفحہ کی ابتدائی رینڈرنگ نے مرگی کو ابھارا نہیں۔ لیکن SPA موڈ میں Habr کے مزید استعمال نے اب بھی الجھن پیدا کی۔

چونکہ صارف کے بہاؤ کی بنیاد فارم کی منتقلی ہے۔ مضامین کی فہرست → مضمون → تبصرے۔ اور اس کے برعکس، اس سلسلہ کے وسائل کی کھپت کو پہلے جگہ پر بہتر بنانا ضروری تھا۔

پوسٹ فیڈ پر واپس آنا ایک نئی ڈیٹا کی درخواست کو بھڑکاتا ہے۔

گہری کھدائی کی ضرورت نہیں تھی۔ اوپر دیے گئے اسکرین کاسٹ میں آپ دیکھ سکتے ہیں کہ ایپلیکیشن واپس سوائپ کرنے پر مضامین کی فہرست کی دوبارہ درخواست کرتی ہے، اور درخواست کے دوران ہمیں مضامین نظر نہیں آتے، جس کا مطلب ہے کہ پچھلا ڈیٹا کہیں غائب ہو جاتا ہے۔ ایسا لگتا ہے کہ مضمون کی فہرست کا جزو مقامی ریاست کا استعمال کرتا ہے اور اسے تباہ کرنے پر کھو دیتا ہے۔ درحقیقت، ایپلی کیشن نے ایک عالمی ریاست کا استعمال کیا، لیکن Vuex فن تعمیر کو سر جوڑ کر بنایا گیا تھا: ماڈیول صفحات سے بندھے ہوئے ہیں، جو بدلے میں راستوں سے بندھے ہوئے ہیں۔ مزید برآں، تمام ماڈیولز "ڈسپوزایبل" ہیں - صفحہ پر آنے والے ہر بعد میں پورے ماڈیول کو دوبارہ لکھا جاتا ہے:

ArticlesList: [
  { Article1 },
  ...
],
PageArticle: { ArticleFull1 },

مجموعی طور پر، ہمارے پاس ایک ماڈیول تھا۔ مضامین کی فہرست، جس میں قسم کی اشیاء شامل ہیں۔ آرٹیکل اور ماڈیول صفحہ کا مضمون، جو آبجیکٹ کا ایک توسیعی ورژن تھا۔ آرٹیکل، اس قسم کی آرٹیکل مکمل. مجموعی طور پر، یہ عمل اپنے آپ میں کوئی خوفناک چیز نہیں رکھتا ہے - یہ بہت آسان ہے، کوئی بولی بھی کہہ سکتا ہے، لیکن انتہائی قابل فہم ہے۔ اگر آپ جب بھی راستہ تبدیل کرتے ہیں تو آپ ماڈیول کو دوبارہ ترتیب دیتے ہیں، تو آپ اس کے ساتھ رہ سکتے ہیں۔ تاہم، مثال کے طور پر آرٹیکل فیڈز کے درمیان منتقل ہونا /فیڈ → /تمام، ذاتی فیڈ سے متعلق ہر چیز کو پھینک دینے کی ضمانت ہے، کیونکہ ہمارے پاس صرف ایک ہے۔ مضامین کی فہرست، جس میں آپ کو نیا ڈیٹا ڈالنے کی ضرورت ہے۔ یہ ہمیں دوبارہ درخواستوں کی نقل کی طرف لے جاتا ہے۔

وہ سب کچھ جمع کرنے کے بعد جو میں اس موضوع پر کھودنے کے قابل تھا، میں نے ایک نیا ریاستی ڈھانچہ تیار کیا اور اسے اپنے ساتھیوں کے سامنے پیش کیا۔ بات چیت طویل تھی، لیکن آخر میں حق میں دلائل شکوک و شبہات سے بڑھ گئے، اور میں نے عمل درآمد شروع کیا۔

حل کی منطق دو مراحل میں بہترین طور پر ظاہر ہوتی ہے۔ پہلے ہم صفحات سے Vuex ماڈیول کو ڈیکپل کرنے کی کوشش کرتے ہیں اور راستوں سے براہ راست منسلک ہوتے ہیں۔ ہاں، اسٹور میں تھوڑا اور ڈیٹا ہوگا، حاصل کرنے والے کچھ زیادہ پیچیدہ ہوجائیں گے، لیکن ہم مضامین کو دو بار لوڈ نہیں کریں گے۔ موبائل ورژن کے لیے، یہ شاید سب سے مضبوط دلیل ہے۔ یہ کچھ اس طرح نظر آئے گا:

ArticlesList: {
  ROUTE_FEED: [ 
    { Article1 },
    ...
  ],
  ROUTE_ALL: [ 
    { Article2 },
    ...
  ],
}

لیکن کیا ہوگا اگر مضمون کی فہرستیں متعدد راستوں کے درمیان اوورلیپ ہوسکتی ہیں اور اگر ہم آبجیکٹ ڈیٹا کو دوبارہ استعمال کرنا چاہتے ہیں۔ آرٹیکل پوسٹ پیج کو رینڈر کرنے کے لیے، اس میں تبدیل کرنا آرٹیکل مکمل? اس صورت میں، اس طرح کے ڈھانچے کو استعمال کرنا زیادہ منطقی ہوگا:

ArticlesIds: {
  ROUTE_FEED: [ '1', ... ],
  ROUTE_ALL: [ '1', '2', ... ],
},
ArticlesList: {
  '1': { Article1 }, 
  '2': { Article2 },
  ...
}

مضامین کی فہرست یہاں یہ صرف ایک قسم کے مضامین کا ذخیرہ ہے۔ وہ تمام مضامین جو صارف کے سیشن کے دوران ڈاؤن لوڈ کیے گئے تھے۔ ہم ان کے ساتھ انتہائی احتیاط سے پیش آتے ہیں، کیونکہ یہ وہ ٹریفک ہے جو شاید میٹرو میں کہیں اسٹیشنوں کے درمیان درد کی وجہ سے ڈاؤن لوڈ کی گئی ہو، اور ہم یقینی طور پر صارف کو دوبارہ اس تکلیف کا باعث نہیں بننا چاہتے کہ اس کے پاس پہلے سے موجود ڈیٹا لوڈ کرنے پر مجبور ہو جائے۔ ڈاؤن لوڈ ایک چیز آرٹیکلز اشیاء کی صرف IDs کی ایک صف ہے (گویا "لنک") آرٹیکل. یہ ڈھانچہ آپ کو راستوں میں عام ڈیٹا کو نقل کرنے اور آبجیکٹ کو دوبارہ استعمال کرنے سے بچنے کی اجازت دیتا ہے۔ آرٹیکل اس میں توسیع شدہ ڈیٹا کو ضم کرکے پوسٹ پیج کو رینڈر کرتے وقت۔

مضامین کی فہرست کا آؤٹ پٹ بھی زیادہ شفاف ہو گیا ہے: تکرار کرنے والا جزو آرٹیکل آئی ڈی کے ساتھ صف میں اعادہ کرتا ہے اور آئی ڈی کو ایک سہارے کے طور پر پاس کرتے ہوئے آرٹیکل ٹیزر جزو کو کھینچتا ہے، اور چائلڈ کمپوننٹ، بدلے میں، ضروری ڈیٹا حاصل کرتا ہے۔ مضامین کی فہرست. جب آپ اشاعت کے صفحہ پر جاتے ہیں، تو ہمیں پہلے سے موجود تاریخ مل جاتی ہے۔ مضامین کی فہرست، ہم گمشدہ ڈیٹا کو حاصل کرنے اور اسے موجودہ آبجیکٹ میں شامل کرنے کی درخواست کرتے ہیں۔

یہ نقطہ نظر کیوں بہتر ہے؟ جیسا کہ میں نے اوپر لکھا ہے، یہ طریقہ ڈاؤن لوڈ کردہ ڈیٹا کے حوالے سے زیادہ نرم ہے اور آپ کو اسے دوبارہ استعمال کرنے کی اجازت دیتا ہے۔ لیکن اس کے علاوہ، یہ کچھ نئے امکانات کا راستہ کھولتا ہے جو اس طرح کے فن تعمیر میں بالکل فٹ بیٹھتے ہیں۔ مثال کے طور پر، پولنگ اور مضامین کو فیڈ میں لوڈ کرنا جیسے ہی وہ ظاہر ہوتے ہیں۔ ہم تازہ ترین پوسٹس کو "اسٹوریج" میں آسانی سے رکھ سکتے ہیں مضامین کی فہرستمیں نئی ​​IDs کی ایک الگ فہرست محفوظ کریں۔ آرٹیکلز اور صارف کو اس کے بارے میں مطلع کریں۔ جب ہم "نئی پبلیکیشنز دکھائیں" کے بٹن پر کلک کرتے ہیں، تو ہم مضامین کی موجودہ فہرست کے آغاز میں آسانی سے نئی آئی ڈیز ڈالیں گے اور ہر چیز تقریباً جادوئی انداز میں کام کرے گی۔

ڈاؤن لوڈ کو مزید پرلطف بنانا

ریفیکٹرنگ کیک پر آئسنگ کنکال کا تصور ہے، جو سست انٹرنیٹ پر مواد ڈاؤن لوڈ کرنے کے عمل کو تھوڑا کم مکروہ بناتا ہے۔ اس معاملے پر کوئی بات چیت نہیں ہوئی؛ آئیڈیا سے پروٹو ٹائپ تک کے راستے میں لفظی طور پر دو گھنٹے لگے۔ ڈیزائن نے عملی طور پر اپنی طرف متوجہ کیا، اور ہم نے ڈیٹا کا انتظار کرتے ہوئے اپنے اجزاء کو سادہ، بمشکل ٹمٹماتے div بلاکس کو پیش کرنا سکھایا۔ موضوعی طور پر، لوڈنگ کا یہ طریقہ دراصل صارف کے جسم میں تناؤ کے ہارمونز کی مقدار کو کم کرتا ہے۔ کنکال اس طرح لگتا ہے:

ہیبرا لوڈنگ

عکاسی کرنا

میں چھ ماہ سے Habré میں کام کر رہا ہوں اور میرے دوست اب بھی پوچھتے ہیں: اچھا، آپ کو وہاں کیسا لگا؟ ٹھیک ہے، آرام دہ - جی ہاں. لیکن کچھ ایسا ہے جو اس کام کو دوسروں سے مختلف بناتا ہے۔ میں نے ان ٹیموں میں کام کیا جو اپنی پروڈکٹ سے مکمل طور پر لاتعلق تھیں، انہیں یہ معلوم نہیں تھا کہ ان کے صارفین کون ہیں۔ لیکن یہاں سب کچھ مختلف ہے۔ یہاں آپ اپنے کام کے لیے ذمہ دار محسوس کرتے ہیں۔ کسی خصوصیت کو تیار کرنے کے عمل میں، آپ جزوی طور پر اس کے مالک بن جاتے ہیں، اپنی فعالیت سے متعلق تمام پروڈکٹ میٹنگز میں حصہ لیتے ہیں، تجاویز دیتے ہیں اور خود فیصلے کرتے ہیں۔ ایک ایسی پروڈکٹ بنانا جسے آپ ہر روز استعمال کرتے ہیں خود بہت اچھا ہے، لیکن ان لوگوں کے لیے کوڈ لکھنا جو شاید آپ سے بہتر ہیں یہ صرف ایک ناقابل یقین احساس ہے (کوئی طنز نہیں)۔

ان تمام تبدیلیوں کی رہائی کے بعد، ہمیں مثبت رائے ملی، اور یہ بہت، بہت اچھا تھا۔ یہ متاثر کن ہے۔ شکریہ! مزید لکھیں۔

میں آپ کو یاد دلاتا ہوں کہ عالمی متغیرات کے بعد ہم نے فن تعمیر کو تبدیل کرنے اور پراکسی پرت کو ایک الگ مثال میں مختص کرنے کا فیصلہ کیا۔ "دو نوڈ" فن تعمیر پہلے ہی عوامی بیٹا ٹیسٹنگ کی شکل میں ریلیز تک پہنچ چکا ہے۔ اب کوئی بھی اس پر سوئچ کر سکتا ہے اور موبائل Habr کو بہتر بنانے میں ہماری مدد کر سکتا ہے۔ آج کیلئے بس اتنا ہی. مجھے تبصرے میں آپ کے تمام سوالات کے جوابات دینے میں خوشی ہوگی۔

ماخذ: www.habr.com