كيف ولماذا فزنا في مسار البيانات الكبيرة في Urban Tech Challenge Hackathon

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

لذا ، أولاً ، بعض الملاحظات العامة.

1. من المدهش أن عددًا قليلاً من الناس يعتقدون بسذاجة أن لعبة الاختراق هي نوع من المنافسة الرياضية حيث يفوز أفضل المبرمجين. هذا ليس كذلك. لا أفكر في الحالات التي لا يعرف فيها منظمو hackathon أنفسهم ما يريدون (رأيت هذا أيضًا). ولكن ، كقاعدة عامة ، فإن الشركة التي ترتب الاختراق تسعى لتحقيق أهدافها. يمكن أن تكون قائمتهم مختلفة: يمكن أن تكون حلاً تقنيًا لبعض المشكلات ، والبحث عن أفكار وأشخاص جدد ، إلخ. غالبًا ما تحدد هذه الأهداف تنسيق الحدث وتوقيته واتصاله بالإنترنت / دون اتصال بالإنترنت ، وكيف سيتم صياغة المهام (وما إذا كانت ستتم صياغتها على الإطلاق) ، وما إذا كان سيتم مراجعة الكود على hackathon ، إلخ. يتم تقييم كل من الفريق وما فعلوه بدقة من وجهة النظر هذه. وتنتصر تلك الفرق التي تصل إلى النقطة التي تحتاجها الشركة على أفضل وجه ، والكثير منها يصل إلى هذه النقطة بشكل غير واعي وغير مقصود ، معتقدين أنهم يشاركون حقًا في المنافسة الرياضية. تظهر ملاحظاتي أنه لتحفيز المشاركين ، ينبغي على المنظمين خلق مظهر على الأقل لبيئة رياضية وظروف متساوية ، وإلا سيحصلون على موجة من السلبية ، كما في المراجعة أعلاه. لكننا ضلنا.

2. ومن هنا الاستنتاج التالي. يهتم المنظمون بالمشاركين القادمين إلى hackathon بأفكارهم الخاصة ، وأحيانًا يتم ترتيب مرحلة المراسلات عبر الإنترنت خصيصًا لهذا الغرض. وهذا يسمح لحلول الإخراج أقوى. إن مفهوم "عملهم" نسبي للغاية ، حيث يمكن لأي مبرمج متمرس أن يجمع آلاف أسطر الكود من مشاريعه القديمة في الالتزام الأول. وسوف يكون وقت التشغيل المعدة مسبقا؟ ولكن على أي حال ، تنطبق القاعدة ، التي أعربت عنها في شكل ميم الشهيرة:



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

3. اختيار الفريق. كما لاحظت من دردشات hackathon ، فإن الكثير من الناس يأخذون هذه المسألة على محمل الجد (على الرغم من أن هذا هو أهم قرار سيحدد نتائجك في hackathon). في العديد من مجالات النشاط (سواء في الألعاب الرياضية أو الاختراقات) ، رأيت أن الأشخاص الأقوياء يميلون إلى الاتحاد مع الأقوياء ، والضعفاء ذوي العيوب الضعيفة ، والأذكياء مع الأفراد الأذكياء ، حسناً ، بشكل عام ، أنت تفهم ... هذا ما يحدث في غرف الدردشة: أكثر أو أقل مبرمجين أقوياء على الفور ، يتعطل الأشخاص الذين ليس لديهم أي مهارات ذات قيمة كبيرة في الدردشة لفترة طويلة ويختارون فريقًا على أساس مبدأ أن شخصًا ما يأخذها. في بعض الاختراقات ، يتم ممارسة التوزيع العشوائي بين الفرق ، ويدعي المنظمون أن الفرق العشوائية تظهر أن النتيجة ليست أسوأ من الفرق الموجودة بالفعل. لكن وفقًا لملاحظاتي ، يجد الأشخاص المتحمسون ، كقاعدة عامة ، الفريق نفسه ، إذا كان يجب توزيع شخص ما ، فغالبًا ما لا يأتي كثير منهم إلى الهاكاتون.

