איך ולמה זכינו במסלול Big Data בהאקתון Urban Tech Challenge

שמי דמיטרי. ואני רוצה לדבר על איך הצוות שלנו הגיע לגמר של ההאקתון Urban Tech Challenge במסלול Big Data. אני אגיד מיד שזה לא ההאקתון הראשון בו השתתפתי, ולא הראשון בו לקחתי פרסים. בהקשר זה, בסיפור שלי אני רוצה להשמיע כמה תצפיות ומסקנות כלליות לגבי תעשיית ההאקתונים בכללותה, ולתת את נקודת המבט שלי בניגוד לביקורות השליליות שהופיעו באינטרנט מיד לאחר סיום אתגר האורבן טק (עבור דוגמא זה).

אז קודם כל כמה תצפיות כלליות.

1. זה מפתיע שלא מעט אנשים חושבים בתמימות שהאקתון הוא סוג של תחרות ספורט שבה מיטב הקודנים מנצחים. זה לא נכון. אני לא מתחשב במקרים שבהם מארגני ההאקתון עצמם לא יודעים מה הם רוצים (גם אני ראיתי את זה). אבל, ככלל, החברה המארגנת האקתון חותרת למטרות שלה. הרשימה שלהם עשויה להיות שונה: זה יכול להיות פתרון טכני לבעיות מסוימות, חיפוש אחר רעיונות ואנשים חדשים וכו'. יעדים אלו קובעים פעמים רבות את מתכונת האירוע, העיתוי שלו, אונליין/אופליין, כיצד יגובשו המשימות (והאם הן יגובשו בכלל), האם תתקיים סקירת קוד בהאקתון וכו'. גם הצוותים וגם מה שהם עשו מוערכים מנקודת מבט זו. ואותן קבוצות שהכי פוגעות בנקודה שהחברה צריכה מנצחות, ורבים מגיעים לנקודה הזו לגמרי לא במודע ובמקרה, במחשבה שהן באמת משתתפות בתחרות ספורט. התצפיות שלי מראות שכדי להניע את המשתתפים, על המארגנים ליצור לפחות מראה של סביבה ספורטיבית ותנאים שווים, אחרת הם יקבלו גל שליליות, כמו בסקירה לעיל. אבל אנחנו מתרחקים.

2. מכאן המסקנה הבאה. המארגנים מעוניינים שהמשתתפים יגיעו להאקתון עם עבודות משלהם, לעיתים אף מארגנים במיוחד שלב התכתבות מקוון לצורך כך. זה מאפשר פתרונות פלט חזקים יותר. המושג "עבודה משלו" הוא מושג מאוד יחסי; כל מפתח מנוסה יכול לצבור אלפי שורות קוד מהפרויקטים הישנים שלו בהתחייבות הראשונה שלו. והאם זה יהיה פיתוח מוכן מראש? אבל בכל מקרה, חל הכלל, אותו הבעתי בצורת מם מפורסם:

כדי לזכות צריך שיהיה לכם משהו, איזשהו יתרון תחרותי: פרויקט דומה שעשיתם בעבר, ידע וניסיון בנושא ספציפי או עבודה מוכנה שנעשתה לפני תחילת ההאקתון. כן, זה לא ספורט. כן, זה אולי לא שווה את המאמץ שהושקע (כאן, כל אחד מחליט בעצמו אם כדאי לקודד במשך 3 שבועות בלילה עבור פרס של 100 אלף, המחולק בין כל הצוות, ואפילו עם הסיכון לא לקבל אותו). אבל, לעתים קרובות, זו ההזדמנות היחידה להתקדם.

3. בחירת צוות. כפי ששמתי לב בצ'אטים בהאקתון, רבים ניגשים לנושא הזה בצורה קלת דעת (למרות שזו ההחלטה החשובה ביותר שתקבע את התוצאה שלך בהאקתון). בהרבה תחומי פעילות (גם בספורט וגם בהאקתונים) ראיתי שאנשים חזקים נוטים להתאחד עם החזקים, החלשים עם החלשים, החכמים עם החכמים, ובכן, בכלל, הבנתם את הרעיון... זה בערך מה שקורה בצ'אטים: מתכנתים פחות חזקים הם נחטפים מיד, אנשים שאין להם כישורים יקרי ערך להאקתון מסתובבים בצ'אט הרבה זמן ובוחרים צוות לפי העיקרון שאם רק מישהו היה לוקח את זה . בחלק מהאקתונים מתרגלים הקצאה אקראית לצוותים, והמארגנים טוענים שצוותים אקראיים לא מתפקדים גרועים יותר מאלה הקיימים. אבל לפי התצפיות שלי, אנשים חדורי מוטיבציה, ככלל, מוצאים צוות בעצמם; אם צריך להקצות מישהו, אז, לעתים קרובות, רבים מהם לא מגיעים להאקתון.

