اسمي ديمتري. وأريد أن أتحدث عن كيفية وصول فريقنا إلى نهائيات هاكاثون Urban Tech Challenge على مسار البيانات الضخمة. سأقول على الفور أن هذا ليس الهاكاثون الأول الذي شاركت فيه، وليس الأول الذي أحصل فيه على جوائز. وفي هذا الصدد، أريد في قصتي أن أعبر عن بعض الملاحظات والاستنتاجات العامة فيما يتعلق بصناعة الهاكاثون ككل، وأن أبدي وجهة نظري في مقابل المراجعات السلبية التي ظهرت عبر الإنترنت مباشرة بعد انتهاء تحدي Urban Tech Challenge (لـ مثال ).
لذلك أولا بعض الملاحظات العامة.
1. من المثير للدهشة أن عددًا لا بأس به من الناس يعتقدون بسذاجة أن الهاكاثون هو نوع من المنافسة الرياضية التي يفوز فيها أفضل المبرمجين. هذا خطأ. أنا لا أفكر في الحالات التي لا يعرف فيها منظمو الهاكاثون أنفسهم ما يريدون (لقد رأيت ذلك أيضًا). ولكن، كقاعدة عامة، تسعى الشركة التي تنظم Hackathon إلى تحقيق أهدافها الخاصة. قد تكون قائمتهم مختلفة: يمكن أن تكون حلاً تقنيًا لبعض المشكلات، أو البحث عن أفكار وأشخاص جدد، وما إلى ذلك. غالبًا ما تحدد هذه الأهداف شكل الحدث، وتوقيته، سواء كان متصلاً أو غير متصل بالإنترنت، وكيفية صياغة المهام (وما إذا كان سيتم صياغتها على الإطلاق)، وما إذا كانت ستكون هناك مراجعة للكود في الهاكاثون، وما إلى ذلك. يتم تقييم كل من الفريقين وما فعلوه من وجهة النظر هذه. وتلك الفرق التي تصل إلى النقطة التي تحتاجها الشركة بشكل أفضل هي التي تفوز، ويصل الكثيرون إلى هذه النقطة دون وعي تمامًا وبالصدفة، معتقدين أنهم يشاركون حقًا في مسابقة رياضية. تظهر ملاحظاتي أنه من أجل تحفيز المشاركين، يجب على المنظمين خلق مظهر بيئة رياضية وظروف متساوية على الأقل، وإلا فسوف يتلقون موجة من السلبية، كما في المراجعة أعلاه. لكننا نستطرد.
2. ومن هنا الاستنتاج التالي. يهتم المنظمون بالمشاركين الذين يأتون إلى الهاكاثون بأعمالهم الخاصة، وفي بعض الأحيان يقومون بتنظيم مرحلة مراسلة عبر الإنترنت خصيصًا لهذا الغرض. وهذا يسمح بحلول إخراج أقوى. إن مفهوم "العمل الخاص" هو مفهوم نسبي للغاية؛ يمكن لأي مطور ذي خبرة أن يجمع آلاف الأسطر من التعليمات البرمجية من مشاريعه القديمة في التزامه الأول. وهل سيكون هذا تطوراً معداً مسبقاً؟ لكن على كل حال تنطبق القاعدة التي عبرت عنها في صورة ميم مشهورة:
للفوز، يجب أن يكون لديك شيء ما، نوع من الميزة التنافسية: مشروع مماثل قمت به في الماضي، أو معرفة وخبرة في موضوع معين، أو عمل جاهز تم إنجازه قبل بدء الهاكاثون. نعم، انها ليست رياضية. نعم، قد لا يستحق هذا الجهد المبذول (هنا، يقرر الجميع بأنفسهم ما إذا كان الأمر يستحق البرمجة لمدة 3 أسابيع ليلاً للحصول على جائزة قدرها 100 ألف، مقسمة على الفريق بأكمله، وحتى مع مخاطر عدم الحصول عليها). ولكن، في كثير من الأحيان، هذه هي الفرصة الوحيدة للمضي قدما.
3. اختيار الفريق. كما لاحظت في محادثات الهاكاثون، يتعامل الكثيرون مع هذه المشكلة بشكل تافه تمامًا (على الرغم من أن هذا هو القرار الأكثر أهمية الذي سيحدد نتيجتك في الهاكاثون). في العديد من مجالات النشاط (سواء في الرياضة أو في الهاكاثون) رأيت أن الأشخاص الأقوياء يميلون إلى الاتحاد مع الأقوياء، والضعفاء مع الضعفاء، والأذكياء مع الأذكياء، حسنًا، بشكل عام، لقد فهمت الفكرة... هذا ما يحدث تقريبًا في الدردشات: يتم الاستيلاء على المبرمجين الأقل قوة على الفور، والأشخاص الذين ليس لديهم أي مهارات ذات قيمة للهاكاثون يبقون في الدردشة لفترة طويلة ويختارون فريقًا على مبدأ أنه إذا قبل شخص ما ذلك فقط . في بعض الهاكاثونات، يتم ممارسة التعيين العشوائي للفرق، ويدعي المنظمون أن أداء الفرق العشوائية ليس أسوأ من أداء الفرق الموجودة. ولكن وفقا لملاحظاتي، فإن الأشخاص المتحمسين، كقاعدة عامة، يجدون فريقا بمفردهم، إذا كان لا بد من تعيين شخص ما، فغالبا ما لا يأتي الكثير منهم إلى Hackathon.
أما بالنسبة لتكوين الفريق فهو فردي للغاية ويعتمد بشكل كبير على المهمة. أستطيع أن أقول إن الحد الأدنى من تكوين الفريق القابل للحياة هو المصمم - الواجهة الأمامية أو الواجهة الأمامية - الخلفية. لكنني أعرف أيضًا حالات فازت فيها فرق مكونة فقط من الواجهات الأمامية، والتي أضافت واجهة خلفية بسيطة في Node.js، أو أنشأت تطبيقًا للهاتف المحمول في React Native؛ أو فقط من الداعمين الذين قاموا بتصميم بسيط. بشكل عام، كل شيء فردي للغاية ويعتمد على المهمة. كانت خطتي لاختيار فريق للهاكاثون كما يلي: خططت لتجميع فريق أو الانضمام إلى فريق مثل مصمم الواجهة الأمامية - الواجهة الخلفية - المصمم (أنا نفسي مصمم الواجهة الأمامية). وسرعان ما بدأت الدردشة مع أحد داعمي لغة بايثون ومصمم قبل الدعوة للانضمام إلينا. بعد ذلك بقليل، انضمت إلينا فتاة، محللة أعمال، لديها بالفعل خبرة في الفوز في هاكاثون، وهذا ما حسم مسألة انضمامها إلينا. بعد اجتماع قصير، قررنا أن نطلق على أنفسنا اسم U4 (URBAN 4، Urban Four) قياسًا على Fantastic Four. وقد قاموا حتى بوضع الصورة المقابلة على الصورة الرمزية لقناة التليجرام الخاصة بنا.
4. اختيار مهمة. كما قلت من قبل، يجب أن يكون لديك ميزة تنافسية، ويتم تحديد مهمة الهاكاثون بناءً على ذلك. وعلى هذا فقد نظر ولتقييم مدى تعقيدها، توصلنا إلى مهمتين: كتالوج المؤسسات المبتكرة من DPiIR وروبوت الدردشة من EFKO. تم اختيار المهمة من DPIiR بواسطة الجهة الخلفية، وتم اختيار المهمة من EFKO بواسطتي، لأنه كان لديه خبرة في كتابة برامج الدردشة الآلية في Node.js وDialogFlow. تتضمن مهمة EFKO أيضًا تعلم الآلة؛ ولدي بعض الخبرة، ليست واسعة جدًا، في تعلم الآلة. ووفقًا لظروف المشكلة، بدا لي أنه من غير المرجح أن يتم حلها باستخدام أدوات ML. وقد تعزز هذا الشعور عندما ذهبت إلى لقاء Urban Tech Challenge، حيث أظهر لي المنظمون مجموعة بيانات عن EFKO، حيث كان هناك حوالي 100 صورة لتخطيطات المنتج (مأخوذة من زوايا مختلفة) وحوالي 20 فئة من أخطاء التخطيط. وفي الوقت نفسه، أراد أولئك الذين أمروا بالمهمة تحقيق نسبة نجاح في التصنيف تبلغ 90%. ونتيجة لذلك، قمت بإعداد عرض تقديمي للحل بدون ML، وأعدت الجهة الخلفية عرضًا تقديميًا بناءً على الكتالوج، ومعًا، بعد الانتهاء من العروض التقديمية، أرسلناهم إلى Urban Tech Challenge. بالفعل في هذه المرحلة، تم الكشف عن مستوى الدافع ومساهمة كل مشارك. لم يشارك مصممنا في المناقشات، وأجاب متأخرا، وحتى ملأ معلومات عن نفسه في العرض التقديمي في اللحظة الأخيرة، بشكل عام، نشأت الشكوك.
نتيجة لذلك، مررنا بالمهمة من DPiIR، ولم نكن مستاءين على الإطلاق لأننا لم نجتاز EFKO، حيث بدت المهمة غريبة بالنسبة لنا، بعبارة ملطفة.
5. التحضير للهاكاثون. عندما أصبح معروفًا أخيرًا أننا تأهلنا للهاكاثون، بدأنا في التحضير. وأنا هنا لا أؤيد البدء في كتابة التعليمات البرمجية قبل أسبوع من بدء الهاكاثون. كحد أدنى، يجب أن يكون لديك نموذج معياري جاهز، يمكنك من خلاله بدء العمل فورًا، دون الحاجة إلى تكوين الأدوات، ودون الاصطدام بأخطاء بعض libات التي قررت تجربتها لأول مرة في hackathon. أعرف قصة عن مهندسين زاوية حضروا إلى هاكاثون وأمضوا يومين في إعداد بناء المشروع، لذلك يجب إعداد كل شيء مسبقًا. أردنا توزيع المسؤوليات على النحو التالي: يقوم الخادم الخلفي بكتابة برامج الزحف التي تجوب الإنترنت وتضع جميع المعلومات المجمعة في قاعدة البيانات، بينما أكتب واجهة برمجة التطبيقات في Node.js التي تستعلم عن قاعدة البيانات هذه وترسل البيانات إلى المقدمة. في هذا الصدد، قمت بإعداد خادم مسبقًا باستخدام Express.js وأعدت واجهة أمامية للرد. أنا لا أستخدم CRA، فأنا أقوم دائمًا بتخصيص حزمة الويب لنفسي وأعرف جيدًا المخاطر التي يمكن أن يشكلها ذلك (تذكر قصة المطورين الزاويين). في هذه المرحلة، طلبت قوالب واجهة أو على الأقل نماذج بالحجم الطبيعي من مصممنا لكي يكون لدي فكرة عما سأقوم بتصميمه. من الناحية النظرية، يجب عليه أيضًا أن يقوم باستعداداته الخاصة وينسقها معنا، لكنني لم أتلق أي إجابة أبدًا. ونتيجة لذلك، قمت باستعارة التصميم من أحد مشاريعي القديمة. وبدأ العمل بشكل أسرع، حيث تمت كتابة جميع الأنماط لهذا المشروع بالفعل. ومن هنا الاستنتاج: ليس هناك حاجة دائمًا إلى المصمم في الفريق))). لقد جئنا إلى الهاكاثون بهذه التطورات.
6. العمل في الهاكاثون. المرة الأولى التي رأيت فيها فريقي على الهواء مباشرة كانت فقط في افتتاح الهاكاثون في مركز التوزيع المركزي. التقينا وناقشنا الحل ومراحل العمل على المشكلة. وعلى الرغم من أنه بعد الافتتاح كان علينا الذهاب بالحافلة إلى أكتوبر الأحمر، فقد عدنا إلى المنزل للنوم، ووافقنا على الوصول إلى المكان بحلول الساعة 9.00. لماذا؟ يبدو أن المنظمين أرادوا تحقيق أقصى استفادة من المشاركين، لذلك قاموا بترتيب مثل هذا الجدول الزمني. لكن، من خلال تجربتي، يمكنك البرمجة بشكل طبيعي دون النوم لليلة واحدة. أما بالنسبة للثانية، فلم أعد متأكدا. الهاكاثون هو ماراثون، عليك أن تحسب قوتك وتخطط لها بشكل مناسب. علاوة على ذلك، كانت لدينا الاستعدادات.
لذلك، بعد النوم، في الساعة 9.00 كنا نجلس في الطابق السادس من Dewocracy. ثم أعلن مصممنا بشكل غير متوقع أنه ليس لديه جهاز كمبيوتر محمول وأنه سيعمل من المنزل، وسوف نتواصل عبر الهاتف. وكانت هذه القشة الأخيرة. وهكذا تحولنا من أربعة إلى ثلاثة، على الرغم من أننا لم نغير اسم الفريق. مرة أخرى، لم تكن هذه ضربة كبيرة بالنسبة لنا، فقد حصلت بالفعل على التصميم من المشروع القديم. بشكل عام، في البداية سار كل شيء بسلاسة تامة ووفقًا للخطة. لقد قمنا بتحميل قاعدة البيانات (قررنا استخدام neo4j) مجموعة بيانات للشركات المبتكرة من المنظمين. لقد بدأت التنضيد، ثم استخدمت ملف Node.js، ثم بدأت الأمور تسوء. لم يسبق لي العمل مع neo4j من قبل، وفي البداية كنت أبحث عن برنامج تشغيل يعمل لقاعدة البيانات هذه، ثم اكتشفت كيفية كتابة استعلام، ثم تفاجأت عندما اكتشفت أن قاعدة البيانات هذه، عند الاستعلام عنها، تُرجع كيانات في شكل مجموعة من كائنات العقدة وحوافها. أولئك. عندما طلبت مؤسسة وجميع البيانات الموجودة عليها بواسطة TIN، بدلاً من كائن مؤسسة واحد، تم إرجاع مجموعة طويلة من الكائنات التي تحتوي على بيانات عن هذه المؤسسة والعلاقات بينها. لقد كتبت مخططًا مر عبر المصفوفة بأكملها وألصقت جميع الكائنات وفقًا لتنظيمها في كائن واحد. ولكن في المعركة، عند طلب قاعدة بيانات تضم 8 آلاف منظمة، تم تنفيذها ببطء شديد، حوالي 20 إلى 30 ثانية. بدأت أفكر في التحسين... ثم توقفنا في الوقت المناسب وانتقلنا إلى MongoDB، واستغرق الأمر منا حوالي 30 دقيقة. في المجموع، تم فقدان حوالي 4 ساعات على neo5j.
تذكر، لا تأخذ التكنولوجيا أبدًا إلى هاكاثون لا تعرفه، فقد تكون هناك مفاجآت. لكن بشكل عام، وبصرف النظر عن هذا الفشل، سار كل شيء حسب الخطة. وفي صباح يوم 9 ديسمبر، كان لدينا تطبيق يعمل بشكل كامل. لبقية اليوم خططنا لإضافة ميزات إضافية إليه. في المستقبل، سار كل شيء بسلاسة نسبيًا بالنسبة لي، لكن الخلفية واجهت مجموعة كاملة من المشكلات مع حظر برامج الزحف الخاصة بها في محركات البحث، في البريد العشوائي لمجمعات الكيانات القانونية، والتي جاءت في الأماكن الأولى لنتائج البحث عند الطلب لكل شركة محددة. ولكن من الأفضل له أن يتحدث عن ذلك بنفسه. الميزة الإضافية الأولى التي أضفتها كانت البحث بالاسم الكامل. المدير العام لفكونتاكتي. استغرق الأمر عدة ساعات.
لذلك، ظهرت على صفحة الشركة في تطبيقنا صورة رمزية للمدير العام، ورابط لصفحة فكونتاكتي الخاصة به وبعض البيانات الأخرى. لقد كانت بمثابة حبة كرز لطيفة على الكعكة، على الرغم من أنها ربما لم تمنحنا الفوز. ثم أردت إجراء بعض التحليلات. ولكن بعد بحث طويل في الخيارات (كان هناك العديد من الفروق الدقيقة في واجهة المستخدم)، استقرت على أبسط تجميع للمنظمات حسب رمز النشاط الاقتصادي. بالفعل في المساء، في الساعات الأخيرة، كنت أضع قالبًا لعرض المنتجات المبتكرة (في تطبيقنا من المفترض أن يكون هناك قسم للمنتجات والخدمات)، على الرغم من أن الواجهة الخلفية لم تكن جاهزة لذلك. في الوقت نفسه، كانت قاعدة البيانات تتضخم بسرعة فائقة، واستمرت برامج الزحف في العمل، وقام فريق الخلفية بتجربة البرمجة اللغوية العصبية لتمييز النصوص المبتكرة عن النصوص غير المبتكرة))). لكن وقت العرض النهائي كان يقترب بالفعل.
7. العرض. من تجربتي الخاصة، أستطيع أن أقول أنه يجب عليك التحول إلى إعداد العرض التقديمي قبل حوالي 3 إلى 4 ساعات من موعده. خاصة إذا كان الأمر يتعلق بالفيديو، فإن تصويره وتحريره يستغرق الكثير من الوقت. كان من المفترض أن يكون لدينا فيديو. وكان لدينا شخص مميز تعامل مع هذا الأمر، وقام أيضًا بحل عدد من المشكلات التنظيمية الأخرى. وفي هذا الصدد، لم نشغل أنفسنا عن البرمجة حتى اللحظة الأخيرة.
8. الملعب. لم يعجبني إقامة العروض التقديمية والنهائيات في يوم منفصل من أيام الأسبوع (الاثنين). هنا، على الأرجح، استمرت سياسة المنظمين المتمثلة في الضغط على الحد الأقصى من المشاركين. لم أخطط لأخذ إجازة من العمل، أردت فقط الوصول إلى النهائيات، على الرغم من أن بقية أعضاء فريقي حصلوا على إجازة. ومع ذلك، كان الانغماس العاطفي في الهاكاثون مرتفعًا بالفعل لدرجة أنه في الساعة الثامنة صباحًا كتبت في دردشة فريقي (فريق العمل، وليس فريق الهاكاثون) أنني كنت أقضي اليوم على نفقتي الخاصة، وذهبت إلى المركز المركزي مكتب للملاعب. تحولت مشكلتنا إلى الكثير من علماء البيانات النقية، وهذا أثر بشكل كبير على النهج المتبع في حل المشكلة. كان لدى الكثير منهم DS جيد، ولكن لم يكن لدى أحد نموذج أولي عملي، ولم يتمكن الكثيرون من التغلب على الحظر المفروض على برامج الزحف الخاصة بهم في محركات البحث. لقد كنا الفريق الوحيد الذي لديه نموذج أولي عملي. وعرفنا كيف نحل المشكلة. في النهاية، فزنا بالمسار، على الرغم من أننا كنا محظوظين للغاية لأننا اخترنا المهمة الأقل تنافسية. وبالنظر إلى الملاعب في المسارات الأخرى، أدركنا أنه لن تكون لدينا فرصة هناك. أريد أيضًا أن أقول إننا كنا محظوظين جدًا بهيئة المحلفين، فقد قاموا بفحص الكود بدقة. وإذا حكمنا من خلال المراجعات، فإن هذا لم يحدث في جميع المسارات.
9. نهائي. بعد أن تم استدعاؤنا عدة مرات إلى هيئة المحلفين لمراجعة الكود، اعتقدنا أننا قد حللنا جميع المشكلات أخيرًا، وذهبنا لتناول الغداء في برجر كنج. وهناك اتصل بنا المنظمون مرة أخرى، وكان علينا أن نحزم طلباتنا بسرعة ونعود.
أوضح لنا المنظم الغرفة التي يتعين علينا الدخول إليها، وعند الدخول وجدنا أنفسنا في جلسة تدريب على التحدث أمام الجمهور للفرق الفائزة. كان الرجال الذين كان من المفترض أن يؤدوا على خشبة المسرح مشحونين جيدًا، وخرج الجميع مثل رجال الاستعراض الحقيقيين.
ويجب أن أعترف، في المباراة النهائية، على خلفية أقوى الفرق من المسارات الأخرى، بدانا شاحبين، وكان الفوز في ترشيح العميل الحكومي بجدارة من نصيب الفريق من مسار التكنولوجيا العقارية. أعتقد أن العوامل الرئيسية التي ساهمت في انتصارنا على المسار هي: توفر الفراغ الجاهز، والذي بفضله تمكنا من صنع نموذج أولي بسرعة، ووجود "النقاط البارزة" في النموذج الأولي (البحث عن المديرين التنفيذيين على الشبكات الاجتماعية) ومهارات البرمجة اللغوية العصبية (NLP) الخاصة بنا، والتي أثارت اهتمام لجنة التحكيم بشكل كبير.
وفي الختام، الشكر التقليدي لكل من دعمنا، لجنة تحكيم مسارنا، إيفجيني إفغرافييف (مؤلف المشكلة التي قمنا بحلها في الهاكاثون) وبالطبع منظمي الهاكاثون. ربما كان هذا أكبر وأروع هاكاثون شاركت فيه على الإطلاق، ولا يسعني إلا أن أتمنى للرجال الحفاظ على هذا المستوى العالي في المستقبل!
المصدر: www.habr.com