Urban Tech Challenge 해커톤에서 빅 데이터 트랙을 수상한 방법과 이유

제 이름은 드미트리입니다. 그리고 우리 팀이 어떻게 빅 데이터 트랙에서 Urban Tech Challenge 해커톤 결승에 진출했는지 이야기하고 싶습니다. 제가 참가한 첫 해커톤도 아니고, 처음으로 상을 받은 것도 아니라는 점을 바로 말씀드리겠습니다. 이와 관련하여 제 이야기에서는 해커톤 산업 전체에 대한 몇 가지 일반적인 관찰과 결론을 말하고 Urban Tech Challenge가 끝난 직후 온라인에 나타난 부정적인 리뷰와는 반대되는 제 관점을 제시하고 싶습니다. 예 이).

먼저 몇 가지 일반적인 관찰을 살펴보겠습니다.

1. 해커톤이 최고의 코더가 승리하는 일종의 스포츠 대회라고 순진하게 생각하는 사람들이 적지 않다는 사실이 놀랍습니다. 이것은 잘못된 것입니다. 나는 해커톤 주최자가 자신이 원하는 것이 무엇인지 모르는 경우는 고려하지 않습니다(저도 그런 경우를 보았습니다). 하지만 원칙적으로 해커톤을 주최하는 회사는 자체 목표를 추구합니다. 목록은 다를 수 있습니다. 일부 문제에 대한 기술적 솔루션, 새로운 아이디어 및 인력 검색 등이 될 수 있습니다. 이러한 목표는 종종 이벤트 형식, 시기, 온라인/오프라인, 작업 구성 방법(및 공식화 여부), 해커톤에서 코드 검토 여부 등을 결정합니다. 팀과 그들이 한 일 모두 이러한 관점에서 평가됩니다. 그리고 회사가 필요로 하는 지점에 가장 잘 도달하는 팀이 승리하며, 많은 사람들이 완전히 무의식적으로 그리고 우연히 이 지점에 도달하여 실제로 스포츠 대회에 참가하고 있다고 생각합니다. 내 관찰에 따르면 참가자들에게 동기를 부여하기 위해 주최측은 최소한 스포츠 환경과 평등한 조건을 조성해야 합니다. 그렇지 않으면 위의 리뷰에서처럼 부정적인 물결을 받게 될 것입니다. 그러나 우리는 빗나간다.

2. 따라서 다음과 같은 결론이 나옵니다. 주최측은 참가자들이 자신의 작업을 가지고 해커톤에 참가하는 데 관심이 있으며 때로는 이러한 목적을 위해 특별히 온라인 통신 단계를 구성하기도 합니다. 이를 통해 더 강력한 출력 솔루션이 가능해졌습니다. "자체 작업"이라는 개념은 매우 상대적인 개념입니다. 숙련된 개발자라면 누구나 첫 번째 커밋에서 이전 프로젝트의 수천 줄의 코드를 축적할 수 있습니다. 그리고 이것이 사전 준비된 개발일까요? 그러나 어떤 경우에도 규칙이 적용됩니다. 저는 이를 유명한 밈의 형태로 표현했습니다.

승리하려면 과거에 수행했던 유사한 프로젝트, 특정 주제에 대한 지식과 경험, 해커톤 시작 전에 이미 완료된 작업 등 무언가, 일종의 경쟁 우위가 있어야 합니다. 예, 스포츠가 아닙니다. 예, 이것은 들인 노력의 가치가 없을 수도 있습니다. (여기서는 3만 달러의 상금을 위해 밤에 100주 동안 코딩할 가치가 있는지 여부를 모든 사람이 스스로 결정합니다. 상금은 전체 팀에 나누어지고 상금을 받지 못할 위험도 있습니다). 그러나 종종 이것이 앞으로 나아갈 수 있는 유일한 기회입니다.

