როგორ და რატომ მოვიგეთ Big Data ტრეკი Urban Tech Challenge ჰაკათონზე

მე მქვია დიმიტრი. და მე მსურს ვისაუბრო იმაზე, თუ როგორ მიაღწია ჩვენს გუნდს Urban Tech Challenge ჰაკათონის ფინალში Big Data-ის ტრასაზე. მაშინვე ვიტყვი, რომ ეს არ არის პირველი ჰაკათონი, რომელშიც მონაწილეობა მივიღე და არც პირველი, რომელშიც პრიზები ავიღე. ამასთან დაკავშირებით, ჩემს მოთხრობაში მინდა გამოვთქვა ზოგიერთი ზოგადი დაკვირვება და დასკვნა ჰაკათონის ინდუსტრიასთან დაკავშირებით, როგორც მთლიანობაში, და გამოვთქვა ჩემი თვალსაზრისი იმ ნეგატიური მიმოხილვებისგან განსხვავებით, რომლებიც ინტერნეტში გამოჩნდა Urban Tech Challenge-ის დასრულებისთანავე ( მაგალითი ამ).

ასე რომ, ჯერ რამდენიმე ზოგადი დაკვირვება.

1. გასაკვირია, რომ საკმაოდ ბევრი ადამიანი გულუბრყვილოდ ფიქრობს, რომ ჰაკათონი არის ერთგვარი სპორტული შეჯიბრი, სადაც საუკეთესო კოდირებები იმარჯვებენ. ეს არასწორია. მე არ განვიხილავ შემთხვევებს, როდესაც თავად ჰაკათონის ორგანიზატორებმა არ იციან რა უნდათ (ეს მეც ვნახე). მაგრამ, როგორც წესი, კომპანია, რომელიც აწყობს ჰაკათონს, საკუთარ მიზნებს მისდევს. მათი სია შეიძლება განსხვავებული იყოს: ეს შეიძლება იყოს ზოგიერთი პრობლემის ტექნიკური გადაწყვეტა, ახალი იდეებისა და ადამიანების ძიება და ა.შ. ეს მიზნები ხშირად განსაზღვრავს ღონისძიების ფორმატს, მის ვადებს, ონლაინ/ოფლაინ, როგორ ჩამოყალიბდება ამოცანები (და ჩამოყალიბდება თუ არა ისინი საერთოდ), იქნება თუ არა კოდის მიმოხილვა ჰაკათონზე და ა.შ. ამ კუთხით ფასდება ორივე გუნდი და ის, რაც გააკეთეს. და ის გუნდები, რომლებიც საუკეთესოდ მოხვდნენ იმ წერტილში, რომელიც კომპანიას სჭირდება, იმარჯვებენ და ბევრი მათგანი სრულიად გაუცნობიერებლად და შემთხვევით მიდის აქამდე, ფიქრობს, რომ ისინი ნამდვილად მონაწილეობენ სპორტულ შეჯიბრში. ჩემი დაკვირვებები აჩვენებს, რომ მონაწილეთა მოტივაციისთვის ორგანიზატორებმა უნდა შექმნან მინიმუმ სპორტული გარემო და თანაბარი პირობები, წინააღმდეგ შემთხვევაში ისინი მიიღებენ ნეგატივის ტალღას, როგორც ზემოთ აღწერილი. მაგრამ ჩვენ გადავდივართ.

2. აქედან გამომდინარეობს შემდეგი დასკვნა. ორგანიზატორები დაინტერესებულნი არიან ჰაკათონზე საკუთარი ნამუშევრებით მისული მონაწილეებით, ზოგჯერ ამ მიზნით სპეციალურად აწყობენ ონლაინ მიმოწერის ეტაპსაც. ეს საშუალებას იძლევა უფრო ძლიერი გამომავალი გადაწყვეტილებები. „საკუთარი სამუშაოს“ კონცეფცია ძალიან ფარდობითია; ნებისმიერ გამოცდილ დეველოპერს შეუძლია დააგროვოს კოდის ათასობით სტრიქონი თავისი ძველი პროექტებიდან პირველ დავალებაში. და იქნება ეს წინასწარ მომზადებული განვითარება? მაგრამ ნებისმიერ შემთხვევაში მოქმედებს წესი, რომელიც მე გამოვხატე ცნობილი მემის სახით:

იმისათვის რომ გაიმარჯვო, უნდა გქონდეს რაღაც, რაიმე სახის კონკურენტული უპირატესობა: მსგავსი პროექტი, რომელიც წარსულში გააკეთე, ცოდნა და გამოცდილება კონკრეტულ თემაზე, ან ჰაკათონის დაწყებამდე შესრულებული მზა სამუშაო. დიახ, ეს არ არის სპორტული. დიახ, ეს შეიძლება არ ღირდეს დახარჯული ძალისხმევის ღირსი (აქ, ყველა თავად წყვეტს, ღირს თუ არა ღამის 3 კვირის განმავლობაში კოდირება 100 ათასი პრიზისთვის, გაყოფილი მთელ გუნდში და თუნდაც მისი არ მიღების რისკით). მაგრამ, ხშირად, ეს არის წინსვლის ერთადერთი შანსი.

3. გუნდის შერჩევა. როგორც მე შევნიშნე ჰაკათონის ჩატებში, ბევრი ამ საკითხს საკმაოდ არასერიოზულად უახლოვდება (თუმცა ეს არის ყველაზე მნიშვნელოვანი გადაწყვეტილება, რომელიც განსაზღვრავს თქვენს შედეგს ჰაკათონზე). საქმიანობის ბევრ სფეროში (როგორც სპორტში, ასევე ჰაკათონებში) მინახავს, ​​რომ ძლიერი ადამიანები მიდრეკილნი არიან ძლიერებთან გაერთიანებისკენ, სუსტები სუსტებთან, ჭკვიანები ჭკვიანებთან, ზოგადად, გესმით... დაახლოებით ასე ხდება ჩატებში: ნაკლებად ძლიერი პროგრამისტები, ისინი მაშინვე იჭრებიან, ადამიანები, რომლებსაც ჰაკათონისთვის ღირებული უნარები არ გააჩნიათ, დიდხანს ჩერდებიან ჩატში და ირჩევენ გუნდს იმ პრინციპით, რომ თუ ვინმე აიღებს მას. . ზოგიერთ ჰაკათონზე პრაქტიკაში ხდება გუნდების შემთხვევითი დავალებები და ორგანიზატორები ამტკიცებენ, რომ შემთხვევითი გუნდები არსებულზე უარესად არ მუშაობენ. მაგრამ, ჩემი დაკვირვებით, მოტივირებული ადამიანები, როგორც წესი, თავად პოულობენ გუნდს, თუ ვინმეს უნდა დაენიშნოს, მაშინ, ხშირად, ბევრი მათგანი არ მოდის ჰაკათონზე.