לגבי הרכב הצוות, זה מאוד אינדיבידואלי ותלוי מאוד במשימה. אני יכול לומר שהרכב הצוות המינימלי בר-קיימא הוא מעצב - קצה קדמי או קצה קדמי - אחורי. אבל אני גם מכיר מקרים שבהם ניצחו צוותים שהורכבו רק מפרונטים, שהוסיפו קצה אחורי פשוט ב-node.js, או יצרו אפליקציה לנייד ב-React Native; או רק מאחורים שעשו פריסה פשוטה. באופן כללי, הכל מאוד אינדיבידואלי ותלוי במשימה. התוכנית שלי לבחירת צוות להאקתון הייתה כדלקמן: תכננתי להרכיב צוות או להצטרף לצוות כמו front-end - back-end - designer (אני בעצמי פרונט-אנד). ודי מהר התחלתי לשוחח עם אחורי פיתון ומעצבת שקיבלה את ההזמנה להצטרף אלינו. קצת אחר כך הצטרפה אלינו בחורה, אנליסטית עסקית, שכבר התנסתה בזכייה בהאקתון, וזה הכריע את סוגיית הצטרפותה. לאחר פגישה קצרה, החלטנו לקרוא לעצמנו U4 (URBAN 4, עירוני ארבע) באנלוגיה לארבעה הפנטסטית. והם אפילו שמו תמונה מתאימה על האווטאר של ערוץ הטלגרם שלנו.

4. בחירת משימה. כפי שכבר אמרתי, חייב להיות לך יתרון תחרותי, המשימה להאקתון נבחרת על סמך זה. על סמך זה, לאחר שהסתכלתי רשימת מטלות ובהערכת המורכבות שלהם, התמקמנו על שתי משימות: קטלוג של ארגונים חדשניים מ-DPiIR וצ'אט-בוט מ-EFKO. המשימה מ-DPIiR נבחרה על ידי ה-backender, המשימה מ-EFKO נבחרה על ידי, כי היה בעל ניסיון בכתיבת צ'אטבוטים ב-node.js וב-DialogFlow. משימת EFKO כללה גם ML; יש לי ניסיון מסוים, לא מאוד נרחב, ב-ML. ולפי תנאי הבעיה, נראה לי שלא סביר שהיא תיפתר באמצעות כלי ML. התחושה הזו התחזקה כשהלכתי למפגש Urban Tech Challenge, שבו המארגנים הראו לי מערך נתונים על EFKO, שבו היו כ-100 תמונות של פריסות מוצרים (שצולמו מזוויות שונות) וכ-20 מחלקות של שגיאות פריסה. ובמקביל, מי שהזמין את המשימה רצה להגיע לשיעור הצלחה בסיווג של 90%. כתוצאה מכך הכנתי מצגת של הפתרון ללא ML, ה-backender הכין מצגת על בסיס הקטלוג, וביחד לאחר סיום המצגות שלחנו אותן ל-Urban Tech Challenge. כבר בשלב זה נחשפה רמת המוטיבציה והתרומה של כל משתתף. המעצב שלנו לא השתתף בדיונים, הגיב באיחור, ואפילו מילא מידע על עצמו במצגת ממש ברגע האחרון, בכלל התעוררו ספקות.

כתוצאה מכך עברנו את המשימה מ-DPiIR, ובכלל לא התעצבנו מכך שלא עברנו את ה-EFKO, שכן המשימה נראתה לנו מוזרה, בלשון המעטה.

5. הכנה להאקתון. כשסוף סוף נודע שהעפלנו להאקתון, התחלנו להכין את ההכנה. וכאן אני לא תומך להתחיל לכתוב קוד שבוע לפני תחילת ההאקתון. לכל הפחות, אתה צריך להיות מוכן, איתו אתה יכול להתחיל לעבוד מיד, בלי להגדיר כלים, ובלי להיתקל בבאגים של איזה ליב שהחלטת לנסות בפעם הראשונה בהאקתון. אני מכיר סיפור על מהנדסים זוויתיים שהגיעו להאקתון ובילו יומיים בהקמת הפרויקט, אז הכל צריך להיות מוכן מראש. התכוונו לחלק את האחריות באופן הבא: ה-backender כותב סורקים שסורקים את האינטרנט ומכניסים את כל המידע שנאסף לבסיס הנתונים, בעוד שאני כותב API ב-node.js שמבצע שאילתות למסד הנתונים הזה ושולח את הנתונים לחזית. בהקשר זה, הכנתי שרת מראש באמצעות express.js והכנתי חזית קצה ב-react. אני לא משתמש ב-CRA, אני תמיד מתאימה לעצמי webpack ואני יודע היטב אילו סיכונים זה יכול להוות (זכור את הסיפור על מפתחים זוויתיים). בשלב זה ביקשתי תבניות ממשק או לפחות דגמים מהמעצב שלנו כדי שיהיה לי מושג מה אני אפתח. בתיאוריה הוא צריך גם לעשות את ההכנות שלו ולתאם איתנו, אבל מעולם לא קיבלתי תשובה. כתוצאה מכך, השאלתי את העיצוב מאחד הפרויקטים הישנים שלי. וזה התחיל להסתדר אפילו מהר יותר, מכיוון שכל הסגנונות לפרויקט הזה כבר נכתבו. מכאן המסקנה: לא תמיד צריך מעצב בצוות))). הגענו להאקתון עם הפיתוחים האלה.