3. 팀 선택. 제가 해커톤 채팅에서 알 수 있듯이 많은 사람들이 이 문제에 아주 경솔하게 접근합니다(비록 이것이 해커톤에서의 결과를 결정하는 가장 중요한 결정이기는 하지만). 많은 활동 영역(스포츠와 해커톤 모두)에서 저는 강한 사람들이 강한 사람들과 연합하고, 약한 사람들과 약한 사람들, 똑똑한 사람들과 똑똑한 사람들이 연합하는 경향이 있다는 것을 보았습니다. 글쎄요, 일반적으로 이해가 되실 겁니다... 이것은 대략 채팅에서 일어나는 일입니다. 덜 강력한 프로그래머는 즉시 쫓겨나고, 해커톤에 필요한 기술이 없는 사람들은 오랫동안 채팅에 매달려 누군가가 그것을 받아들인다는 원칙에 따라 팀을 선택합니다. . 일부 해커톤에서는 무작위로 팀을 배정하는 방식이 시행되고 있으며, 주최측에서는 무작위로 구성된 팀이 기존 팀보다 나쁘지 않은 성과를 거두고 있다고 주장합니다. 그러나 내 관찰에 따르면 의욕이 있는 사람들은 원칙적으로 스스로 팀을 찾고, 누군가를 배정해야 한다면 그들 중 많은 사람들이 해커톤에 참석하지 않는 경우가 많습니다.

팀 구성은 매우 개별적이며 작업에 대한 의존도가 높습니다. 최소한의 실행 가능한 팀 구성은 디자이너 - 프론트엔드 또는 프론트엔드 - 백엔드라고 말할 수 있습니다. 하지만 저는 node.js에 간단한 백엔드를 추가하거나 React Native에서 모바일 애플리케이션을 만든 프론트엔더로만 구성된 팀이 승리한 경우도 알고 있습니다. 또는 간단한 레이아웃을 수행한 백엔더에서만 가능합니다. 일반적으로 모든 것은 매우 개별적이며 작업에 따라 다릅니다. 해커톤에 참가하기 위한 팀 선발 계획은 다음과 같았습니다. 프론트엔드-백엔드-디자이너(저도 프론트엔드입니다) 식으로 팀을 구성하거나 팀에 가입할 계획이었습니다. 그리고 꽤 빨리 우리와 함께하라는 초대를 수락한 Python 백엔더 및 디자이너와 채팅을 시작했습니다. 얼마 후, 이미 해커톤 우승 경험이 있는 비즈니스 분석가인 소녀가 우리에게 합류했고, 이것이 그녀의 합류 문제를 결정했습니다. 짧은 회의 끝에 우리는 Fantastic Four에 비유하여 U4(URBAN 4, Urban Four)라고 부르기로 결정했습니다. 그리고 그들은 심지어 우리 텔레그램 채널의 아바타에 해당 사진을 올렸습니다.

4. 작업 선택. 앞서 말했듯이 경쟁 우위가 있어야 하고, 이를 바탕으로 해커톤 과제가 선정됩니다. 이를 토대로 살펴보니 작업 목록 그 복잡성을 평가하면서 우리는 DPiIR의 혁신적인 기업 카탈로그와 EFKO의 챗봇이라는 두 가지 작업을 결정했습니다. DPIiR의 작업은 백엔더가 선택했고, EFKO의 작업은 제가 선택했습니다. node.js와 DialogFlow에서 챗봇을 작성한 경험이 있습니다. EFKO 작업에는 ML도 포함되었습니다. 저는 ML에 대한 경험이 그리 광범위하지는 않지만 어느 정도 있습니다. 그리고 문제의 조건에 따라 ML 도구를 사용하여 해결될 가능성은 거의 없어 보였습니다. 이 느낌은 제가 Urban Tech Challenge 모임에 갔을 때 더욱 강해졌습니다. 그곳에서 주최측은 약 100장의 제품 레이아웃 사진(다양한 각도에서 촬영)과 약 20개 클래스의 레이아웃 오류가 있는 EFKO에 대한 데이터세트를 보여주었습니다. 그리고 동시에 해당 작업을 지시한 사람들은 90%의 분류 성공률을 달성하기를 원했습니다. 그 결과 나는 ML 없이 솔루션 프레젠테이션을 준비했고, 백엔더는 카탈로그를 기반으로 프레젠테이션을 준비했으며, 함께 프레젠테이션을 마무리한 후 Urban Tech Challenge에 보냈습니다. 이미 이 단계에서 각 참가자의 동기와 기여 수준이 공개되었습니다. 우리 디자이너는 토론에 참여하지 않았고 늦게 응답했으며 심지어 마지막 순간에 프레젠테이션에서 자신에 대한 정보를 작성하는 등 일반적으로 의심이 생겼습니다.