რაც შეეხება გუნდის შემადგენლობას, ეს ძალიან ინდივიდუალურია და დიდად არის დამოკიდებული დავალებაზე. მე შემიძლია ვთქვა, რომ მინიმალური სიცოცხლისუნარიანი გუნდის შემადგენლობა არის დიზაინერი - ფრონტ-ენდი ან ფრონტ-ენდი - ბექ-ენდი. მაგრამ მე ასევე ვიცი შემთხვევები, როდესაც გაიმარჯვეს მხოლოდ ფრონტ-ენდერებისგან შემდგარმა გუნდებმა, რომლებმაც დაამატეს მარტივი back-end node.js-ში, ან შექმნეს მობილური აპლიკაცია React Native-ში; ან მხოლოდ დამხმარეებიდან, რომლებმაც გააკეთეს მარტივი განლაგება. ზოგადად, ყველაფერი ძალიან ინდივიდუალურია და ამოცანაზეა დამოკიდებული. ჩემი გეგმა ჰაკათონისთვის გუნდის შერჩევის შესახებ ასეთი იყო: ვგეგმავდი გუნდის შეკრებას ან გუნდში გაწევრიანებას, როგორიცაა front-end - back-end - დიზაინერი (მე თვითონ ვარ ფრონტ-ენდი). და საკმაოდ სწრაფად დავიწყე ჩეთი პითონის ბექენდერთან და დიზაინერთან, რომელმაც მიიღო მოწვევა შემოგვიერთდა. ცოტა მოგვიანებით შემოგვიერთდა გოგონა, ბიზნეს ანალიტიკოსი, რომელსაც უკვე ჰქონდა ჰაკათონის მოგების გამოცდილება და ამან გადაწყვიტა მისი ჩვენთან გაწევრიანების საკითხი. ხანმოკლე შეხვედრის შემდეგ გადავწყვიტეთ დავარქვათ თავს 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. მზადება ჰაკათონისთვის. როდესაც საბოლოოდ ცნობილი გახდა, რომ ჰაკათონისთვის კვალიფიკაცია გავიარეთ, მზადება დავიწყეთ. და აქ მე არ ვარ მომხრე, რომ დაიწყოს კოდის დაწერა ჰაკათონის დაწყებამდე ერთი კვირით ადრე. მინიმუმ, მზად უნდა გქონდეთ ქვაბის ფირფიტა, რომლითაც შეგიძლიათ დაუყოვნებლივ დაიწყოთ მუშაობა, ხელსაწყოების კონფიგურაციის საჭიროების გარეშე და რაიმე სახის შეცდომის შეჯახების გარეშე, რომელიც პირველად გადაწყვიტეთ ჰაკათონზე სცადოთ. მე ვიცი ამბავი კუთხური ინჟინრების შესახებ, რომლებიც მივიდნენ ჰაკათონზე და 2 დღე დახარჯეს პროექტის აწყობაზე, ამიტომ ყველაფერი წინასწარ უნდა მომზადდეს. ჩვენ ვაპირებდით პასუხისმგებლობების განაწილებას შემდეგნაირად: დამხმარე წერს კრეულერებს, რომლებიც ასუფთავებენ ინტერნეტს და ათავსებენ ყველა შეგროვებულ ინფორმაციას მონაცემთა ბაზაში, ხოლო მე ვწერ API-ს node.js-ში, რომელიც კითხულობს ამ მონაცემთა ბაზას და აგზავნის მონაცემებს წინ. ამასთან დაკავშირებით, წინასწარ მოვამზადე სერვერი express.js-ის გამოყენებით და მოვამზადე ფრონტ-ენდი რეაქტში. მე არ ვიყენებ CRA-ს, მე ყოველთვის ვაფორმებ ვებპაკეტს ჩემთვის და ძალიან კარგად ვიცი, რა რისკებს შეიძლება მოჰყვეს ეს (გაიხსენეთ ამბავი კუთხოვანი დეველოპერების შესახებ). ამ ეტაპზე, მე მოვითხოვე ინტერფეისის შაბლონები ან მინიმუმ მაკეტები ჩვენი დიზაინერისგან, რათა მქონოდა წარმოდგენა იმის შესახებ, თუ რას დავდებდი. თეორიულად მანაც თვითონ უნდა მოამზადოს და კოორდინირება მოახდინოს ჩვენთან, მაგრამ პასუხი არასდროს მიმიღია. შედეგად, დიზაინი ვისესხე ჩემი ერთ-ერთი ძველი პროექტისგან. და კიდევ უფრო სწრაფად დაიწყო მუშაობა, რადგან ამ პროექტის ყველა სტილი უკვე დაწერილი იყო. აქედან გამომდინარეობს დასკვნა: დიზაინერი ყოველთვის არ არის საჭირო გუნდში))). ჩვენ მოვედით ჰაკათონზე ამ განვითარებით.