أما بالنسبة لتكوين الفريق ، فهو فردي للغاية ويعتمد بدرجة كبيرة على المهمة. أستطيع أن أقول إن الحد الأدنى من الفريق القابل للحياة هو مصمم - الواجهة الأمامية أو الأمامية - الخلفية. لكنني أعرف أيضًا حالات عندما فازت الفرق المؤلفة فقط من الدعم الأمامي ، والتي أرفقت خلفية بسيطة بـ node.js ، أو قدمت تطبيقًا للهاتف المحمول على React Native ؛ أو فقط من المتسولين الذين قاموا بتصميم بسيط. بشكل عام ، كل شيء فردي للغاية ويعتمد على المهمة. كانت خطتي لاختيار فريق للاختراق هي كما يلي: كنت أخطط لتجميع فريق أو الانضمام لفريق مثل مصمم الواجهة الأمامية (أنا أمامي بنفسي). وسرعان ما بدأ الدردشة مع خلفية بيثون ومصمم قبل الدعوة للانضمام إلينا. بعد ذلك بقليل ، انضمت إلينا فتاة محللة أعمال ، والتي كانت لديها بالفعل خبرة في الفوز بالهاكاثون ، وهذا قرر مسألة انضمامها إلينا. بعد اجتماع قصير ، قررنا أن نسمي أنفسنا U4 (URBAN 4 ، وأربعة مدن) مماثلة لأربعة رائعة. وقد وضعوا صورة مماثلة على قناة التلغراف لدينا.

4. اختيار المهمة. كما قلت ، يجب أن يكون لديك ميزة تنافسية ، يتم اختيار مهمة hackathon على هذا الأساس. بناءً على ذلك ، بعد الاطلاع على قائمة المهام وتقييم تعقيدها ، توصلنا إلى مهمتين: فهرس للمؤسسات المبتكرة من DPiIR وروبوت دردشة من EFKO. تم اختيار المهمة من معهد التنمية الصناعية والصناعية من قبل backender ، تم اختيار المهمة من EFKO بواسطتي ، لأن كانت تجربة كتابة chatbots على node.js و DialogFlow. تضمنت مهمة EFKO أيضًا ML ، لديّ خبرة ، وليس كبيرة جدًا ، في ML. ووفقًا لظروف المشكلة ، بدا لي أنه لم يتم حلها عن طريق ML. تعزز هذا الشعور عندما ذهبت إلى اجتماع Urban Tech Challenge ، حيث أطلعني المنظمون على مجموعة بيانات EFCO ، حيث كان هناك حوالي 100 صورة لتخطيطات المنتجات (مأخوذة من زوايا مختلفة) وحوالي 20 فئة من أخطاء التخطيط. وفي الوقت نفسه ، أراد عملاء المهمة معدل نجاح تصنيف بنسبة 90 ٪. كنتيجة لذلك ، قمت بإعداد العرض التقديمي للحل دون ML ، أعد المؤيد العرض التقديمي وفقًا للكتالوج ، وبعد الانتهاء من العروض التقديمية ، أرسلناها إلى Urban Tech Challenge. بالفعل في هذه المرحلة ، تم الكشف عن مستوى الدافع والمساهمة لكل مشارك. لم يشارك مصممنا في المناقشات ، وأجاب في وقت متأخر ، بل وملأ معلومات عن نفسه في العرض التقديمي في اللحظة الأخيرة ، وبصورة عامة نشأت شكوك.

ونتيجة لذلك ، تابعنا المهمة من قسم البناء والتصميم ، ولم نكن مستاء على الإطلاق لأننا لم نذهب من خلال EFKO ، لأن المهمة بدت لنا ، بعبارة ملطفة وغريبة.