결과적으로 우리는 DPiIR의 작업을 통과했으며 EFKO를 통과하지 못한 것에 대해 전혀 화를 내지 않았습니다. 가볍게 말하면 작업이 우리에게 이상해 보였기 때문입니다.

5. 해커톤을 준비합니다. 마침내 우리가 해커톤에 참가할 자격이 있다는 사실이 알려졌을 때, 우리는 준비를 시작했습니다. 그리고 여기서 나는 해커톤이 시작되기 일주일 전에 코드 작성을 시작하는 것을 옹호하는 것이 아닙니다. 최소한 도구를 구성할 필요 없이, 그리고 해커톤에서 처음 시도하기로 결정한 일부 lib의 버그에 부딪히지 않고 즉시 작업을 시작할 수 있는 상용구가 준비되어 있어야 합니다. 해커톤에 와서 프로젝트 빌드를 설정하는 데 이틀을 소비한 각도 엔지니어에 대한 이야기를 알고 있으므로 모든 것이 미리 준비되어야 합니다. 우리는 다음과 같이 책임을 분배하려고 했습니다. 백엔더는 인터넷을 샅샅이 뒤져 수집된 모든 정보를 데이터베이스에 저장하는 크롤러를 작성하고, 나는 이 데이터베이스를 쿼리하고 데이터를 전면으로 보내는 API를 node.js에 작성합니다. 이에 대비하여 express.js를 이용하여 서버를 미리 준비하였고, React에서는 프론트엔드를 준비하였습니다. 저는 CRA를 사용하지 않고 항상 웹팩을 맞춤설정하며 이로 인해 발생할 수 있는 위험이 무엇인지 잘 알고 있습니다(Angular 개발자에 대한 이야기를 기억하세요). 이 시점에서 나는 무엇을 배치할지에 대한 아이디어를 얻기 위해 디자이너에게 인터페이스 템플릿이나 최소한 모형을 요청했습니다. 이론적으로는 그도 스스로 준비하고 우리와 조율해야 하는데, 저는 아직 답변을 받지 못했습니다. 결과적으로 저는 예전 프로젝트 중 하나에서 디자인을 빌렸습니다. 그리고 이 프로젝트의 모든 스타일이 이미 작성되었기 때문에 작업 속도는 더욱 빨라졌습니다. 따라서 결론은 팀에 디자이너가 항상 필요한 것은 아닙니다.))). 우리는 이러한 발전을 가지고 해커톤에 왔습니다.

6. 해커톤에서 일해보세요. 우리 팀을 처음 본 것은 중앙 유통 센터에서 열린 해커톤 개막식에서였습니다. 우리는 문제 해결의 해결책과 단계를 만나 논의했습니다. 그리고 개장 후 우리는 버스를 타고 Red October까지 가야했지만 집에 가서 잠을 자고 9.00시까지 그곳에 도착하기로 동의했습니다. 왜? 주최측은 참가자들을 최대한 활용하고 싶어서 그런 일정을 마련했습니다. 하지만 제 경험상 하룻밤 자지 않고도 정상적으로 코딩이 가능합니다. 두 번째에 관해서는 더 이상 확실하지 않습니다. 해커톤은 마라톤이므로 자신의 힘을 적절히 계산하고 계획해야 합니다. 게다가 준비도 있었어요.