6. მუშაობა ჰაკათონზე. პირველად ჩემი გუნდი პირდაპირ ეთერში მხოლოდ ჰაკათონის გახსნაზე ვნახე ცენტრალურ სადისტრიბუციო ცენტრში. შევხვდით, განვიხილეთ პრობლემის გადაჭრისა და მუშაობის ეტაპები. და მიუხედავად იმისა, რომ გახსნის შემდეგ წითელ ოქტომბერში ავტობუსით უნდა წავსულიყავით, სახლში წავედით დასაძინებლად და შევთანხმდით, რომ ადგილზე 9.00 საათისთვის მივსულიყავით. რატომ? როგორც ჩანს, ორგანიზატორებს სურდათ მონაწილეთაგან მაქსიმალური სარგებლობის მიღება, ამიტომ სწორედ ასეთი განრიგი მოაწყვეს. მაგრამ, ჩემი გამოცდილებით, შეგიძლიათ ნორმალურად კოდირება ერთი ღამის ძილის გარეშე. რაც შეეხება მეორეს, აღარ ვარ დარწმუნებული. ჰაკათონი არის მარათონი, თქვენ უნდა ადეკვატურად გამოთვალოთ და დაგეგმოთ თქვენი ძალა. მეტიც, მზადება გვქონდა.

ამიტომ, ძილის შემდეგ, 9.00 საათზე ვისხედით Dewocracy-ის მეექვსე სართულზე. მერე ჩვენმა დიზაინერმა მოულოდნელად გამოაცხადა, რომ ლეპტოპი არ აქვს და სახლიდან იმუშავებს და ტელეფონით დავუკავშირდებით. ეს იყო ბოლო წვეთი. ასე რომ, ოთხიდან სამამდე გადავედით, თუმცა გუნდის სახელი არ შეგვიცვლია. ისევ და ისევ, ეს ჩვენთვის დიდი დარტყმა არ იყო, მე უკვე მქონდა დიზაინი ძველი პროექტისგან. ზოგადად, თავიდან ყველაფერი საკმაოდ მშვიდად და გეგმის მიხედვით მიდიოდა. ჩვენ ჩავტვირთეთ მონაცემთა ბაზაში (ჩვენ გადავწყვიტეთ გამოვიყენოთ neo4j) ინოვაციური კომპანიების ნაკრები ორგანიზატორებისგან. დავიწყე აკრეფა, შემდეგ ავიღე node.js, შემდეგ კი რამის გაფუჭება დაიწყო. აქამდე არასდროს მიმუშავია neo4j-თან და თავიდან ვეძებდი სამუშაო დრაივერს ამ მონაცემთა ბაზისთვის, შემდეგ გავარკვიე, როგორ დამეწერა შეკითხვა, შემდეგ კი გამიკვირდა, რომ აღმოვაჩინე, რომ ეს მონაცემთა ბაზა, მოკითხვისას, აბრუნებს ერთეულებს კვანძის ობიექტებისა და მათი კიდეების მასივის ფორმა. იმათ. როდესაც მე მოვითხოვე ორგანიზაცია და მასზე არსებული ყველა მონაცემი TIN-ით, ერთი ორგანიზაციის ობიექტის ნაცვლად, დამიბრუნეს ობიექტების გრძელი მასივი, რომელიც შეიცავს მონაცემებს ამ ორგანიზაციაზე და მათ შორის ურთიერთობებზე. მე დავწერე რუკტი, რომელმაც გაიარა მთელი მასივი და ყველა ობიექტი მათი ორგანიზაციის მიხედვით ერთ ობიექტად დავაწებე. მაგრამ ბრძოლაში, 8 ათასი ორგანიზაციის მონაცემთა ბაზის მოთხოვნისას, იგი შესრულდა უკიდურესად ნელა, დაახლოებით 20 - 30 წამში. დავიწყე ოპტიმიზაციაზე ფიქრი... შემდეგ კი დროზე შევჩერდით და გადავედით MongoDB-ზე და დაახლოებით 30 წუთი დაგვჭირდა. საერთო ჯამში, neo4j-ზე დაახლოებით 5 საათი დაიკარგა.