5. التحضير للاختراق. عندما أصبح معروفًا أخيرًا أننا ذهبنا إلى hackathon ، بدأنا في إعداد الشغل. وهنا لا أحثك ​​على البدء في كتابة الكود قبل أسبوع من بدء الاختراق. كحد أدنى ، يجب أن يكون لديك صفيحة جاهزة ، والتي يمكنك من خلالها العمل فورًا دون الحاجة إلى ضبط الأدوات ، وبدون اصطدامها بأخطاء من أي نوع تقرر تجربتها للمرة الأولى على hackathon. أعرف قصة عن الصيادين الذين جاؤوا إلى hackathon وأمضوا يومين في إعداد مجموعة المشروع ، لذلك يجب إعداد كل شيء مسبقًا. من المفترض أن نوزع الواجبات كما يلي: يكتب bekender برامج الزحف التي تفحص الإنترنت وتضع كل المعلومات التي تم جمعها في قاعدة البيانات ، أكتب واجهة برمجة التطبيقات على node.js ، التي تطلب قاعدة البيانات هذه وترسل البيانات إلى المقدمة. في هذا الصدد ، أعددت الخادم مقدمًا على Express.js ، وأعددت الواجهة الأمامية للرد. لا أستخدم CRA ، فأنا دائمًا ما أقوم بتخصيص حزمة الويب لنفسي وأعلم جيدًا المخاطر التي قد تترتب على ذلك (نتذكر قصة الصيادون). في هذه اللحظة ، طلبت فراغات الواجهة ، أو على الأقل نماذج بالحجم الطبيعي من مصممنا ، من أجل الحصول على فكرة عما سأفرضه. من الناحية النظرية ، يجب عليه أيضًا أن يتخذ استعداداته وينسقها معنا ، لكنني لم أتلق إجابة أبدًا. نتيجة لذلك ، اقترضت التصميم من أحد أعمالي القديمة. وهكذا بدأت تتحول بشكل أسرع ، لأن جميع أنماط هذا المشروع كانت مكتوبة بالفعل. ومن هنا الاستنتاج: المصمم ليس مطلوبًا دائمًا في الفريق))). مع هذه التطورات ، وصلنا إلى hackathon.

6. العمل على hackathon. رأيت أول مرة فريقي يعيش فقط عند افتتاح hackathon في CDP. التقينا وناقشنا الحل ومراحل العمل في المهمة. وعلى الرغم من أننا بعد الافتتاح ، استقلنا حافلات إلى Red October ، فقد عدنا إلى المنزل للنوم ، بعد أن وافقنا على القدوم إلى مكاننا بحلول الساعة 9.00. لماذا؟ أراد المنظمون ، على ما يبدو ، الضغط على معظم المشاركين ، لذا قاموا بترتيب مثل هذا الجدول الزمني. ولكن ، في تجربتي ، يمكنك عادةً أن ترمز دون أن تنام ليلة واحدة. بالنسبة للثاني ، لست متأكداً بعد الآن. Hackathon هو سباق الماراثون ، تحتاج إلى حساب وتخطيط قوتك بشكل كاف. وعلاوة على ذلك ، كان لدينا الفراغات.



لذلك ، بعد النوم ، في الساعة 9.00 ، كنا نجلس في الطابق السادس من الديوانية. ثم أعلن مصممنا بشكل غير متوقع أنه ليس لديه جهاز كمبيوتر محمول وأنه سيعمل من المنزل ، وسوف نتواصل عبر الهاتف. كان هذا القشة الأخيرة. وهكذا تحولنا من أربعة إلى ثلاثة ، رغم أننا لم نغير اسم الفريق. مرة أخرى ، لم تصبح هذه ضربة قوية لنا ، لقد كان لدي بالفعل تصميم من المشروع القديم. بشكل عام ، في البداية سار كل شيء بسلاسة ووفقًا للخطة. لقد قمنا بتحميل مجموعة بيانات من الشركات المبتكرة من المنظمين في قاعدة البيانات (قررنا استخدام neo4j). بدأت في التنضيد ، ثم أخذت node.js ، ثم اختفت. لم أعمل مطلقًا مع neo4j من قبل ، وبحثت أولاً عن برنامج تشغيل عامل لقاعدة البيانات هذه ، ثم اكتشفت كيف يتم كتابة الاستعلام ، ثم تفاجأت عندما وجدت أن قاعدة البيانات هذه تُرجع الكيانات عند الطلب ، كصفيف لكائنات العقدة وحوافها. أي عندما طلبت المؤسسة من قبل TIN وجميع البيانات الموجودة عليها ، بدلاً من كائن مؤسسة واحد ، قمت بإرجاع مجموعة طويلة من الكائنات التي تحتوي على بيانات في هذه المؤسسة والعلاقة بينها. كتبت معينًا يجتاز الصفيف بأكمله ولصق جميع الكائنات في المؤسسة في كائن واحد. لكن في المعركة ، عند الاستعلام عن قاعدة بيانات تضم 8000 منظمة ، كانت بطيئة للغاية لمدة تتراوح بين 20 و 30 ثانية. فكرت في التحسين ... ثم توقفنا في الوقت المناسب وانتقلنا إلى MongoDB ، واستغرق الأمر حوالي 30 دقيقة. ضاعت حوالي 5 ساعات على neo4j.