그래서 잠을 자고 9.00시에 우리는 Dewocracy의 4층에 앉아 있었습니다. 그러다가 우리 디자이너가 예기치 않게 그에게 노트북이 없고 집에서 일할 것이며 우리는 전화로 소통하겠다고 발표했습니다. 이것이 마지막 빨대였습니다. 그래서 우리는 팀 이름을 바꾸지는 않았지만 4에서 8으로 바뀌었습니다. 다시 말하지만, 이것은 우리에게 큰 타격이 아니었습니다. 나는 이미 이전 프로젝트의 디자인을 가지고 있었습니다. 일반적으로 처음에는 모든 것이 계획대로 순조롭게 진행되었습니다. 우리는 주최측의 혁신적인 기업 데이터 세트를 데이터베이스에 로드했습니다(neo20j를 사용하기로 결정했습니다). 조판을 시작한 다음 node.js를 사용했는데 문제가 발생하기 시작했습니다. 저는 이전에 neo30j를 사용해본 적이 없었으며 처음에는 이 데이터베이스에 대해 작동하는 드라이버를 찾고 있었습니다. 그런 다음 쿼리를 작성하는 방법을 알아냈고 그런 다음 이 데이터베이스가 쿼리될 때 엔터티를 반환한다는 사실에 놀랐습니다. 노드 객체와 그 가장자리의 배열 형태. 저것들. 하나의 조직 개체 대신 TIN으로 조직과 그에 대한 모든 데이터를 요청했을 때 이 조직과 조직 간의 관계에 대한 데이터가 포함된 긴 개체 배열이 반환되었습니다. 나는 전체 배열을 살펴보고 조직에 따라 모든 객체를 하나의 객체로 묶는 매퍼를 작성했습니다. 그런데 전투에서 30개 조직의 데이터베이스를 요청하면 4~5초 정도의 극히 느린 속도로 실행되었다. 최적화에 대해 고민하기 시작했는데... 그러다가 시간에 맞춰 멈추고 MongoDB로 전환했는데 약 XNUMX분 정도 걸렸습니다. 전체적으로 neoXNUMXj에서는 약 XNUMX시간이 손실되었습니다.

익숙하지 않은 해커톤에 기술을 사용하지 마십시오. 예상치 못한 일이 발생할 수 있습니다. 그러나 일반적으로 이러한 실패를 제외하면 모든 것이 계획대로 진행되었습니다. 그리고 이미 9월 XNUMX일 아침에 우리는 완전히 작동하는 애플리케이션을 갖게 되었습니다. 남은 하루 동안 우리는 여기에 추가 기능을 추가할 계획이었습니다. 앞으로는 모든 것이 상대적으로 순조롭게 진행되었지만 백엔더는 검색 엔진에서 크롤러를 금지하고 요청할 때 검색 결과의 첫 번째 위치에 나오는 법인 수집기 스팸에서 많은 문제를 겪었습니다. 특정 회사마다. 하지만 그 사람이 직접 이야기하는 것이 더 낫습니다. 제가 추가한 첫 번째 추가 기능은 이름으로 검색하는 것이었습니다. VKontakte의 총책임자. 몇 시간이 걸렸습니다.

따라서 우리 응용 프로그램의 회사 페이지에는 총책임자의 아바타, 그의 VKontakte 페이지에 대한 링크 및 기타 데이터가 나타났습니다. 그것은 우리에게 승리를 안겨주었을 수도 있지만 케이크 위의 멋진 체리였습니다. 그런 다음 몇 가지 분석을 실행하고 싶었습니다. 그러나 옵션을 오랫동안 검색한 끝에(UI에는 미묘한 차이가 많았습니다) 경제 활동 코드별로 가장 간단한 조직 집합을 결정했습니다. 이미 저녁, 지난 몇 시간 동안 저는 혁신적인 제품을 표시하기 위한 템플릿을 레이아웃하고 있었지만(우리 애플리케이션에는 제품 및 서비스 섹션이 있어야 했습니다) 백엔드는 이를 위한 준비가 되어 있지 않았습니다. 동시에 데이터베이스는 비약적으로 팽창했고 크롤러는 계속 작동했으며 백엔더는 혁신적인 텍스트와 비혁신적인 텍스트를 구별하기 위해 NLP를 실험했습니다.))). 하지만 이미 최종 발표 시간이 다가오고 있었습니다.