დაიმახსოვრეთ, არასოდეს წაიყვანოთ ტექნოლოგია ჰაკათონზე, რომელსაც არ იცნობთ, შეიძლება სიურპრიზები იყოს. მაგრამ, ზოგადად, ამ წარუმატებლობის გარდა, ყველაფერი გეგმის მიხედვით წარიმართა. და უკვე 9 დეკემბერს დილით გვქონდა სრულად სამუშაო აპლიკაცია. დანარჩენი დღის განმავლობაში ვგეგმავდით მას დამატებითი ფუნქციების დამატებას. სამომავლოდ ყველაფერი შედარებით შეუფერხებლად წავიდა ჩემთვის, მაგრამ ბექენდერს ჰქონდა მთელი რიგი პრობლემები საძიებო სისტემებში მისი მცოცავების აკრძალვასთან დაკავშირებით, იურიდიული პირების აგრეგატორების სპამში, რომლებიც მოთხოვნისას ძიების შედეგების პირველ ადგილზე მოხვდნენ. თითოეული კონკრეტული კომპანიისთვის. მაგრამ ჯობია მან თავად თქვას ამის შესახებ. პირველი დამატებითი ფუნქცია, რომელიც მე დავამატე იყო ძიება სრული სახელით. VKontakte-ს გენერალური დირექტორი. რამდენიმე საათი დასჭირდა.

ასე რომ, კომპანიის გვერდზე ჩვენს აპლიკაციაში გამოჩნდა გენერალური დირექტორის ავატარი, ბმული მის VKontakte გვერდზე და სხვა მონაცემები. ტორტზე ლამაზი ალუბალი იყო, თუმცა შესაძლოა გამარჯვება არ მოგვცეს. შემდეგ, მინდოდა გამეკეთებინა ანალიტიკა. მაგრამ ვარიანტების ხანგრძლივი ძიების შემდეგ (UI-სთან ბევრი ნიუანსი იყო), მე გადავწყვიტე ორგანიზაციების უმარტივესი აგრეგაცია ეკონომიკური საქმიანობის კოდით. უკვე საღამოს, ბოლო საათებში, მე ვაწყობდი შაბლონს ინოვაციური პროდუქტების ჩვენებისთვის (ჩვენს აპლიკაციაში უნდა იყოს პროდუქტები და სერვისების განყოფილება), თუმცა ბექენდი ამისთვის მზად არ იყო. ამავდროულად, მონაცემთა ბაზა ნახტომებით იზრდებოდა, მცოცავი აგრძელებდა მუშაობას, ბექენდერი ატარებდა ექსპერიმენტებს NLP-ით, რათა განასხვავოს ინოვაციური ტექსტები არაინოვაციურიდან))). მაგრამ საბოლოო პრეზენტაციის დრო უკვე ახლოვდებოდა.

7. პრეზენტაცია. ჩემი საკუთარი გამოცდილებიდან შემიძლია ვთქვა, რომ თქვენ უნდა გადახვიდეთ პრეზენტაციის მომზადებაზე მის დასრულებამდე 3-4 საათით ადრე. მით უმეტეს, თუ ის ვიდეოს მოიცავს, მის გადაღებას და მონტაჟს საკმაოდ დიდი დრო სჭირდება. ჩვენ უნდა გვქონდეს ვიდეო. ჩვენ გვყავდა სპეციალური ადამიანი, რომელიც ეხებოდა ამ საქმეს და ასევე გადაჭრის სხვა ორგანიზაციულ საკითხებს. ამ კუთხით, ბოლო მომენტამდე ჩვენ არ გავშორდით კოდირებას.