6. עבודה בהאקתון. הפעם הראשונה שראיתי את הצוות שלי בשידור חי הייתה רק בפתיחת ההאקתון במרכז ההפצה המרכזי. נפגשנו, שוחחנו על הפתרון ושלבי העבודה על הבעיה. ולמרות שאחרי הפתיחה היינו צריכים לנסוע באוטובוס לאוקטובר האדום, חזרנו הביתה לישון, הסכמנו להגיע למקום עד 9.00. למה? המארגנים כנראה רצו להפיק את המרב מהמשתתפים, אז הם ארגנו בדיוק לוח זמנים כזה. אבל, מניסיוני, אתה יכול לקודד כרגיל בלי לישון לילה אחד. לגבי השני, אני כבר לא בטוח. האקתון הוא מרתון; אתה צריך לחשב כראוי ולתכנן את הכוח שלך. יתר על כן, היו לנו הכנות.

לכן, לאחר שינה, בשעה 9.00 ישבנו בקומה השישית של Dewocracy. ואז המעצב שלנו הודיע ​​במפתיע שאין לו מחשב נייד ושהוא יעבוד מהבית, ואנחנו נתקשר בטלפון. זה היה הקש האחרון. וכך הפכנו מארבע לשלוש, למרות שלא שינינו את שם הקבוצה. שוב, זו לא הייתה מכה גדולה עבורנו; כבר היה לי את העיצוב מהפרויקט הישן. באופן כללי, בהתחלה הכל הלך די חלק ובהתאם לתוכנית. העמסנו למסד הנתונים (החלטנו להשתמש ב-neo4j) מערך נתונים של חברות חדשניות מהמארגנים. התחלתי להגדיר כתיבה, ואז לקחתי את node.js, ואז דברים התחילו לפעול לא נכון. מעולם לא עבדתי עם neo4j לפני כן, ובהתחלה חיפשתי דרייבר עובד למסד הנתונים הזה, ואז הבנתי איך כותבים שאילתה, ואז הופתעתי לגלות שבסיס הנתונים הזה, כשנשאלים אותו, מחזיר ישויות ב- צורה של מערך של אובייקטי צומת והקצוות שלהם. הָהֵן. כאשר ביקשתי ארגון ואת כל הנתונים עליו על ידי TIN, במקום אובייקט ארגון אחד, הוחזרו לי מערך ארוך של אובייקטים המכילים נתונים על הארגון הזה והקשרים ביניהם. כתבתי ממפה שעבר את כל המערך והדבקתי את כל האובייקטים לפי הארגון שלהם לאובייקט אחד. אבל בקרב, כשביקשו מסד נתונים של 8 ארגונים, זה בוצע באיטיות רבה, בערך 20 - 30 שניות. התחלתי לחשוב על אופטימיזציה... ואז עצרנו בזמן ועברנו ל-MongoDB, וזה לקח לנו בערך 30 דקות. בסך הכל אבדו כ-4 שעות ב-neo5j.

זכרו, לעולם אל תיקחו טכנולוגיה להאקתון שאינכם מכירים, עלולות להיות הפתעות. אבל, באופן כללי, מלבד הכישלון הזה, הכל הלך לפי התוכנית. וכבר בבוקר ה-9 בדצמבר הייתה לנו אפליקציה עובדת במלואה. בשאר היום תכננו להוסיף לו פיצ'רים נוספים. בעתיד, הכל הלך לי יחסית חלק, אבל למאחורי היו המון בעיות עם איסור הסורקים שלו במנועי חיפוש, בספאם של אגרגטורים של ישויות משפטיות, שהגיעו למקומות הראשונים של תוצאות החיפוש בעת בקשה. לכל חברה ספציפית. אבל עדיף לו לספר על זה בעצמו. התכונה הנוספת הראשונה שהוספתי הייתה חיפוש לפי שם מלא. המנהל הכללי של VKontakte. זה לקח כמה שעות.