7. 프레젠테이션. 내 경험에 따르면 마감 시간 약 3~4시간 전에 프레젠테이션 준비로 전환해야 한다고 말할 수 있습니다. 특히 영상이 포함된 경우에는 촬영과 편집에 상당한 시간이 소요됩니다. 우리는 비디오를 찍기로 되어 있었습니다. 그리고 우리에게는 이 문제를 처리하고 다른 여러 조직 문제도 해결한 특별한 사람이 있었습니다. 이런 점에서 우리는 마지막 순간까지 코딩에 집중하지 않았습니다.

8. 피치. 발표회와 결승전이 별도의 평일(월요일)에 열리는 것이 마음에 들지 않았습니다. 여기서는 참가자들의 최대치를 압박하려는 주최측의 정책이 계속되었을 가능성이 큽니다. 나는 직장을 쉴 계획이 없었고, 나머지 팀원들이 하루를 쉬었음에도 불구하고 결승전에만 오르고 싶었습니다. 하지만 해커톤에 대한 감성적 몰입도는 이미 너무 높아서 오전 8시에 우리 팀(해커톤 팀이 아닌 작업팀) 채팅에 하루는 자비로 쓴다고 쓰고 중앙으로 갔습니다. 경기장 사무실. 우리 문제에는 순수 데이터 과학자가 많은 것으로 밝혀졌고 이는 문제 해결에 대한 접근 방식에 큰 영향을 미쳤습니다. 많은 사람들이 좋은 DS를 가지고 있었지만 제대로 작동하는 프로토타입을 가진 사람은 아무도 없었으며, 많은 사람들이 검색 엔진에서 크롤러 금지를 피할 수 없었습니다. 우리는 작동하는 프로토타입을 갖춘 유일한 팀이었습니다. 그리고 우리는 문제를 해결하는 방법을 알고 있었습니다. 결국 우리는 트랙에서 우승했습니다. 비록 운이 좋게도 경쟁이 가장 적은 작업을 선택한 것이었지만요. 다른 트랙의 피치를 살펴보면서 우리는 그곳에서는 기회가 없다는 것을 깨달았습니다. 또한 심사위원단이 코드를 꼼꼼하게 확인했기 때문에 운이 좋았다고 말하고 싶습니다. 그리고 리뷰에 따르면 이것은 모든 트랙에서 발생하지 않았습니다.

9. 최종. 코드 검토를 위해 심사위원단에 여러 번 호출된 후, 마침내 모든 문제가 해결되었다고 생각한 우리는 버거킹에 점심을 먹으러 갔습니다. 그곳에서 주최자가 다시 우리에게 전화를 걸어 우리는 주문한 음식을 빨리 포장하고 돌아가야 했습니다.

주최자는 우리가 어느 방에 들어가야 하는지 보여줬고, 들어가자마자 우리는 우승팀을 위한 대중 연설 훈련 세션에 있었습니다. 무대에 오르기로 한 남자들은 늠름하게 흥을 돋우고, 모두가 진짜 쇼맨처럼 나왔다.

그리고 결승전에서 다른 트랙의 가장 강력한 팀을 배경으로 우리의 모습이 창백해 보였음을 인정해야 합니다. 정부 고객 지명에서 승리한 것은 당연하게도 부동산 기술 트랙의 팀이 차지했습니다. 트랙에서 우리가 승리할 수 있었던 주요 요인은 바로 프로토타입을 신속하게 만들 수 있었던 기성 블랭크의 가용성, 프로토타입에 "하이라이트"가 있다는 점이었습니다(CEO 검색). 소셜 네트워크) 및 우리 백엔더의 NLP 기술은 심사위원단의 큰 관심을 끌었습니다.

결론적으로, 우리를 지지해주신 모든 분들, 우리 트랙의 심사위원단, Evgeniy Evgrafiev(우리가 해커톤에서 해결한 문제의 작성자), 그리고 물론 해커톤 주최자들에게 전통적으로 감사드립니다. 이것은 아마도 제가 참가한 해커톤 중 가장 크고 멋진 해커톤이었을 것입니다. 앞으로도 이 사람들이 이렇게 높은 기준을 유지하기를 바랄 뿐입니다!

출처 : habr.com