Je m'appelle Dmitri. 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 dirai tout de suite que ce n'est pas le premier hackathon auquel je participe, ni le premier auquel je remporte des prix. À cet égard, dans mon histoire, je souhaite exprimer quelques observations et conclusions générales concernant l'industrie du hackathon dans son ensemble, et donner mon point de vue par opposition aux critiques négatives apparues en ligne immédiatement après la fin de l'Urban Tech Challenge (par exemple exemple ).
Alors 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ù gagnent les meilleurs codeurs. C'est faux. 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, l'entreprise qui organise un hackathon poursuit ses propres objectifs. Leur liste peut être différente : il peut s'agir d'une solution technique à certains problèmes, d'une recherche de nouvelles idées et de nouvelles personnes, etc. Ces objectifs déterminent souvent le format de l'événement, son timing, en ligne/hors ligne, la manière dont les tâches seront formulées (et si elles le seront), s'il y aura une révision de code lors du hackathon, etc. Les équipes et leurs réalisations sont évaluées de ce point de vue. Et les équipes qui atteignent le mieux le point dont l'entreprise a besoin gagnent, et beaucoup y arrivent de manière complètement inconsciemment et par accident, pensant qu'elles participent réellement à une compétition sportive. Mes observations montrent que pour motiver les participants, les organisateurs doivent créer au moins l'apparence d'un environnement sportif et de conditions égales, sinon ils recevront une vague de négativité, comme dans l'analyse ci-dessus. Mais nous nous éloignons.
2. D'où la conclusion suivante. Les organisateurs souhaitent que les participants viennent au hackathon avec leur propre travail, parfois ils organisent même spécialement une étape de correspondance en ligne à cet effet. Cela permet des solutions de sortie plus solides. La notion de « travail personnel » est très relative : tout développeur expérimenté peut accumuler des milliers de lignes de code issues de ses anciens projets lors de son premier commit. Et s’agira-t-il d’un développement préparé à l’avance ? Mais dans tous les 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 concurrentiel : un projet similaire à celui que vous avez réalisé dans le passé, des connaissances et de l'expérience dans un sujet spécifique, ou un travail prêt à l'emploi réalisé avant le début du hackathon. Oui, ce n'est pas sportif. Oui, cela n'en vaut peut-être pas la peine (ici, chacun décide lui-même si cela vaut la peine de coder pendant 3 semaines la nuit pour un prix de 100 mille, réparti entre toute l'équipe, et même avec le risque de ne pas l'obtenir). Mais c’est souvent la seule chance d’avancer.
3. Sélection de l'équipe. Comme je l'ai remarqué lors des discussions du hackathon, beaucoup abordent cette question de manière assez frivole (bien que ce soit la décision la plus importante qui déterminera votre résultat au hackathon). Dans de nombreux domaines d'activité (tant dans le sport que dans les hackathons), j'ai vu que les gens forts ont tendance à s'unir aux forts, les faibles aux faibles, les intelligents aux intelligents, enfin, en général, vous voyez l'idée... C'est à peu près ce qui se passe dans les chats : des programmeurs moins forts sont immédiatement recrutés, des personnes qui n'ont aucune compétence précieuse pour un hackathon restent longtemps dans le chat et choisissent une équipe sur le principe que si seulement quelqu'un le prenait . Lors de certains hackathons, la répartition aléatoire des équipes est pratiquée et les organisateurs affirment que les équipes aléatoires ne fonctionnent pas moins bien que celles existantes. Mais d'après mes observations, les personnes motivées trouvent généralement une équipe par elles-mêmes ; si quelqu'un doit être désigné, alors souvent, beaucoup d'entre eux ne viennent pas au hackathon.
Quant à la composition de l’équipe, elle est très individuelle et fortement dépendante de la tâche à accomplir. Je pourrais dire que la composition minimale viable d'une équipe est un concepteur - front-end ou front-end - back-end. Mais je connais aussi des cas où des équipes composées uniquement de front-ends ont gagné, qui ont ajouté un simple back-end dans node.js, ou créé une application mobile dans React Native ; ou seulement auprès de backenders 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 de sélection d'une équipe pour le hackathon était le suivant : j'avais prévu de constituer une équipe ou de rejoindre une équipe comme front-end - back-end - designer (je suis moi-même front-end). Et assez vite, j'ai commencé à discuter avec un backender python et un designer qui ont accepté l'invitation à nous rejoindre. Un peu plus tard, une fille, une analyste commerciale, qui avait déjà gagné un hackathon, nous a rejoint, ce qui a décidé de son adhésion à nous. Après une courte réunion, nous avons décidé de nous appeler U4 (URBAN 4, urban four) par analogie avec les quatre fantastiques. Et ils ont même mis une photo correspondante sur l'avatar de notre chaîne Telegram.
4. Sélection d'une tâche. Comme je l'ai déjà dit, vous devez avoir un avantage concurrentiel, la tâche du hackathon est sélectionnée en fonction de cela. Sur cette base, après avoir regardé et évaluant leur complexité, nous nous sommes arrêtés sur deux tâches : un catalogue d'entreprises innovantes de DPiIR et un chatbot d'EFKO. La tâche de DPIiR 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 dans node.js et DialogFlow. La tâche EFKO impliquait également du ML ; j’ai une certaine expérience, pas très étendue, en ML. Et selon les conditions du problème, il m'a semblé qu'il était peu probable qu'il soit résolu à l'aide d'outils ML. Ce sentiment s'est renforcé lorsque je suis allé à la rencontre Urban Tech Challenge, où les organisateurs m'ont montré un ensemble de données sur EFKO, où il y avait environ 100 photos de présentations de produits (prises sous différents angles) et environ 20 classes d'erreurs de mise en page. Et, en même temps, ceux qui ont commandé la tâche voulaient atteindre un taux de réussite de classification de 90 %. Du coup, j'ai préparé une présentation de la solution sans ML, le backender a préparé une présentation basée sur le catalogue, et ensemble, après avoir finalisé les présentations, nous les avons envoyées à l'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 participé aux discussions, a répondu tardivement et a même rempli des informations le concernant lors de la présentation au tout dernier moment, en général, des doutes sont apparus.
En conséquence, nous avons réussi la tâche du DPiIR et n'étions pas du tout contrariés de ne pas avoir réussi l'EFKO, car la tâche nous semblait étrange, c'est un euphémisme.
5. Préparation du hackathon. Lorsqu’il a finalement été appris que nous étions qualifiés pour le hackathon, nous avons commencé à préparer les préparatifs. Et ici, je ne préconise pas de 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 commencer à travailler, sans avoir à configurer d'outils et sans tomber sur des bugs d'une bibliothèque que vous avez décidé d'essayer pour la première fois lors d'un hackathon. Je connais l'histoire d'ingénieurs angulaires qui sont venus à un hackathon et ont passé 2 jours à configurer la construction du projet, donc tout doit être préparé à l'avance. Nous avions l'intention de répartir les responsabilités comme suit : le backender écrit des robots qui parcourent Internet et mettent toutes les informations collectées dans la base de données, tandis que j'écris une API dans node.js qui interroge cette base de données et envoie les données au front. À cet égard, j'ai préparé un serveur à l'avance en utilisant express.js et préparé un front-end en réaction. Je n'utilise pas CRA, je personnalise toujours le webpack pour moi-même et je sais très bien quels risques cela peut poser (rappelez-vous l'histoire des développeurs angulaires). À ce stade, j'ai demandé des modèles d'interface ou au moins des maquettes à notre designer afin d'avoir une idée de ce que j'allais présenter. En théorie, il devrait aussi faire ses propres 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 d’un de mes anciens projets. Et cela a commencé à fonctionner encore plus vite, puisque tous les styles de ce projet avaient déjà été écrits. D'où la conclusion : un designer n'est pas toujours nécessaire dans une équipe))). Nous sommes venus au hackathon avec ces développements.
6. Travaillez au hackathon. La première fois que j'ai vu mon équipe en direct, c'était seulement à l'ouverture du hackathon au Central Distribution Center. Nous nous sommes rencontrés, avons discuté de la solution et des étapes de travail sur le problème. Et même si après l'ouverture nous avons dû prendre le bus pour Octobre Rouge, nous sommes rentrés dormir chez nous, en acceptant d'arriver sur place à 9.00 heures. Pourquoi? Les organisateurs voulaient apparemment tirer le meilleur parti des participants, c'est pourquoi ils ont organisé un tel programme. Mais, d’après mon expérience, vous pouvez coder normalement sans dormir une nuit. Quant au deuxième, je n'en suis plus sûr. Un hackathon est un marathon, vous devez calculer et planifier adéquatement votre force. De plus, nous avions des préparatifs.
Par conséquent, après avoir dormi, à 9.00 heures, nous étions assis au sixième étage de Dewocracy. Ensuite, notre designer a annoncé de manière inattendue qu'il n'avait pas d'ordinateur portable, qu'il travaillerait à domicile et que nous communiquerions par téléphone. C’était la goutte d’eau qui a fait déborder le vase. Nous sommes donc passés du quatre au trois, même si nous n'avons pas changé le nom de l'équipe. Encore une fois, ce n'était pas un gros coup dur pour nous : j'avais déjà le design de l'ancien projet. En général, au début, tout s'est déroulé sans problème et comme prévu. Nous avons chargé dans la base de données (nous avons décidé d'utiliser neo4j) un ensemble de données d'entreprises innovantes provenant des organisateurs. J'ai commencé la composition, puis j'ai commencé à node.js, puis les choses ont commencé à avoir des ratés. Je n'avais jamais travaillé avec neo4j auparavant, et au début je cherchais un pilote fonctionnel pour cette base de données, puis j'ai compris comment écrire une requête, puis j'ai été surpris de découvrir que cette base de données, lorsqu'elle est interrogée, renvoie des entités dans le forme d’un tableau d’objets nœuds et de leurs arêtes. Ceux. lorsque j'ai demandé une organisation et toutes les données qu'elle contient par TIN, au lieu d'un objet d'organisation, on m'a renvoyé un long tableau d'objets contenant des données sur cette organisation et les relations entre eux. J'ai écrit un mappeur qui a parcouru l'ensemble du tableau et collé tous les objets en fonction de leur organisation en un seul objet. Mais au combat, lors de la demande d'une base de données de 8 20 organisations, elle était exécutée extrêmement lentement, environ 30 à 30 secondes. J'ai commencé à réfléchir à l'optimisation... Et puis nous nous sommes arrêtés à temps et sommes passés à MongoDB, et cela nous a pris environ 4 minutes. Au total, environ 5 heures ont été perdues sur neoXNUMXj.
N'oubliez pas : n'emmenez jamais une technologie à un hackathon que vous ne connaissez pas, il pourrait y avoir des surprises. Mais, en général, à part cet échec, tout s’est déroulé comme prévu. Et déjà le matin du 9 décembre, nous avions une application entièrement fonctionnelle. Pour le reste de la journée, nous avions prévu d'y ajouter des fonctionnalités supplémentaires. À l'avenir, tout s'est relativement bien passé pour moi, mais le backender a eu tout un tas de problèmes avec l'interdiction de ses robots dans les moteurs de recherche, dans le spam des agrégateurs de personnes morales, qui arrivaient aux premières places des résultats de recherche lors de la demande pour chaque entreprise spécifique. Mais il vaut mieux qu’il en parle lui-même. La première fonctionnalité supplémentaire que j'ai ajoutée était la recherche par nom complet. Directeur général de VKontakte. Cela a pris plusieurs heures.
Ainsi, sur la page de l'entreprise dans notre application, un avatar du directeur général est apparu, un lien vers sa page VKontakte et quelques autres données. C'était une belle cerise sur le gâteau, même si cela ne nous a peut-être pas donné la victoire. Ensuite, j'ai voulu exécuter des analyses. Mais après une longue recherche d'options (il y avait de nombreuses nuances avec l'UI), j'ai opté pour l'agrégation la plus simple des organisations par code d'activité économique. Déjà le soir, au cours des dernières heures, je préparais un modèle pour afficher des produits innovants (dans notre application, il est censé y avoir une section Produits et Services), même si le backend n'était pas prêt pour cela. Dans le même temps, la base de données s'est agrandie à pas de géant, les robots d'exploration ont continué à fonctionner, le backender a expérimenté la PNL pour distinguer les textes innovants des textes non innovants))). Mais l’heure de la présentation finale approchait déjà.
7. Présentation. D'après ma propre expérience, je peux dire que vous devriez commencer à préparer une présentation environ 3 à 4 heures avant la date prévue. Surtout s’il s’agit de vidéo, son tournage et son 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 résolvait également un certain nombre d'autres problèmes d'organisation. À cet égard, nous ne nous sommes distraits du codage qu’au tout dernier moment.
8. Emplacement. Je n’ai pas aimé que les présentations et les finales aient lieu un jour de semaine différent (lundi). Ici, très probablement, la politique des organisateurs visant à tirer le meilleur parti des participants s’est poursuivie. Je n’avais pas prévu de m’absenter du travail, je voulais seulement assister à la finale, même si le reste de mon équipe a pris un jour de congé. Cependant, l'immersion émotionnelle dans le hackathon était déjà si forte qu'à 8 heures du matin j'ai écrit dans le chat de mon équipe (l'équipe de travail, pas l'équipe du hackathon) que je prenais la journée à mes frais, et je me suis rendu au centre bureau pour emplacements. Notre problème s'est avéré être dû à de nombreux data scientists purs, 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 les interdictions de leurs robots dans les moteurs de recherche. Nous étions la seule équipe à disposer d'un prototype fonctionnel. Et nous savions comment résoudre le problème. 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 pitchs des autres morceaux, on s'est rendu compte qu'on n'aurait aucune chance là-bas. Je tiens aussi à dire que nous avons eu beaucoup de chance avec le jury, ils ont minutieusement vérifié le code. Et, à en juger par les critiques, cela ne s'est pas produit dans toutes les pistes.
9. Finale. Après avoir été convoqués à plusieurs reprises devant le jury pour une révision du code, nous, pensant avoir enfin résolu tous les problèmes, sommes allés déjeuner chez Burger King. Là, les organisateurs nous ont rappelé, nous avons dû rapidement préparer nos commandes et repartir.
L'organisateur nous a montré dans quelle salle nous devions entrer et en entrant, nous nous sommes retrouvés à une séance de formation à la prise de parole en public pour les équipes gagnantes. Les gars qui devaient se produire sur scène étaient bien chargés, tout le monde est sorti comme de vrais forains.
Et je dois admettre qu'en finale, dans le contexte des équipes les plus fortes des autres filières, nous avions l'air pâles : la victoire dans la nomination des clients gouvernementaux est revenue à juste titre à l'équipe de la filière technologie immobilière. Je pense que les facteurs clés qui ont contribué à notre victoire sur la piste ont été : la disponibilité d'un flan prêt à l'emploi, grâce auquel nous avons pu réaliser rapidement un prototype, la présence de « points forts » dans le prototype (recherche de PDG sur les réseaux sociaux) et les compétences PNL de notre backender, qui ont également beaucoup intéressé le jury.
Et en conclusion, un traditionnel merci à tous ceux qui nous ont soutenus, le jury de notre track, Evgeniy Evgrafiev (l'auteur du problème que nous avons résolu lors du hackathon) et bien sûr les organisateurs du hackathon. C’était peut-être le hackathon le plus grand et le plus cool auquel j’ai jamais participé, je ne peux que souhaiter aux gars de maintenir un niveau aussi élevé à l’avenir !
Source: habr.com