تذكر ، لا تستخدم تقنية hackathon التي لا تعرفها ، فقد تكون هناك مفاجآت. ولكن ، بشكل عام ، وبصرف النظر عن هذا الفشل ، كل شيء سار وفقا للخطة. وبالفعل في صباح يوم 9 ديسمبر كان لدينا تطبيق يعمل بشكل كامل. بالنسبة لبقية اليوم ، خططنا لتصفية ميزات إضافية عليه. في المستقبل ، سارت الأمور على نحو سلس نسبيًا ، لكن واجه bekender مجموعة كبيرة من المشكلات فيما يتعلق بحظر برامج الزحف الخاصة به في محركات البحث ، في رسائل البريد العشوائي التي تم تجميعها من الكيانات القانونية ، والتي جاءت في الأماكن الأولى لنتائج البحث عند طلب كل شركة محددة. ولكن عن هذا سوف يقول أفضل. الميزة الإضافية الأولى التي قمت بها هي البحث بالاسم الكامل الرئيس التنفيذي فكونتاكتي. استغرق الأمر عدة ساعات.

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

7. العرض. من تجربتي الخاصة أستطيع أن أقول أنه يجب عليك التبديل إلى إعداد عرض تقديمي في مكان ما قبل 3-4 ساعات من تسليمه. خاصة إذا كان من المفترض أن يكون الفيديو موجودًا فيه ، فإن التقاط الصور وتحريره يستغرق الكثير من الوقت. كان من المفترض أن يكون لدينا فيديو. وكان لدينا شخص مميز شارك في هذا ، وحل أيضًا عددًا من المشكلات التنظيمية الأخرى. في هذا الصدد ، حتى اللحظة الأخيرة ، لم نكن نشغل الانتباه عن الترميز.

8. الملعب. لم تعجبني العروض التقديمية والنهائية التي تم تقديمها في يوم منفصل من أيام الأسبوع (الاثنين). هنا ، على الأرجح ، واصل المنظمون سياسة الضغط على أقصى المشاركين. لم أكن أخطط لأخذ إجازة من العمل ، أردت أن أحضر فقط إلى النهائيات ، على الرغم من أن بقية فريقي استغرق عطلة نهاية الأسبوع. ومع ذلك ، كان الانغماس العاطفي في hackathon مرتفعًا بالفعل لدرجة أنني في الساعة الثامنة صباحًا كتبت إلى الدردشة مع فريقي (العمل ، وليس فريق hackathon) الذي قضيته في اليوم على نفقتي الخاصة وذهبت إلى مركز السيطرة على الأمراض (CDC). تحولت مشكلتنا إلى الكثير من بيانات العلماء الخالصة ، مما أثر بشكل كبير على النهج المتبع لحل المشكلة. كان لدى الكثير منهم DS جيد ، لكن لم يكن لدى أي شخص نموذج أولي عملي ، فالكثيرون لم يتمكنوا من تجنب برامج الزحف الخاصة بهم في محركات البحث. كنا الفريق الوحيد مع نموذج العمل. وكنا نعرف كيفية حل المهمة. في النهاية ، فزنا بالمسار ، على الرغم من أننا كنا محظوظين للغاية لأننا اخترنا المهمة الأقل تنافسية. بالنظر إلى الملاعب في مسارات أخرى ، أدركنا أنه لن تكون لدينا فرصة هناك. أريد أيضًا أن أقول إننا كنا محظوظين جدًا مع هيئة المحلفين ، فقد قاموا بالتحقق من الرمز بدقة. واستنادا إلى الاستعراضات ، كان هذا أبعد ما يكون عن الحدوث على جميع المسارات.

9. النهائي. بعد أن تم استدعائنا إلى هيئة المحلفين عدة مرات لمراجعة الكود ، اعتقدنا أننا قد حللنا أخيرًا كل المشكلات وتناولنا العشاء في برغر كينج. هناك ، اتصل بنا المنظمون مرة أخرى ، وكان علينا أن نتعجل في تعبئة الطلبات والعودة.

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

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



وفي الختام ، شكراً تقليدياً لجميع الذين ساندونا ، وهيئة المحلفين في مسارنا ، Evgeny Evgrafiev (مؤلف المهمة التي قمنا بحلها في hackathon) ، وبالطبع ، منظمو hackathon. ربما كان هذا هو أكبر وأروع الهاكاثون الذي شاركت فيه جميعًا ، يبقى فقط أن تتمنى اللاعبين الحفاظ على هذه العلامة التجارية العالية والمزيد!

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


All Articles