DIY: كيف صنعنا جدولًا حيًا لبرنامج Codefest X

في نهاية شهر مارس في نوفوسيبيرسك ، توفي CodeFest الذكرى 10. مثل أي مؤتمر ، على الأرجح ، ترك CodeFestX للمشاركين مجموعة من الانطباعات المختلفة من "ساقي لم تعد هنا" إلى "كيفية شراء اشتراك مدى الحياة؟". لن أصف كيف كان الحال ، فهناك بالفعل مراجعات ، وأعتقد أنها ستظل تظهر. أريد أن أشارك قصة كيف أطلقنا نسخة بديلة لجدول Codefest ( شاهد أفضل من هاتف محمول ): من الفكرة إلى النتيجة.



فكرة


لقد حضرت Codefest منذ عام 2010 ، وكان هذا العام مؤتمري التاسع. بالنسبة لي ، Codefest هو تقليد ، وهذه المرة أردت أن أفعل شيئًا مفيدًا. قبل الحدث ، عند قراءة محادثة المؤتمر ، أدركت أن الجدول الزمني أمر يمكن تحسينه بالتأكيد. Codefest هو حدث حافل بالأحداث يرغب فيه الجميع في الحصول على أقصى استفادة منه ، لذلك قررت المساعدة في إنشاء جدول مخصص بديل.

الأهداف كانت كما يلي:

  • للزوار - لإعطاء الفرصة للحصول على مزيد من المعلومات ذات الصلة حول الأحداث الجارية وتشكيل تغذية المصالح الخاصة بهم. بالإضافة إلى ذلك ، أتيحت لجميع زوار المؤتمر الفرصة للحضور إلى جناحنا وتقديم أي ميزة مفقودة أو إصلاح الخلل ؛
  • بالنسبة إلى Codefest ، هذه قناة إضافية لتوزيع برنامج "شعبي" ؛
  • بالنسبة لنا ، كشركة ، هذا بالطبع هو إضافة إضافية في علامة تجارية صاحب العمل.




جاء مفهوم "ضخ ما يزيد" على جدول منظمي Codefest. شاركت الفكرة في Wrike ووجدت أشخاصًا متشابهين في التفكير على استعداد للاتصال. لقد بدأنا بالبحث ونظرنا في مواقع المؤتمرات والتطبيقات المحمولة. بشكل عام ، أطلقنا عملية البقالة المعتادة في Wrike.

نتيجة للعمل المتراكم ، قررنا أن الوظائف اللازمة ضرورية مثل هذا:

  • جدول المؤتمر الرئيسي مع القدرة على تصفية التقارير والبحث.
  • المفضلة والإشعارات حول نهج الأحداث المختارة ؛
  • برنامج شائع له نفس الوظيفة كبرنامج رئيسي ، بالإضافة إلى فرصة للشركاء والناشطين لإضافة أحداث إلى هذا البرنامج.

كانت هناك مهام ذات أولوية أقل:

  • مناقشات حول التقرير بحيث يمكن للمستخدمين المصرح لهم تبادل الآراء ومناقشتها ؛
  • الإعجابات وتقارير التقييم الشائعة ؛
  • الخريطة ، كما CodeFest رائع والتنقل مهم جدًا.

لا تزال هناك مهام ذات الأولوية الثالثة ، حيث لا يزال لدينا مجموعة من سفن الفضاء مدفونة ، لكنني أعتقد أن وقتهم سيأتي.

تطبيق


قررنا أن نأخذ ما نستخدمه في تطوير منتجاتنا كمكدس للمشروع ، لإعطاء فرصة لنرى كيف تم بناء الواجهة الأمامية في Wrike. نكتب على دارت ( وقد أخبرنا بالفعل لماذا: هنا و هنا ) و في الوقت الحالي لمشاريع الويب الكبيرة مثل مشروعنا ، لا يوجد سوى الزاوي ( هنا 5 دقائق من الإلهام من bunopus ). يمكن العثور على مستودع مشروعنا هنا github.com/wrike/codefestx .

في تطبيقنا الزاوي ، أضفنا Redux . هناك عدة تطبيقات لـ Dart: أخذنا Redux.dart و Redux Epics للتأثيرات. في مشروعنا ، يوجد الرمز المتعلق بـ Redux هنا github.com/wrike/codefestx/tree/master/lib/src/redux .

للعمل مع حالة غير قابلة للتغيير ، اتخذنا الحزم build_value و build_collection ، والتي تعمل على تبسيط العمل بشكل جيد. على سبيل المثال ، نقوم بإنشاء فصل لحالة تطبيقنا - CodefestState ، وتُنشئ الحزم أداة إنشاء.
يتم استخدام خدعة بسيطة للتواصل مع Angular و Redux ( في المكون الرئيسي - github.com/wrike/codefestx/blob/master/lib/app_component.dart ):


