اسم من دیمیتری است. و من می خواهم در مورد چگونگی رسیدن تیم ما به فینال هکاتون چالش فناوری شهری در مسیر Big Data صحبت کنم. فوراً می گویم که این اولین هکاتونی نیست که در آن شرکت کردم و اولین باری نیست که در آن جوایز را دریافت کردم. در این رابطه، در داستان خود می‌خواهم برخی از مشاهدات و نتیجه‌گیری‌های کلی را در مورد صنعت هکاتون به طور کلی بیان کنم و نقطه نظر خود را برخلاف نظرات منفی که بلافاصله پس از پایان چالش فناوری شهری (برای مثال ).
بنابراین ابتدا برخی از مشاهدات کلی.
1. تعجب آور است که تعداد کمی از مردم ساده لوحانه فکر می کنند که هکاتون نوعی مسابقه ورزشی است که در آن بهترین کدنویس ها برنده می شوند. این اشتباه است. من مواردی را در نظر نمی‌گیرم که خود سازمان‌دهندگان هکاتون نمی‌دانند چه می‌خواهند (من هم آن را دیده‌ام). اما، به عنوان یک قاعده، شرکتی که یک هکاتون را برگزار می کند، اهداف خود را دنبال می کند. لیست آنها ممکن است متفاوت باشد: می تواند یک راه حل فنی برای برخی مشکلات، جستجوی ایده ها و افراد جدید و غیره باشد. این اهداف اغلب فرمت رویداد، زمان آن، آنلاین/آفلاین، نحوه فرموله شدن وظایف (و اینکه آیا اصلاً فرموله خواهند شد)، آیا بازبینی کد در هکاتون و غیره تعیین می شود. هم تیم ها و هم کارهایی که انجام دادند از این منظر ارزیابی می شود. و آن دسته از تیم هایی که به بهترین وجه به نقطه مورد نیاز شرکت رسیدند برنده می شوند و بسیاری کاملاً ناخودآگاه و تصادفی به این نقطه می رسند و فکر می کنند که واقعاً در یک مسابقه ورزشی شرکت می کنند. مشاهدات من نشان می دهد که برای ایجاد انگیزه در شرکت کنندگان، برگزارکنندگان باید حداقل ظاهر یک محیط ورزشی و شرایط برابر را ایجاد کنند، در غیر این صورت مانند بررسی فوق موجی از منفی بافی را دریافت خواهند کرد. اما منحرف می شویم.
2. از این رو نتیجه گیری زیر است. برگزارکنندگان علاقه مند هستند که شرکت کنندگان با کار خود به هکاتون بیایند، گاهی اوقات حتی به طور ویژه یک مرحله مکاتبه آنلاین را برای این منظور سازماندهی می کنند. این به راه حل های خروجی قوی تر اجازه می دهد. مفهوم «کار خود» مفهومی بسیار نسبی است؛ هر توسعه‌دهنده با تجربه‌ای می‌تواند هزاران خط کد را از پروژه‌های قدیمی خود در اولین commit جمع‌آوری کند. و آیا این یک توسعه از پیش آماده شده خواهد بود؟ اما در هر صورت این قاعده صدق می کند که در قالب یک میم معروف بیان کردم:
برای برنده شدن، باید چیزی داشته باشید، نوعی مزیت رقابتی: پروژه مشابهی که در گذشته انجام داده اید، دانش و تجربه در یک موضوع خاص، یا کار آماده ای که قبل از شروع هکاتون انجام شده است. بله، ورزشی نیست. بله، این ممکن است ارزش تلاشی را نداشته باشد (در اینجا، هر کسی خودش تصمیم می گیرد که آیا ارزش دارد برای 3 هفته در شب برای یک جایزه 100 هزار نفری، تقسیم شده بین کل تیم، و حتی با خطر عدم دریافت آن، کدنویسی کند یا خیر). اما، اغلب، این تنها فرصت برای پیشرفت است.
3. انتخاب تیم همانطور که در چت های هکاتون متوجه شدم، بسیاری به این موضوع کاملاً بیهوده برخورد می کنند (اگرچه این مهم ترین تصمیمی است که نتیجه شما را در هکاتون تعیین می کند). در بسیاری از زمینه‌های فعالیت (چه در ورزش و چه در هکاتون) دیده‌ام که افراد قوی تمایل دارند با قوی‌ها، ضعیف‌ها با ضعیف‌ها، باهوش‌ها با باهوش‌ها متحد شوند، خب، به طور کلی، شما می‌دانید... تقریباً این همان چیزی است که در چت ها اتفاق می افتد: برنامه نویسان کمتر قوی بلافاصله از بین می روند، افرادی که هیچ مهارت ارزشمندی برای هکاتون ندارند برای مدت طولانی در چت می مانند و تیمی را بر اساس این اصل انتخاب می کنند که اگر فقط کسی آن را قبول کند. . در برخی از هکاتون ها، تخصیص تصادفی به تیم ها انجام می شود و برگزارکنندگان ادعا می کنند که تیم های تصادفی بدتر از تیم های موجود نیستند. اما طبق مشاهدات من، افراد با انگیزه، به عنوان یک قاعده، تیمی را به تنهایی پیدا می کنند؛ اگر کسی باید تعیین شود، اغلب، بسیاری از آنها به هکاتون نمی آیند.
در مورد ترکیب تیم، این بسیار فردی است و به شدت به وظیفه بستگی دارد. می توانم بگویم که حداقل ترکیب تیم قابل دوام یک طراح - جلویی یا جلویی - پشتی است. اما مواردی را نیز می‌شناسم که تیم‌هایی که فقط از فرانت‌ندرها تشکیل شده‌اند، برنده شده‌اند، که یک بک‌اند ساده در node.js اضافه کرده‌اند، یا یک اپلیکیشن موبایل در React Native ساخته‌اند. یا فقط از پشتیبان هایی که چیدمان ساده را انجام داده اند. به طور کلی، همه چیز بسیار فردی است و به کار بستگی دارد. برنامه من برای انتخاب تیم برای هکاتون به این صورت بود: قصد داشتم یک تیم جمع کنم یا به تیمی مانند front-end - back-end - designer ملحق شوم (من خودم یک front-end هستم). و خیلی سریع شروع کردم به چت کردن با یک پشتیبان پایتون و یک طراح که دعوت را برای پیوستن به ما پذیرفت. کمی بعد، یک دختر، تحلیلگر کسب و کار، که قبلاً تجربه برنده شدن در هکاتون را داشت، به ما ملحق شد و این مسئله پیوستن او به ما را قطعی کرد. پس از یک جلسه کوتاه، تصمیم گرفتیم که خود را U4 (URBAN 4، urban four) به قیاس با چهار فوق العاده بنامیم. و حتی تصویر مربوطه را در آواتار کانال تلگرام ما قرار دادند.
4. انتخاب یک کار. همانطور که قبلاً گفتم، شما باید مزیت رقابتی داشته باشید، وظیفه هکاتون بر این اساس انتخاب می شود. بر این اساس، با نگاه کردن و با ارزیابی پیچیدگی آنها، دو وظیفه را انجام دادیم: کاتالوگ شرکت های نوآورانه از DPiIR و چت بات از EFKO. وظیفه از DPIiR توسط پشتیبان انتخاب شد، وظیفه EFKO توسط من انتخاب شد، زیرا تجربه نوشتن چت بات در node.js و DialogFlow را داشت. وظیفه EFKO همچنین شامل ML بود؛ من تجربه ای نه چندان گسترده در ML دارم. و با توجه به شرایط مشکل، بعید به نظر می رسید که با استفاده از ابزارهای ML حل شود. این احساس زمانی تقویت شد که به جلسه چالش Urban Tech Challenge رفتم، جایی که برگزارکنندگان مجموعه داده ای را در EFKO به من نشان دادند، جایی که حدود 100 عکس از طرح بندی محصول (گرفته شده از زوایای مختلف) و حدود 20 کلاس از خطاهای چیدمان وجود داشت. و در همان زمان، کسانی که این کار را سفارش داده بودند، می خواستند به نرخ موفقیت طبقه بندی 90٪ دست یابند. در نتیجه، من یک ارائه از راه حل بدون ML آماده کردم، پشتیبان یک ارائه بر اساس کاتالوگ تهیه کرد و با هم، پس از نهایی کردن ارائه ها، آنها را به چالش Urban Tech فرستادیم. قبلاً در این مرحله، میزان انگیزه و مشارکت هر یک از شرکت کنندگان مشخص شد. طراح ما در بحث ها شرکت نکرد، دیر پاسخ داد و حتی در آخرین لحظه اطلاعات مربوط به خود را در ارائه پر کرد، به طور کلی، شک و تردیدهایی به وجود آمد.
در نتیجه، ما وظیفه را از DPiIR پشت سر گذاشتیم و از اینکه EFKO را پاس نکردیم، اصلاً ناراحت نشدیم، زیرا این کار، به بیان ملایم، برای ما عجیب به نظر می رسید.
5. آماده شدن برای هکاتون. وقتی بالاخره مشخص شد که ما برای هکاتون واجد شرایط هستیم، شروع به آماده سازی کردیم. و در اینجا من از شروع کدنویسی یک هفته قبل از شروع هکاتون دفاع نمی کنم. حداقل، شما باید یک دیگ بخار آماده داشته باشید، که می توانید بلافاصله بدون نیاز به پیکربندی ابزارها و بدون برخورد با اشکالاتی که برای اولین بار در یک هکاتون امتحان کردید، شروع به کار کنید. من داستانی درباره مهندسان انگولار می دانم که به یک هکاتون آمدند و 2 روز را صرف راه اندازی ساخت پروژه کردند، بنابراین همه چیز باید از قبل آماده شود. ما قصد داشتیم مسئولیت ها را به صورت زیر تقسیم کنیم: پشتیبان خزنده هایی را می نویسد که اینترنت را جست و جو می کنند و تمام اطلاعات جمع آوری شده را در پایگاه داده قرار می دهند، در حالی که من یک API در node.js می نویسم که این پایگاه داده را پرس و جو می کند و داده ها را به جلو می فرستد. در این رابطه از قبل با استفاده از express.js یک سرور آماده کردم و در react یک front-end آماده کردم. من از CRA استفاده نمی کنم، من همیشه بسته وب را برای خودم سفارشی می کنم و به خوبی می دانم که این چه خطراتی می تواند داشته باشد (داستان مربوط به توسعه دهندگان زاویه ای را به خاطر بسپارید). در این مرحله، من از طراح خود الگوهای رابط یا حداقل مدل‌هایی را درخواست کردم تا ایده‌ای داشته باشم که چه چیزی را می‌سازم. از نظر تئوری هم باید تدارکات خودش را انجام دهد و با ما هماهنگ کند اما هیچ وقت جوابی نگرفتم. در نتیجه طرح را از یکی از پروژه های قدیمی ام قرض گرفتم. و حتی سریعتر شروع به کار کرد، زیرا تمام سبک های این پروژه قبلاً نوشته شده بود. از این رو نتیجه گیری: یک طراح همیشه در یک تیم مورد نیاز نیست))). با این پیشرفت ها به هکاتون رسیدیم.
6. در هکاتون کار کنید. اولین باری که تیمم را به صورت زنده دیدم تنها در افتتاحیه هکاتون در مرکز توزیع مرکزی بود. ما ملاقات کردیم، راه حل و مراحل کار روی مشکل را مورد بحث قرار دادیم. و اگرچه پس از افتتاحیه مجبور شدیم با اتوبوس به اکتبر سرخ برویم، اما برای خواب به خانه رفتیم و موافقت کردیم که تا ساعت 9.00 به محل برسیم. چرا؟ ظاهراً برگزارکنندگان می‌خواستند بیشترین بهره را از شرکت‌کنندگان ببرند، بنابراین چنین برنامه‌ای را ترتیب دادند. اما، در تجربه من، شما می توانید به طور معمول بدون خواب برای یک شب کدنویسی کنید. در مورد دومی، دیگر مطمئن نیستم. هکاتون یک ماراتن است؛ شما باید قدرت خود را به اندازه کافی محاسبه و برنامه ریزی کنید. علاوه بر این، ما تدارکاتی داشتیم.
بنابراین، پس از خوابیدن، ساعت 9.00:4 در طبقه ششم Dewocracy نشسته بودیم. سپس طراح ما به طور غیرمنتظره ای اعلام کرد که لپ تاپ ندارد و از خانه کار می کند و تلفنی با هم ارتباط برقرار می کنیم. این آخرین نی بود. و بنابراین ما از چهار به سه تبدیل شدیم، اگرچه نام تیم را تغییر ندادیم. باز هم، این ضربه بزرگی برای ما نبود؛ من قبلاً طرح پروژه قدیمی را داشتم. به طور کلی، در ابتدا همه چیز کاملاً روان و طبق برنامه پیش رفت. ما مجموعه داده ای از شرکت های نوآور از سازمان دهندگان را در پایگاه داده بارگذاری کردیم (ما تصمیم گرفتیم از neo4j استفاده کنیم). من شروع به حروفچینی کردم، سپس node.js را گرفتم، و بعد همه چیز شروع به خراب شدن کرد. من قبلاً هرگز با neo8j کار نکرده بودم و ابتدا به دنبال یک درایور کارآمد برای این پایگاه داده بودم، سپس متوجه شدم که چگونه یک پرس و جو بنویسم، و سپس با تعجب متوجه شدم که این پایگاه داده، هنگامی که پرس و جو می شود، موجودیت هایی را در شکل آرایه ای از اشیاء گره و لبه های آنها. آن ها هنگامی که من یک سازمان و تمام داده های موجود در آن را توسط TIN درخواست کردم، به جای یک شی سازمان، یک آرایه طولانی از اشیاء حاوی داده های این سازمان و روابط بین آنها به من برگردانده شد. من یک نگاشت نوشتم که کل آرایه را طی کرد و همه اشیاء را مطابق با سازمانشان در یک شیء چسباندم. اما در نبرد، هنگام درخواست پایگاه داده از 20 هزار سازمان، بسیار آهسته، حدود 30 تا 30 ثانیه اجرا شد. من شروع کردم به فکر کردن به بهینه سازی... و بعد به موقع متوقف شدیم و به MongoDB تغییر دادیم و حدود 4 دقیقه طول کشید. در کل حدود 5 ساعت در neoXNUMXj از دست رفت.
به یاد داشته باشید، هرگز فن آوری را به هکاتونی که با آن آشنایی ندارید نبرید، ممکن است شگفتی هایی وجود داشته باشد. اما در کل جدا از این شکست همه چیز طبق برنامه پیش رفت. و قبلاً در صبح روز 9 دسامبر ، ما یک برنامه کاملاً کارآمد داشتیم. برای بقیه روز ما برنامه ریزی کردیم که ویژگی های اضافی را به آن اضافه کنیم. در آینده، همه چیز برای من نسبتاً راحت پیش رفت، اما پشتیبان با ممنوعیت خزنده های خود در موتورهای جستجو، در هرزنامه های جمع آوری کننده اشخاص حقوقی، که در هنگام درخواست در اولین مکان های نتایج جستجو قرار می گرفتند، مشکلات زیادی داشت. برای هر شرکت خاص اما بهتر است خودش در این مورد بگوید. اولین ویژگی اضافی که اضافه کردم جستجو با نام کامل بود. مدیر کل VKontakte. چندین ساعت طول کشید.
بنابراین ، در صفحه شرکت در برنامه ما ، نماد مدیر کل ، پیوندی به صفحه VKontakte وی و برخی داده های دیگر ظاهر شد. این یک گیلاس خوب روی کیک بود، اگرچه ممکن است به ما برنده نشده باشد. سپس، من می خواستم یک تجزیه و تحلیل اجرا کنم. اما پس از جستجوی طولانی گزینه ها (تفاوت های زیادی در رابط کاربری وجود داشت)، من به ساده ترین تجمیع سازمان ها بر اساس کد فعالیت اقتصادی پرداختم. در حال حاضر در عصر، در آخرین ساعات، من یک الگو برای نمایش محصولات نوآورانه قرار می دادم (در برنامه ما قرار است بخش محصولات و خدمات وجود داشته باشد)، اگرچه پشتیبان برای این کار آماده نبود. در همان زمان، پایگاه داده با جهش و مرز متورم شد، خزنده ها به کار خود ادامه دادند، پشتیبان با NLP آزمایش کرد تا متون نوآورانه را از متن های غیر ابتکاری تشخیص دهد))). اما زمان ارائه نهایی نزدیک بود.
7. ارائه. با توجه به تجربه خودم، می توانم بگویم که شما باید 3 تا 4 ساعت قبل از موعد ارائه، به تهیه یک ارائه روی بیاورید. به خصوص اگر شامل ویدئو باشد، تصویربرداری و ویرایش آن زمان زیادی را می گیرد. قرار شد یک ویدیو داشته باشیم. و ما یک فرد ویژه داشتیم که به این موضوع رسیدگی کرد و یکسری مسائل سازمانی دیگر را نیز حل کرد. در این زمینه تا آخرین لحظه حواسمان را از کدنویسی پرت نکردیم.
8. زمین. من دوست نداشتم که ارائه ها و فینال ها در یک روز هفته جداگانه (دوشنبه) برگزار شود. در اینجا، به احتمال زیاد، سیاست برگزارکنندگان برای فشار حداکثری از شرکت کنندگان ادامه یافت. من قصد نداشتم از کار مرخصی بگیرم، فقط می خواستم به فینال بروم، اگرچه بقیه اعضای تیمم روز را تعطیل کردند. با این حال، غوطه ور شدن عاطفی در هکاتون از قبل آنقدر بالا بود که ساعت 8 صبح در چت تیمم (تیم کاری، نه تیم هکاتون) نوشتم که روز را با هزینه شخصی می گذرانم و به مرکز رفتم. دفتر برای زمین معلوم شد که مشکل ما تعداد زیادی دانشمند داده خالص دارد و این به شدت بر رویکرد حل مشکل تأثیر گذاشت. بسیاری از آنها یک DS خوب داشتند، اما هیچ کس نمونه اولیه کارکردی نداشت، بسیاری نمی توانستند ممنوعیت خزنده های خود را در موتورهای جستجو دور بزنند. ما تنها تیمی بودیم که یک نمونه اولیه کار می کرد. و ما می دانستیم که چگونه مشکل را حل کنیم. در نهایت پیست را بردیم، هرچند خیلی خوش شانس بودیم که کم رقابتی ترین کار را انتخاب کردیم. با نگاهی به زمین های دیگر پیست ها، متوجه شدیم که هیچ شانسی در آنجا نخواهیم داشت. همچنین می خواهم بگویم که ما از نظر هیئت داوران خیلی خوش شانس بودیم؛ آنها با دقت کد را بررسی کردند. و با قضاوت بر اساس بررسی ها، این اتفاق در همه آهنگ ها رخ نداد.
9. نهایی. بعد از اینکه چندین بار برای بررسی کد به هیئت منصفه دعوت شدیم، با این فکر که بالاخره همه مسائل را حل کرده ایم، برای صرف ناهار به برگر کینگ رفتیم. در آنجا برگزارکنندگان دوباره با ما تماس گرفتند، مجبور شدیم سریع سفارشاتمان را جمع کنیم و برگردیم.
برگزارکننده به ما نشان داد که باید به کدام اتاق برویم و پس از ورود، خود را در یک جلسه تمرین سخنرانی عمومی برای تیم های برنده دیدیم. بچه هایی که قرار بود روی صحنه اجرا کنند شارژ خوبی داشتند، همه مثل شومن های واقعی بیرون آمدند.
و باید اعتراف کنم، در فینال، در مقابل پس‌زمینه قوی‌ترین تیم‌ها از مسیرهای دیگر، ما رنگ پریده به نظر می‌رسیدیم؛ پیروزی در نامزدی مشتریان دولتی کاملاً شایسته به تیم از مسیر فناوری املاک و مستغلات رسید. من فکر می کنم عوامل کلیدی که به پیروزی ما در مسیر کمک کرد عبارت بودند از: در دسترس بودن یک جای خالی آماده که به همین دلیل ما توانستیم به سرعت یک نمونه اولیه بسازیم، وجود "نقاط برجسته" در نمونه اولیه (جستجوی مدیران عامل در شبکه‌های اجتماعی) و مهارت‌های NLP پشتیبان ما، که هیئت داوران را نیز بسیار مورد توجه قرار داد.
و در پایان، تشکر سنتی از همه کسانی که از ما حمایت کردند، هیئت داوران آهنگ ما، اوگنی اوگرافیف (نویسنده مشکلی که در هکاتون حل کردیم) و البته برگزارکنندگان هکاتون. این شاید بزرگ‌ترین و جالب‌ترین هکاتونی بود که تا به حال در آن شرکت کرده‌ام، فقط می‌توانم آرزو کنم که بچه‌ها در آینده چنین استاندارد بالایی داشته باشند!
منبع: www.habr.com