Tên tôi là Dmitry. Và tôi muốn nói về cách nhóm của chúng tôi lọt vào vòng chung kết của cuộc thi hackathon Thử thách công nghệ đô thị trên đường đua Dữ liệu lớn. Tôi sẽ nói ngay rằng đây không phải là cuộc thi hackathon đầu tiên mà tôi tham gia và cũng không phải là lần đầu tiên tôi giành được giải thưởng. Về vấn đề này, trong câu chuyện của mình, tôi muốn nêu lên một số quan sát và kết luận chung về toàn bộ ngành công nghiệp hackathon, đồng thời đưa ra quan điểm của mình trái ngược với những đánh giá tiêu cực xuất hiện trực tuyến ngay sau khi kết thúc Thử thách công nghệ đô thị (dành cho ví dụ ).
Vì vậy, đầu tiên một số quan sát chung.
1. Thật ngạc nhiên khi khá nhiều người ngây thơ nghĩ rằng hackathon là một loại cuộc thi thể thao mà những lập trình viên giỏi nhất sẽ giành chiến thắng. Cái này sai. Tôi không xét đến những trường hợp bản thân ban tổ chức hackathon cũng không biết họ muốn gì (tôi cũng từng thấy điều đó). Tuy nhiên, theo quy định, công ty tổ chức hackathon đều theo đuổi mục tiêu riêng của mình. Danh sách của họ có thể khác: đó có thể là một giải pháp kỹ thuật cho một số vấn đề, tìm kiếm ý tưởng và con người mới, v.v. Những mục tiêu này thường xác định hình thức của sự kiện, thời gian, trực tuyến/ngoại tuyến, cách thức các nhiệm vụ sẽ được hình thành (và liệu chúng có được hình thành hay không), liệu có đánh giá mã tại hackathon hay không, v.v. Cả hai đội và những gì họ đã làm đều được đánh giá từ quan điểm này. Và những đội đạt được điểm tốt nhất mà công ty cần sẽ giành chiến thắng, và nhiều người đi đến điểm này một cách hoàn toàn vô thức và vô tình, nghĩ rằng họ thực sự đang tham gia một cuộc thi thể thao. Quan sát của tôi cho thấy, để tạo động lực cho người tham gia, ban tổ chức ít nhất phải tạo ra diện mạo của một môi trường thể thao và điều kiện bình đẳng, nếu không sẽ đón nhận làn sóng tiêu cực, như đánh giá trên. Nhưng chúng ta lạc đề.
2. Do đó có kết luận sau đây. Ban tổ chức quan tâm đến việc những người tham gia hackathon bằng công việc riêng của họ, thậm chí đôi khi họ còn đặc biệt tổ chức một giai đoạn trao đổi thư từ trực tuyến cho mục đích này. Điều này cho phép các giải pháp đầu ra mạnh mẽ hơn. Khái niệm “công việc của chính mình” là một khái niệm rất tương đối; bất kỳ nhà phát triển có kinh nghiệm nào cũng có thể tích lũy hàng nghìn dòng mã từ các dự án cũ của mình trong lần cam kết đầu tiên. Và liệu đây có phải là một sự phát triển được chuẩn bị trước? Nhưng trong mọi trường hợp, quy tắc được áp dụng mà tôi đã thể hiện dưới dạng một meme nổi tiếng:
Để giành chiến thắng, bạn phải có thứ gì đó, một loại lợi thế cạnh tranh nào đó: một dự án tương tự mà bạn đã làm trước đây, kiến thức và kinh nghiệm về một chủ đề cụ thể hoặc một công việc làm sẵn được thực hiện trước khi bắt đầu hackathon. Vâng, đó không phải là thể thao. Đúng, điều này có thể không xứng đáng với nỗ lực đã bỏ ra (ở đây, mọi người tự quyết định xem có đáng để viết mã trong 3 tuần vào ban đêm để nhận giải thưởng 100 nghìn, chia cho toàn đội và thậm chí có nguy cơ không nhận được nó hay không). Nhưng thường thì đây là cơ hội duy nhất để tiến lên phía trước.
3. Lựa chọn đội. Như tôi nhận thấy trong các cuộc trò chuyện về hackathon, nhiều người tiếp cận vấn đề này khá nhẹ nhàng (mặc dù đây là quyết định quan trọng nhất sẽ quyết định kết quả của bạn tại hackathon). Trong nhiều lĩnh vực hoạt động (cả thể thao và hackathons), tôi đã thấy rằng những người mạnh mẽ có xu hướng đoàn kết với kẻ mạnh, kẻ yếu với kẻ yếu, người thông minh với người thông minh, nói chung, bạn hiểu ý... Đây gần như là những gì xảy ra trong các cuộc trò chuyện: những lập trình viên kém mạnh mẽ hơn sẽ ngay lập tức bị bắt, những người không có bất kỳ kỹ năng nào có giá trị cho một cuộc hackathon sẽ treo cổ trong cuộc trò chuyện trong một thời gian dài và chọn một đội theo nguyên tắc nếu chỉ có ai đó đảm nhận nó. . Tại một số hackathons, việc phân công ngẫu nhiên cho các đội được thực hiện và ban tổ chức khẳng định rằng các đội ngẫu nhiên hoạt động không tệ hơn các đội hiện có. Nhưng theo quan sát của tôi, những người có động lực, theo quy luật, sẽ tự mình tìm một đội; nếu ai đó phải được phân công, thì nhiều người trong số họ thường không đến hackathon.
Về thành phần của nhóm, điều này mang tính cá nhân cao và phụ thuộc nhiều vào nhiệm vụ. Tôi có thể nói rằng thành phần nhóm khả thi tối thiểu là một nhà thiết kế - front-end hoặc front-end - back-end. Nhưng tôi cũng biết những trường hợp khi các đội chỉ bao gồm những người chạy giao diện người dùng chiến thắng, những người đã thêm một back-end đơn giản trong node.js hoặc tạo một ứng dụng di động trong React Native; hoặc chỉ từ những người hỗ trợ đã thực hiện bố cục đơn giản. Nói chung, mọi thứ đều rất riêng biệt và phụ thuộc vào nhiệm vụ. Kế hoạch chọn đội cho hackathon của tôi như sau: Tôi dự định tập hợp một đội hoặc tham gia một đội như front-end - back-end - Designer (bản thân tôi cũng là front-end). Và khá nhanh chóng, tôi bắt đầu trò chuyện với một người hỗ trợ python và một nhà thiết kế đã chấp nhận lời mời tham gia cùng chúng tôi. Một lát sau, một cô gái, một nhà phân tích kinh doanh, người đã có kinh nghiệm chiến thắng một cuộc thi hackathon, đã tham gia cùng chúng tôi và điều này quyết định việc cô ấy tham gia cùng chúng tôi. Sau một cuộc gặp ngắn, chúng tôi quyết định gọi mình là U4 (URBAN 4, Urban Four) tương tự như Fantastic Four. Và họ thậm chí còn đặt một bức ảnh tương ứng lên ảnh đại diện của kênh telegram của chúng tôi.
4. Lựa chọn nhiệm vụ. Như tôi đã nói, bạn phải có lợi thế cạnh tranh, nhiệm vụ cho hackathon được lựa chọn dựa trên điều này. Dựa trên điều này, đã xem xét và đánh giá mức độ phức tạp của chúng, chúng tôi đã giải quyết hai nhiệm vụ: danh mục các doanh nghiệp đổi mới từ DPiIR và một chatbot từ EFKO. Nhiệm vụ từ PIiR là do backender chọn, nhiệm vụ từ EFKO là do tôi chọn, bởi vì đã có kinh nghiệm viết chatbot trong node.js và DialogFlow. Nhiệm vụ của EFKO cũng liên quan đến ML; Tôi có một số kinh nghiệm, nhưng không sâu lắm về ML. Và theo các điều kiện của vấn đề, đối với tôi, có vẻ như nó khó có thể giải quyết được bằng các công cụ ML. Cảm giác này càng được củng cố khi tôi đến buổi gặp mặt Thử thách công nghệ đô thị, nơi ban tổ chức cho tôi xem một tập dữ liệu trên EFKO, trong đó có khoảng 100 bức ảnh về bố cục sản phẩm (chụp từ các góc khác nhau) và khoảng 20 loại lỗi bố cục. Đồng thời, những người đặt hàng nhiệm vụ muốn đạt được tỷ lệ phân loại thành công là 90%. Do đó, tôi đã chuẩn bị bản trình bày về giải pháp không có ML, người hỗ trợ đã chuẩn bị bản trình bày dựa trên danh mục và cùng nhau, sau khi hoàn thiện các bản trình bày, chúng tôi đã gửi chúng đến Thử thách công nghệ đô thị. Ở giai đoạn này, mức độ động lực và đóng góp của mỗi người tham gia đã được bộc lộ. Nhà thiết kế của chúng tôi đã không tham gia vào các cuộc thảo luận, trả lời muộn và thậm chí còn điền thông tin về bản thân trong bài thuyết trình vào phút cuối, nói chung là nảy sinh nghi ngờ.
Kết quả là, chúng tôi đã vượt qua nhiệm vụ từ DPiIR và không hề buồn khi chúng tôi không vượt qua EFKO, vì nhiệm vụ này có vẻ xa lạ đối với chúng tôi, nói một cách nhẹ nhàng.
5. Chuẩn bị cho hackathon. Cuối cùng khi được biết rằng chúng tôi đã đủ điều kiện tham gia hackathon, chúng tôi bắt đầu chuẩn bị. Và ở đây tôi không ủng hộ việc bắt đầu viết mã một tuần trước khi bắt đầu cuộc thi hackathon. Tối thiểu, bạn nên chuẩn bị sẵn một bản soạn sẵn để bạn có thể bắt đầu làm việc ngay lập tức mà không cần phải định cấu hình các công cụ cũng như không gặp phải lỗi của một số lib mà bạn quyết định thử lần đầu tiên tại hackathon. Tôi biết một câu chuyện về các kỹ sư góc cạnh đến hackathon và dành 2 ngày để thiết lập bản dựng dự án, vì vậy mọi thứ nên được chuẩn bị trước. Chúng tôi dự định phân bổ trách nhiệm như sau: người phụ trợ viết các trình thu thập thông tin để tìm kiếm trên Internet và đưa tất cả thông tin được thu thập vào cơ sở dữ liệu, trong khi tôi viết một API trong node.js để truy vấn cơ sở dữ liệu này và gửi dữ liệu lên phía trước. Về vấn đề này, tôi đã chuẩn bị trước một máy chủ bằng cách sử dụng express.js và chuẩn bị giao diện người dùng trong React. Tôi không sử dụng CRA, tôi luôn tùy chỉnh webpack cho riêng mình và tôi biết rất rõ những rủi ro mà điều này có thể gây ra (hãy nhớ câu chuyện về các nhà phát triển góc cạnh). Tại thời điểm này, tôi đã yêu cầu các mẫu giao diện hoặc ít nhất là các mô hình từ nhà thiết kế của chúng tôi để có ý tưởng về những gì tôi sẽ trình bày. Về lý thuyết, anh ấy cũng nên tự chuẩn bị và phối hợp với chúng tôi, nhưng tôi chưa bao giờ nhận được câu trả lời. Do đó, tôi đã mượn thiết kế từ một trong những dự án cũ của mình. Và nó bắt đầu hoạt động nhanh hơn nữa, vì tất cả các phong cách cho dự án này đã được viết sẵn. Do đó kết luận: không phải lúc nào cũng cần một nhà thiết kế trong một nhóm))). Chúng tôi đến với hackathon với những phát triển này.
6. Làm việc tại hackathon. Lần đầu tiên tôi thấy đội của mình trực tiếp chỉ là lúc khai mạc hackathon tại Trung tâm phân phối trung tâm. Chúng tôi đã gặp nhau, thảo luận về giải pháp và các giai đoạn giải quyết vấn đề. Và mặc dù sau khi khai mạc phải đi xe buýt đến Tháng Mười Đỏ, chúng tôi vẫn về nhà ngủ và thống nhất sẽ đến nơi trước 9.00 giờ. Tại sao? Ban tổ chức dường như muốn thu được lợi ích tối đa từ những người tham gia nên họ đã sắp xếp một lịch trình như vậy. Tuy nhiên, theo kinh nghiệm của tôi, bạn có thể viết mã bình thường mà không cần ngủ một đêm. Còn điều thứ hai thì tôi không chắc nữa. Hackathon là một cuộc chạy marathon, bạn cần tính toán và lập kế hoạch đầy đủ cho sức mạnh của mình. Hơn nữa, chúng tôi đã có sự chuẩn bị.
Vì vậy, sau khi ngủ xong, lúc 9.00h chúng tôi đã ngồi trên tầng sáu của Dewocracy. Sau đó, nhà thiết kế của chúng tôi bất ngờ thông báo rằng anh ấy không có máy tính xách tay và anh ấy sẽ làm việc ở nhà, còn chúng tôi sẽ liên lạc qua điện thoại. Đây là rơm cuối cùng. Và thế là chúng tôi chuyển từ số bốn thành số ba, mặc dù chúng tôi không đổi tên đội. Một lần nữa, đây không phải là một cú sốc lớn đối với chúng tôi; tôi đã có thiết kế từ dự án cũ. Nhìn chung, thời gian đầu mọi việc diễn ra khá suôn sẻ và đúng kế hoạch. Chúng tôi đã tải vào cơ sở dữ liệu (chúng tôi quyết định sử dụng neo4j) tập dữ liệu về các công ty đổi mới từ ban tổ chức. Tôi bắt đầu sắp chữ, sau đó sử dụng node.js và sau đó mọi thứ bắt đầu không ổn. Tôi chưa bao giờ làm việc với neo4j trước đây và lúc đầu, tôi đang tìm kiếm một trình điều khiển hoạt động cho cơ sở dữ liệu này, sau đó tôi tìm ra cách viết một truy vấn và sau đó tôi rất ngạc nhiên khi phát hiện ra rằng cơ sở dữ liệu này, khi được truy vấn, sẽ trả về các thực thể trong dạng một mảng các đối tượng nút và các cạnh của chúng. Những thứ kia. Khi tôi yêu cầu TIN cho một tổ chức và tất cả dữ liệu trên đó, thay vì một đối tượng tổ chức, tôi được trả về một mảng dài các đối tượng chứa dữ liệu về tổ chức này và mối quan hệ giữa chúng. Tôi đã viết một trình ánh xạ đi qua toàn bộ mảng và dán tất cả các đối tượng theo cách tổ chức của chúng vào một đối tượng. Nhưng trong trận chiến, khi yêu cầu cơ sở dữ liệu của 8 nghìn tổ chức thì thực hiện cực kỳ chậm, khoảng 20 - 30 giây. Tôi bắt đầu nghĩ đến việc tối ưu hóa... Và sau đó chúng tôi dừng lại đúng lúc và chuyển sang MongoDB, chúng tôi mất khoảng 30 phút. Tổng cộng, mất khoảng 4 giờ trên neo5j.
Hãy nhớ rằng, đừng bao giờ mang công nghệ đến một cuộc thi hackathon mà bạn không quen, có thể sẽ có những điều bất ngờ. Nhưng nhìn chung, ngoài thất bại này thì mọi việc đều diễn ra theo đúng kế hoạch. Và vào sáng ngày 9 tháng XNUMX, chúng tôi đã có một ứng dụng hoạt động hoàn chỉnh. Trong thời gian còn lại của ngày, chúng tôi dự định bổ sung thêm các tính năng cho nó. Trong tương lai, mọi thứ diễn ra tương đối suôn sẻ đối với tôi, nhưng người hỗ trợ lại gặp phải rất nhiều vấn đề với việc cấm trình thu thập thông tin của anh ta trong các công cụ tìm kiếm, trong thư rác của các công cụ tổng hợp các pháp nhân, xuất hiện ở những vị trí đầu tiên trong kết quả tìm kiếm khi yêu cầu cho từng công ty cụ thể. Nhưng tốt hơn hết là anh ấy nên tự mình kể về điều đó. Tính năng bổ sung đầu tiên tôi thêm vào là tìm kiếm theo tên đầy đủ. Tổng giám đốc VKontakte. Phải mất vài giờ.
Vì vậy, trên trang của công ty trong ứng dụng của chúng tôi, hình đại diện của tổng giám đốc đã xuất hiện, một liên kết đến trang VKontakte của ông ấy và một số dữ liệu khác. Đó là một quả anh đào đẹp mắt trên chiếc bánh, mặc dù nó có thể không mang lại chiến thắng cho chúng tôi. Sau đó, tôi muốn chạy một số phân tích. Nhưng sau một thời gian dài tìm kiếm các lựa chọn (có nhiều sắc thái với giao diện người dùng), tôi đã quyết định tập hợp các tổ chức đơn giản nhất theo mã hoạt động kinh tế. Vào buổi tối, trong những giờ cuối cùng, tôi đã đặt ra một mẫu để hiển thị các sản phẩm sáng tạo (trong ứng dụng của chúng tôi đáng lẽ phải có phần Sản phẩm và Dịch vụ), mặc dù phần phụ trợ chưa sẵn sàng cho việc này. Đồng thời, cơ sở dữ liệu đang tăng vọt, các trình thu thập thông tin tiếp tục hoạt động, người phụ trợ đã thử nghiệm NLP để phân biệt các văn bản đổi mới với các văn bản không đổi mới))). Nhưng thời gian thuyết trình cuối cùng đã đến gần.
7. Trình bày. Theo kinh nghiệm của bản thân, tôi có thể nói rằng bạn nên chuyển sang chuẩn bị bài thuyết trình khoảng 3 đến 4 giờ trước thời hạn. Đặc biệt nếu liên quan đến video thì việc quay và chỉnh sửa mất khá nhiều thời gian. Đáng lẽ chúng tôi phải có một đoạn video. Và chúng tôi đã có một người đặc biệt giải quyết vấn đề này, đồng thời giải quyết một số vấn đề tổ chức khác. Về vấn đề này, chúng tôi đã không sao lãng việc viết mã cho đến giây phút cuối cùng.
8. Sân. Tôi không thích việc các bài thuyết trình và trận chung kết được tổ chức vào một ngày trong tuần riêng biệt (Thứ Hai). Ở đây, rất có thể, chính sách thu hút tối đa số người tham gia của ban tổ chức vẫn tiếp tục. Tôi không có ý định nghỉ làm, tôi chỉ muốn lọt vào trận chung kết, mặc dù các thành viên còn lại trong đội của tôi đã nghỉ làm một ngày. Tuy nhiên, cảm xúc đắm chìm trong hackathon đã lên cao đến mức vào lúc 8 giờ sáng, tôi đã viết trong cuộc trò chuyện với nhóm của mình (nhóm làm việc, không phải nhóm hackathon) rằng tôi sẽ dành cả ngày bằng chi phí của mình và đi đến trung tâm. văn phòng cho quảng cáo chiêu hàng. Vấn đề của chúng tôi hóa ra có rất nhiều nhà khoa học dữ liệu thuần túy, và điều này ảnh hưởng lớn đến cách tiếp cận giải quyết vấn đề. Nhiều người có DS tốt, nhưng không ai có nguyên mẫu hoạt động được, nhiều người không thể vượt qua lệnh cấm trình thu thập thông tin của họ trong công cụ tìm kiếm. Chúng tôi là đội duy nhất có nguyên mẫu hoạt động được. Và chúng tôi đã biết cách giải quyết vấn đề. Cuối cùng, chúng tôi đã giành chiến thắng trên đường đua, mặc dù rất may mắn khi chọn được nhiệm vụ ít cạnh tranh nhất. Nhìn vào mặt sân ở các đường đua khác, chúng tôi nhận ra rằng mình sẽ không có cơ hội ở đó. Tôi cũng muốn nói rằng chúng tôi đã rất may mắn với ban giám khảo; họ đã kiểm tra mật mã một cách tỉ mỉ. Và, theo đánh giá, điều này không xảy ra ở tất cả các bài hát.
9. Cuối cùng. Sau khi được gọi đến bồi thẩm đoàn nhiều lần để xem xét quy tắc, chúng tôi nghĩ rằng cuối cùng chúng tôi đã giải quyết được mọi vấn đề nên đã đi ăn trưa tại Burger King. Đến đó ban tổ chức gọi chúng tôi lại, chúng tôi phải nhanh chóng thu dọn đơn hàng và quay về.
Người tổ chức chỉ cho chúng tôi phòng nào cần vào, và khi bước vào, chúng tôi thấy mình đang ở trong một buổi huấn luyện nói trước công chúng dành cho các đội chiến thắng. Những người được cho là biểu diễn trên sân khấu đều được tính phí rất cao, mọi người bước ra như những nghệ sĩ biểu diễn thực thụ.
Và tôi phải thừa nhận, trong trận chung kết, trước sự góp mặt của các đội mạnh nhất từ các đường đua khác, chúng ta trông nhợt nhạt, chiến thắng trong hạng mục đề cử khách hàng chính phủ khá xứng đáng thuộc về đội công nghệ bất động sản. Tôi nghĩ rằng các yếu tố chính góp phần vào chiến thắng của chúng tôi trên đường đua là: sự sẵn có của một chiếc trống làm sẵn, nhờ đó chúng tôi có thể nhanh chóng tạo ra một nguyên mẫu, sự hiện diện của những “điểm nổi bật” trong nguyên mẫu (tìm kiếm CEO trên mạng xã hội) và kỹ năng NLP của người hỗ trợ chúng tôi, điều này cũng khiến ban giám khảo rất quan tâm.
Và cuối cùng, xin gửi lời cảm ơn truyền thống đến tất cả những người đã ủng hộ chúng tôi, ban giám khảo đường đua của chúng tôi, Evgeniy Evgrafiev (tác giả của vấn đề mà chúng tôi đã giải quyết tại hackathon) và tất nhiên là những người tổ chức hackathon. Đây có lẽ là hackathon lớn nhất và thú vị nhất mà tôi từng tham gia, tôi chỉ có thể mong các bạn sẽ giữ được tiêu chuẩn cao như vậy trong tương lai!
Nguồn: www.habr.com