אז בדף החברה באפליקציה שלנו, הופיע דמות של המנהל הכללי, קישור לדף VKontakte שלו ועוד כמה נתונים. זה היה דובדבן נחמד על העוגה, למרות שזה אולי לא העניק לנו את הניצחון. לאחר מכן, רציתי להפעיל קצת ניתוחים. אבל לאחר חיפוש ארוך של אפשרויות (היו הרבה ניואנסים עם ממשק המשתמש), התפשרתי על הצבירה הפשוטה ביותר של ארגונים לפי קוד פעילות כלכלית. כבר בערב, בשעות האחרונות, הנחתי תבנית להצגת מוצרים חדשניים (באפליקציה שלנו אמור להיות מדור מוצרים ושירותים), אם כי ה-backend לא היה מוכן לכך. במקביל, בסיס הנתונים התנפח בצעדי ענק, הסורקים המשיכו לעבוד, המגן האחורי התנסה ב-NLP כדי להבחין בין טקסטים חדשניים לבין לא חדשניים))). אבל הזמן למצגת הסופית כבר התקרב.

7. מצגת. מניסיוני, אני יכול לומר שכדאי לעבור להכנת מצגת כ-3 עד 4 שעות לפני מועדה. במיוחד אם זה כולל וידאו, הצילום והעריכה שלו לוקחים די הרבה זמן. היינו אמורים לקבל סרטון. והיה לנו אדם מיוחד שעסק בזה, וגם פתר עוד מספר בעיות ארגוניות. בהקשר זה, לא הסחנו את עצמנו מקידוד עד הרגע האחרון ממש.

8. מגרש. לא אהבתי שהמצגות והגמרים נערכו ביום חול נפרד (שני). כאן, ככל הנראה, נמשכה מדיניות המארגנים לסחוט את המקסימום מהמשתתפים. לא תכננתי לקחת חופש מהעבודה, רציתי רק להגיע לגמר, למרות ששאר הצוות שלי לקחו את היום. עם זאת, השקיעה הרגשית בהאקתון כבר הייתה כל כך גבוהה שבשעה 8 בבוקר כתבתי בצ'אט של הצוות שלי (צוות העבודה, לא צוות ההאקתון) שאני לוקח את היום על חשבוני, והלכתי למרכז משרד למגרשים. לבעיה שלנו התברר שיש הרבה מדעני נתונים טהורים, וזה השפיע מאוד על הגישה לפתרון הבעיה. לרבים היה DS טוב, אבל לאף אחד לא היה אב טיפוס עובד, רבים לא יכלו לעקוף את האיסורים של הסורקים שלהם במנועי חיפוש. היינו הצוות היחיד עם אב טיפוס עובד. וידענו איך לפתור את הבעיה. בסופו של דבר זכינו במסלול, למרות שהיה לנו מזל גדול שבחרנו במשימה הכי פחות תחרותית. כשמסתכלים על המגרשים במסלולים אחרים, הבנו שלא יהיה לנו סיכוי שם. אני גם רוצה לומר שהיה לנו מזל גדול עם חבר המושבעים; הם בדקו בקפדנות את הקוד. ואם לשפוט לפי הביקורות, זה לא קרה בכל המסלולים.

9. גמר. לאחר שנקראנו כמה פעמים לחבר המושבעים לבדיקת קוד, חשבנו שסוף סוף פתרנו את כל הבעיות, הלכנו לאכול ארוחת צהריים בבורגר קינג. שם המארגנים התקשרו אלינו שוב, היינו צריכים לארוז במהירות את ההזמנות ולחזור.

המארגן הראה לנו לאיזה חדר אנחנו צריכים להיכנס, וכשנכנסנו מצאנו את עצמנו באימון דיבור בפני הקבוצות הזוכות. החבר'ה שהיו אמורים להופיע על הבמה היו טעונים היטב, כולם יצאו כמו שואומנים אמיתיים.

ואני חייב להודות שבגמר, על רקע הקבוצות החזקות ממסלולים אחרים, נראינו חיוורים; הניצחון במועמדות הלקוחות הממשלתית הגיע בצדק לצוות מהמסלול הטכנולוגי בתחום הנדל"ן. אני חושב שהגורמים המרכזיים שתרמו לניצחון שלנו על המסלול היו: זמינות של ריק מוכן, שבגללו הצלחנו ליצור במהירות אב טיפוס, נוכחות של "היילייטס" באב הטיפוס (חיפוש מנכ"לים ברשתות חברתיות) וכישורי ה-NLP של ה-backender שלנו, שגם הם עניינו מאוד את חבר המושבעים.

ולסיכום, תודה מסורתית לכל אלה שתמכו בנו, חבר השופטים של המסלול שלנו, יבגני אבגרפיייב (מחבר הבעיה שפתרנו בהאקתון) וכמובן מארגני ההאקתון. זה היה אולי ההאקתון הגדול והמגניב ביותר שהשתתפתי בו אי פעם, אני יכול רק לאחל לחבר'ה לשמור על רמה כזו גבוהה בעתיד!

מקור: www.habr.com