Je m'appelle Dmitry. Et je veux parler de la façon dont notre équipe a atteint la finale du hackathon Urban Tech Challenge sur la piste Big Data. Je dois dire tout de suite que ce n'est pas le premier hackathon auquel j'ai participé, et pas le premier où je gagne des prix. À cet égard, dans mon histoire, je veux exprimer quelques observations générales et conclusions concernant l'industrie du hackathon dans son ensemble, et donner mon point de vue par opposition aux critiques négatives qui sont apparues sur le réseau juste après la fin de l'Urban Tech Challenge (par exemple
celui-ci ).
Donc, tout d'abord, quelques observations générales.
1. Il est surprenant que beaucoup de gens pensent naïvement qu'un hackathon est une sorte de compétition sportive où les meilleurs codeurs gagnent. Ce n'est pas le cas. Je ne considère pas les cas où les organisateurs du hackathon eux-mêmes ne savent pas ce qu'ils veulent (je l'ai vu aussi). Mais, en règle générale, une entreprise qui organise un hackathon poursuit ses objectifs. Leur liste peut être différente: elle peut être une solution technique à certains problèmes, la recherche de nouvelles idées et de nouvelles personnes, etc. Ces objectifs déterminent souvent le format de l'événement, son calendrier, en ligne / hors ligne, comment les tâches seront formulées (et si elles seront formulées du tout), s'il y aura une révision du code sur le hackathon, etc. Les équipes et ce qu'elles ont fait sont évaluées précisément de ce point de vue. Et les équipes qui parviennent le mieux au point dont l'entreprise a besoin gagnent, et beaucoup y arrivent complètement inconsciemment et accidentellement, pensant qu'elles participent vraiment à une compétition sportive. Mes observations montrent que pour motiver les participants, les organisateurs devraient créer au moins l'apparence d'un environnement sportif et des conditions égales, sinon ils recevront une vague de négativité, comme dans la revue ci-dessus. Mais nous nous sommes égarés.
2. D'où la conclusion suivante. Les organisateurs sont intéressés à ce que les participants viennent au hackathon avec leurs propres idées, parfois même une étape de correspondance en ligne est spécialement organisée pour cela. Cela permet des solutions de sortie plus solides. Le concept de «leur propre travail» est très relatif, tout programmeur expérimenté peut accumuler des milliers de lignes de code de ses anciens projets lors du premier commit. Et ce sera un temps de fonctionnement pré-préparé? Mais en tout cas, la règle s'applique, que j'ai exprimée sous la forme d'un mème célèbre:
Pour gagner, vous devez avoir quelque chose, une sorte d'avantage compétitif: un projet similaire que vous avez fait dans le passé, des connaissances et de l'expérience dans un sujet spécifique, ou un travail déjà terminé avant le début du hackathon. Oui, ce n'est pas du sport. Oui, cela peut ne pas rembourser l'effort (ici, tout le monde décide de coder 3 semaines la nuit pour un prix de 100 mille, divisé par toute l'équipe, et même avec le risque de ne pas l'obtenir). Mais, souvent, c'est la seule chance d'aller de l'avant.
3. Sélection de l'équipe. Comme je l'ai remarqué lors des discussions de hackathon, beaucoup de gens prennent ce problème plutôt à la légère (bien que ce soit la décision la plus importante qui déterminera votre résultat au hackathon). Dans de nombreux domaines d'activité (à la fois dans les sports et les hackathons), j'ai vu que les gens forts ont tendance à s'unir avec les forts, les faibles avec les faibles, les intelligents avec les intelligents, eh bien, en général, vous comprenez ... C'est ce qui se passe dans les salles de chat: des programmeurs plus ou moins forts tout de suite, les gens qui n'ont pas de compétences précieuses en hackathon restent longtemps dans le chat et choisissent une équipe selon le principe si seulement quelqu'un l'a pris. Dans certains hackathons, une répartition aléatoire entre les équipes est pratiquée, et les organisateurs affirment que les équipes aléatoires ne donnent pas de résultat pire que celles déjà établies. Mais selon mes observations, les personnes motivées, en règle générale, trouvent l'équipe elles-mêmes, si quelqu'un doit être distribué, alors souvent beaucoup d'entre eux ne viennent pas au hackathon.
Quant à la composition de l'équipe, elle est très individuelle et très dépendante de la tâche. Je pourrais dire que l'équipe minimum viable est un concepteur - front-end ou front-end - back-end. Mais je connais également des cas où des équipes constituées uniquement de front-end ont gagné, qui ont attaché un simple back-end à node.js, ou ont fait une application mobile sur React Native; ou seulement de beckenders qui ont fait une mise en page simple En général, tout est très individuel et dépend de la tâche. Mon plan pour sélectionner une équipe pour le hackathon était le suivant: je prévoyais de constituer une équipe ou de rejoindre une équipe comme designer front-end-back-end (je suis moi-même devant). Et assez rapidement, il a commencé à discuter avec un back-end en python et un designer qui a accepté l'invitation à nous rejoindre. Un peu plus tard, une analyste d'entreprise nous a rejoint, qui avait déjà l'expérience de gagner le hackathon, et cela a décidé de la rejoindre. Après une courte réunion, nous avons décidé de nous appeler U4 (URBAN 4, urban four) similaire au fantastique quatre. Et ils ont même mis une image correspondante sur notre chaîne de télégramme.
4. Choix de la tâche. Comme je l'ai dit, vous devriez avoir un avantage concurrentiel, la tâche du hackathon est choisie en fonction de cela. Partant de là, après avoir examiné la
liste des tâches et évalué leur complexité, nous nous sommes fixés sur deux tâches: un catalogue d'entreprises innovantes de DPiIR et un chat bot d'EFKO. La tâche de l'Institut de développement industriel et industriel a été choisie par le backender, la tâche d'EFKO a été choisie par moi, car avait de l'expérience dans l'écriture de chatbots sur node.js et DialogFlow. La tâche EFKO impliquait également le ML, j'ai une expérience, pas très grande, en ML. Et selon les conditions du problème, il m'a semblé qu'il était à peine résolu au moyen du ML. Ce sentiment s'est renforcé lorsque je suis allé à la réunion Urban Tech Challenge, où les organisateurs m'ont montré un ensemble de données EFCO, où il y avait environ 100 photos de présentations de produits (prises sous différents angles) et environ 20 classes d'erreurs de présentation. Et en même temps, les clients de la tâche souhaitaient un taux de réussite de classement de 90%. En conséquence, j'ai préparé la présentation de la solution sans ML, le backender a préparé la présentation selon le catalogue, et ensemble, après avoir finalisé les présentations, nous les avons envoyées au Urban Tech Challenge. Déjà à ce stade, le niveau de motivation et de contribution de chaque participant a été révélé. Notre designer n'a pas pris part aux discussions, a répondu tard et a même renseigné des informations sur lui-même dans la présentation au tout dernier moment, en général des doutes ont surgi.
En conséquence, nous avons effectué la tâche du Département de la construction et du design, et nous n'étions pas du tout contrariés de ne pas avoir passé par EFKO, car la tâche nous semblait, pour le dire légèrement, étrange.
5. Préparation pour le hackathon. Quand on a finalement su que nous étions allés au hackathon, nous avons commencé à préparer la pièce. Et ici, je ne vous invite pas à commencer à écrire du code une semaine avant le début du hackathon. Au minimum, vous devriez avoir un passe-partout prêt, avec lequel vous pouvez immédiatement vous mettre au travail sans avoir à régler les outils, et sans tomber sur des bugs de toute nature que vous décidez d'essayer pour la première fois sur un hackathon. Je connais une histoire de pêcheurs qui sont venus au hackathon et ont passé 2 jours à mettre en place l'assemblage du projet, donc tout doit être préparé à l'avance. Nous devions répartir les tâches comme suit: le bekender écrit des robots d'exploration qui analysent Internet et mettent toutes les informations collectées dans la base de données, j'écris l'API sur node.js, qui demande cette base de données et envoie les données au front. À cet égard, j'ai préparé le serveur à l'avance sur express.js et préparé le frontend sur react. Je n'utilise pas CRA, je personnalise toujours le webpack pour moi et je sais très bien quels risques cela peut impliquer (nous nous souvenons de l'histoire des pêcheurs). À ce moment, j'ai demandé des blancs d'interface, ou du moins des maquettes à notre designer, afin d'avoir une idée de ce que j'imposerais. En théorie, lui aussi devrait faire ses préparatifs et les coordonner avec nous, mais je n'ai jamais reçu de réponse. En conséquence, j'ai emprunté le design à l'un de mes anciens projets. Et donc ça a commencé à tourner encore plus vite, puisque tous les styles de ce projet étaient déjà écrits. D'où la conclusion: le designer n'est pas toujours nécessaire dans l'équipe))). Avec ces développements, nous sommes arrivés au hackathon.
6. Travaillez sur le hackathon. J'ai vu mon équipe pour la première fois seulement lors de l'ouverture du hackathon dans le CDP. Nous nous sommes rencontrés, avons discuté de la solution et des étapes du travail sur la tâche. Et bien qu'après l'ouverture nous ayons dû prendre des bus pour octobre rouge, nous sommes rentrés chez nous pour dormir, ayant accepté de venir chez nous avant 9h00. Pourquoi? Les organisateurs, apparemment, voulaient tirer le meilleur parti des participants, alors ils ont organisé un tel calendrier. Mais, d'après mon expérience, vous pouvez normalement coder sans dormir une nuit. Quant au second, je ne suis plus sûr. Le hackathon est un marathon, vous devez calculer et planifier correctement votre force. De plus, nous avions des blancs.
Par conséquent, après avoir dormi, à 9 heures, nous étions assis au sixième étage de la Dewocracy. Ensuite, notre designer a annoncé de façon inattendue qu'il n'avait pas d'ordinateur portable, qu'il travaillerait à domicile et que nous communiquerions par téléphone. Ce fut la dernière goutte. Et donc nous sommes passés de quatre à trois, bien que nous n'ayons pas changé le nom de l'équipe. Encore une fois, cela n'a pas été un coup dur pour nous, j'avais déjà le design de l'ancien projet. En général, au début, tout s'est bien passé et comme prévu. Nous avons téléchargé un ensemble de données d'entreprises innovantes des organisateurs dans la base de données (nous avons décidé d'utiliser neo4j). J'ai commencé à composer, puis j'ai pris node.js, puis des ratés se sont produits. Je n'avais jamais travaillé avec neo4j auparavant, et j'ai d'abord cherché un pilote de travail pour cette base de données, puis j'ai compris comment la requête était écrite, puis j'ai été surpris de constater que cette base de données renvoyait des entités à la demande, sous la forme d'un tableau d'objets de nœud et de leurs bords. C'est-à-dire lorsque j'ai demandé l'organisation par TIN et toutes les données qu'il contient, au lieu d'un seul objet d'organisation, j'ai renvoyé un long tableau d'objets contenant des données sur cette organisation et la relation entre eux. J'ai écrit un mappeur qui a traversé l'ensemble du tableau et collé tous les objets de l'organisation en un seul objet. Mais au combat, lors de l'interrogation d'une base de données de 8 000 organisations, cela a été extrêmement lent pendant environ 20 à 30 secondes. J'ai pensé à l'optimisation ... Et puis nous nous sommes arrêtés à temps et nous sommes passés à MongoDB, et cela nous a pris environ 30 minutes. Un total d'environ 5 heures a été perdu sur neo4j.
N'oubliez pas, n'acceptez jamais une technologie de hackathon que vous ne connaissez pas, il peut y avoir des surprises. Mais, en général, à part cet échec, tout s'est passé comme prévu. Et déjà dans la matinée du 9 décembre, nous avions une application pleinement fonctionnelle. Pour le reste de la journée, nous avions prévu d'enrouler des fonctionnalités supplémentaires. À l'avenir, tout s'est relativement bien passé, mais le bekender a eu tout un tas de problèmes avec l'interdiction de ses robots d'exploration dans les moteurs de recherche, dans le spam des agrégateurs d'entités juridiques, qui est venu en premier lieu des résultats de recherche lors de la demande pour chaque entreprise spécifique. Mais il en parlera mieux. La première fonctionnalité supplémentaire que j'ai ratée est une recherche par nom complet PDG VKontakte. Cela a pris plusieurs heures.
Ainsi, sur la page de l'entreprise dans notre application, est apparu l'ava du directeur général, un lien vers sa page VK et d'autres données. C'était une bonne cerise sur le gâteau, même si cela ne nous a peut-être pas permis de remporter la victoire. Ensuite, j'ai voulu conclure quelques analyses. Mais après une longue recherche d'options (il y avait beaucoup de nuances avec l'interface utilisateur), il a opté pour l'agrégation la plus simple des organisations par code d'activité économique. Déjà le soir, dans les dernières heures, je faisais un blanc pour afficher des produits innovants (la section Produits et Services est supposée dans notre application), bien que le backend pour cela n'était pas prêt. La base était en même temps gonflée de pas de géant, les crawlers ont continué à travailler, le back-end a expérimenté la PNL pour distinguer les textes innovants des textes non innovants)))). Mais il était déjà temps pour la présentation finale.
7. Présentation. D'après ma propre expérience, je peux dire que vous devriez passer à la préparation d'une présentation quelque part 3-4 heures avant sa livraison. Surtout si la vidéo est censée y être, le tournage et le montage prennent beaucoup de temps. Nous étions censés avoir une vidéo. Et nous avions une personne spéciale qui s'occupait de cela et qui a également résolu un certain nombre d'autres problèmes d'organisation. À cet égard, jusqu'au tout dernier moment, nous n'avons pas été distraits du codage.
8. Pitch. Je n'ai pas aimé que les présentations et la finale aient été faites un jour de semaine séparé (lundi). Ici, très probablement, les organisateurs ont poursuivi la politique consistant à tirer le maximum des participants. Je n'avais pas prévu de m'absenter du travail, je ne voulais venir qu'en finale, même si le reste de mon équipe a pris un week-end. Cependant, l'immersion émotionnelle dans le hackathon était déjà si élevée qu'à 8 heures du matin, j'ai écrit au chat de mon équipe (travaillant, pas à l'équipe du hackathon) que j'ai pris la journée à mes frais et que je suis allé au CDC pour les emplacements. Notre problème s'est avéré être un grand nombre de données purement scientifiques, ce qui a grandement affecté l'approche de résolution du problème. Beaucoup avaient une bonne DS, mais personne n'avait de prototype fonctionnel, beaucoup ne pouvaient pas contourner l'interdiction de leurs robots dans les moteurs de recherche. Nous étions la seule équipe avec un prototype fonctionnel. Et nous savions comment résoudre la tâche. Au final, nous avons gagné la piste, même si nous avons eu beaucoup de chance d'avoir choisi la tâche la moins compétitive. En regardant les emplacements dans d'autres pistes, nous avons réalisé que nous n'aurions aucune chance là-bas. Je veux aussi dire que nous avons eu beaucoup de chance avec le jury, ils ont méticuleusement vérifié le code. Et, à en juger par les critiques, cela était loin de se produire sur toutes les pistes.
9. La finale. Après avoir été appelé plusieurs fois au jury pour une révision du code, nous pensions avoir finalement résolu tous les problèmes et nous sommes allés dîner chez Burger King. Là, les organisateurs nous ont rappelé, nous avons dû emballer les commandes à la hâte et revenir.
L'organisateur a montré dans quelle pièce aller et, nous y sommes rendus, nous nous sommes retrouvés dans une formation de prise de parole en public pour les équipes gagnantes. Les gars qui étaient censés se produire sur scène étaient bien chargés, tout le monde s'est fait passer pour de vrais showmen.
Et je dois avouer, en finale, sur fond des équipes les plus fortes des autres pistes, que nous avions l'air pâle, la victoire dans la nomination du client de l'Etat a à juste titre quitté l'équipe de la piste de l'immobilier technique. Je pense que les facteurs clés qui ont contribué à notre victoire sur la piste étaient: la disponibilité d'un blank prêt à l'emploi, grâce auquel nous avons pu réaliser rapidement un prototype, la présence de «zeste» dans le prototype (recherche de directeurs généraux sur les réseaux sociaux) et les compétences PNL de notre backender qui sont également très intéressés par le jury.
Et en guise de remerciement traditionnel à tous ceux qui nous ont soutenus, au jury de notre piste, Evgeny Evgrafiev (l'auteur de la tâche que nous avons résolue lors du hackathon) et, bien sûr, aux organisateurs du hackathon. C'était peut-être le hackathon le plus grand et le plus cool auquel j'ai participé, il ne reste plus qu'à souhaiter aux gars de garder une marque aussi haute et plus encore!