ونحن نربطهم معا من خلال gart Stream القياسية:

_dispatcher.onAction.listen((action) => _store.dispatch(action)),
_store.onChange.listen((_) => _zone.run(_cdr.markForCheck)),

أي عندما تنشئ إجراءً في المدير ( جميعها هنا ) ، فإنها تدخل في مستودع Redux. تتم معالجتها والحالة تتغير ، مما يؤدي إلى دورة من الكشف الزاوي التغيير.
لقد صنعنا 2 آليات لإرسال الإخطارات: للإخطارات بحدوث أحداث ، لأن هذا مهم ، ومتكامل مع PushWoosh وتلقى دفعة نظام ( لسوء الحظ دون دعم المتصفحات على iOS ). بالنسبة للأحداث الأقل أهمية ، على سبيل المثال ، تم إصدار نسخة جديدة ، وتم رفع مأخذ التوصيل ، وتم استخدام socket_io_client على العميل.



بشكل عام ، بنية التطبيق بسيطة وفي رأيي مفهومة. إذا كانت لديك أسئلة ، فيمكننا مناقشة حلول محددة في التعليقات أو على جيثب.

البنية التحتية


في العالم الحديث ، لتحميل ملف JS للاستخدام العام ، لا غنى عن k8s . ولكن على محمل الجد ، فإن إحدى ميزات خدمتنا هي المراجعة الصحيحة في المؤتمر نفسه ( والتي استفاد منها العديد من Dartizans من بين الزوار ولا ، فهي ليست من Wrike :) ).



لذلك ، قررنا أن نجعل CI صادقة. نظرنا في فرص التكامل التي وجدها GitHub ووجدنا Google Cloud Build هناك : بما أننا نستخدم منتجات Google ، فلا ينبغي لنا أن نترك هذا المسار. يعمل التكامل مثل هذا: أي التزام بالمستودع يستدعي تجميع cloudbuild.yaml . لقد سلكنا المسار الذي نقوم بتجميع حاوية Docker به تطبيق جاهز ( يوجد قالب محور للثبة - hub.docker.com/r/google/dart ) ، ثم نطلقها في k8s حتى نتمكن من استعادة الإصدارات ، وتوسيع نطاق الإصدارات الافتراضية الأخرى الوضع. من بين ما لم يكن خارج الصندوق ، كانت القدرة على القيام بسلوك مختلف اعتمادًا على الفرع الذي نرتكب فيه ، أي أن يبني المعلم وينتشر في المعركة ، وبالنسبة للفروع الباقية ، ينبغي تنفيذ خطوات قليلة دون K8s. هناك مناقشة نشطة لهذا الموضوع هنا ، واستفدنا من الحل من هذه المناقشة. عملت CI تماما وفشلت أبدا.

يطير في مرهم


بالإضافة إلى نجاحاتنا ، بالطبع ، هناك شيء يمكن القيام به بشكل مختلف. على سبيل المثال ، لا تجبر الأشخاص على تسجيل الدخول عند التصويت للتقارير - فالبعض لا يعجبهم ( خاصة في الخدمات قصيرة الأجل ). نتيجةً لذلك ، لم نحصل على "إعجابات" كثيرة جدًا للتقارير ، لكن مع ذلك ، هنأنا أبطال المتحدثين.



نحن أيضًا في شجاعة تطوير الويب نسيان القيود الصارمة لنظام iOS ، وأنه لا توجد طريقة للقيام بالدفع من أجل الويب . اتضح أن ما يقرب من نصف مستخدمي خدمتنا كانوا مع iPhone. لسوء الحظ ، لم نتمكن من إرسال إشعار لهم.
وما الذي أزعج الفريق ، كما ذكرت بالفعل ، - لم نتمكن من القيام بكل خططنا. تم طرح بعض الوظائف مباشرة في المؤتمر ، ولا يزال البعض في حالة تراكم.

النتائج


شكراً للمنظمين على إضافة رابط الجدول إلى مذكرة المشارك في المؤتمر. خلال المؤتمر ، استخدم أكثر من 1100 مستخدم الخدمة. إلى البرنامج الرئيسي للأحداث ~ 120 ، أضفنا ~ 50 الشعبية الأخرى. حوالي 75٪ من الجلسات كانت على الأجهزة المحمولة ، أرسلنا أكثر من 500 إخطارات بالدفع ، وأصدرنا 3 إصدارات خلال المؤتمر نفسه ، وحصلنا على الكثير من المتعة من العملية والنتيجة.



لقد كانت تجربة رائعة ، وسوف نستمر في تطوير المشروع ، على الأقل للمناسبات الداخلية ومؤتمرات Wrike. إذا كنت قد ذهبت إلى Codefest واستخدمت جدولنا الزمني ، فإننا نرحب بتعليقاتك في التعليقات.

Source: https://habr.com/ru/post/ar448610/


All Articles