8. მოედანი. არ მომეწონა, რომ პრეზენტაციები და ფინალი ტარდებოდა ცალკე სამუშაო დღეს (ორშაბათს). აქ, დიდი ალბათობით, გაგრძელდა ორგანიზატორების პოლიტიკა მონაწილეთაგან მაქსიმუმის გამოდევნის შესახებ. სამსახურიდან დასვენებას არ ვგეგმავდი, მხოლოდ ფინალში მოსვლა მინდოდა, თუმცა ჩემმა გუნდმა დასვენების დღე აიღო. თუმცა, ჰაკათონში ემოციური ჩაძირვა უკვე იმდენად მაღალი იყო, რომ დილის 8 საათზე ჩემი გუნდის ჩატში (სამუშაო გუნდი და არა ჰაკათონის გუნდი) დავწერე, რომ დღეს ჩემი ხარჯებით ვიღებდი და ცენტრალურში წავედი. ოფისი მოედნებისთვის. ჩვენს პრობლემას ბევრი სუფთა მონაცემთა მეცნიერი ჰყავდა და ამან დიდად იმოქმედა პრობლემის გადაჭრის მიდგომაზე. ბევრს ჰქონდა კარგი DS, მაგრამ არავის ჰყავდა სამუშაო პროტოტიპი, ბევრს არ შეეძლო დაეცვა საძიებო სისტემებში მათი მცოცავი აკრძალვები. ჩვენ ვიყავით ერთადერთი გუნდი სამუშაო პროტოტიპით. და ჩვენ ვიცოდით, როგორ გადავჭრათ პრობლემა. საბოლოოდ ტრასა მოვიგეთ, თუმცა ძალიან გაგვიმართლა, რომ ყველაზე ნაკლებად საკონკურსო დავალება ავირჩიეთ. სხვა ტრასებზე მოედნების დათვალიერებისას მივხვდით, რომ იქ შანსი არ გვექნებოდა. ასევე მინდა ვთქვა, რომ ძალიან გაგვიმართლა ჟიურიმ, მათ საგულდაგულოდ შეამოწმეს კოდი. და, თუ ვიმსჯელებთ მიმოხილვებით, ეს არ მომხდარა ყველა ტრეკზე.

9. ფინალი. მას შემდეგ რაც ჟიურიში რამდენჯერმე დაგვიბარეს კოდის განხილვაზე, ჩვენ, ვფიქრობდით, რომ საბოლოოდ მოვაგვარეთ ყველა საკითხი, წავედით ლანჩზე Burger King-ში. იქ ორგანიზატორებმა ისევ დაგვირეკეს, სწრაფად მოგვიწია შეკვეთების ჩალაგება და უკან დაბრუნება.

ორგანიზატორმა გვაჩვენა, რომელ ოთახში გვჭირდებოდა შესვლა და შესვლისთანავე აღმოვჩნდით გამარჯვებული გუნდების საჯარო გამოსვლის ტრენინგზე. ბიჭები, რომლებიც სცენაზე უნდა გამოსულიყვნენ, კარგად დატვირთულები იყვნენ, ყველა ნამდვილი შოუმენივით გამოვიდა.

და უნდა ვაღიარო, ფინალში, სხვა ტრასების უძლიერესი გუნდების ფონზე, ჩვენ ფერმკრთალი გამოვიყურებოდით; მთავრობის მომხმარებელთა ნომინაციაში გამარჯვება საკმაოდ დამსახურებულად წავიდა გუნდს უძრავი ქონების ტექნიკური ბილიკიდან. მე ვფიქრობ, რომ მთავარი ფაქტორები, რამაც ხელი შეუწყო ჩვენს გამარჯვებას ტრასაზე, იყო: მზა ბლანკის არსებობა, რის გამოც ჩვენ შევძელით სწრაფად შეგვექმნა პროტოტიპი, პროტოტიპში „მაჩვენებლების“ არსებობა (აღმასრულებელი დირექტორიების ძიება სოციალურ ქსელებში) და ჩვენი backender-ის NLP უნარები, რამაც ასევე დიდად დააინტერესა ჟიური.

და ბოლოს, ტრადიციული მადლობა ყველას, ვინც მხარი დაგვიჭირა, ჩვენი ტრეკის ჟიურის, ევგენი ევგრაფიევს (პრობლემის ავტორი, რომელიც ჩვენ გადავწყვიტეთ ჰაკათონზე) და რა თქმა უნდა ჰაკათონის ორგანიზატორებს. ეს იყო ალბათ ყველაზე დიდი და ყველაზე მაგარი ჰაკათონი, რომელშიც ოდესმე მიმიღია მონაწილეობა, ბიჭებს მხოლოდ მინდა ვუსურვო მომავალში ასეთი მაღალი სტანდარტის შენარჩუნება!

წყარო: www.habr.com