Hier, un nouveau Yandex.Blitz a été lancé - cette fois, le concours sera intéressant pour les développeurs d'interfaces. Pour les titulaires de la première à la cinquième place, nous vous proposerons de nous rejoindre selon un schéma simplifié: une section entretien au lieu de quatre. Ainsi, Blitz reste le moyen le plus rapide pour se rendre à Yandex.
Les tâches de la compétition sont à nouveau proches des tâches de production de combat - vous aurez besoin non seulement de compétences frontales, mais également de connaissances en algorithmes.
Inscrivez-vous ici pour participer au tour de qualification.
Blitz est une bonne raison de parler de l'histoire des problèmes algorithmiques qui se posent dans le front-end industriel et de la façon dont ils diffèrent de ceux de la concurrence.
À propos des tâches
Des tâches algorithmiquement saturées dans le développement d'interfaces dans Yandex ont toujours surgi. Je me souviens d'exemples de 2005-2006. L'une de ces tâches était un système de travail avec des événements abstraits. Il était nécessaire de créer un noyau qui permettrait d'attacher des gestionnaires (spécifiés par une fonction) à des événements arbitraires (spécifiés par une chaîne), après quoi il déclencherait un événement spécifique et supprimerait la liaison du gestionnaire. Une complication supplémentaire était que les trois principales opérations énumérées auraient dû être effectuées le plus rapidement possible. À ce sujet, il y a même une section dans l'
un des anciens rapports .
Une autre tâche intéressante concernait l'emplacement des miniatures dans les résultats de recherche Yandex.Picture. Il fallait aligner le flux d'objets rectangulaires de même hauteur et de largeurs différentes sur le bord droit. Dans le cas général, ce problème n'a pas de solution, il a donc été autorisé de modifier la taille de l'image d'origine (réduire et recadrer), mais afin que la perte d'informations ne dépasse pas un seuil donné donné en pourcentage.
Des tâches ont également été associées au développement du moteur de modèle Yandex, connu pour les mots clés XJST et BEMTHML. La principale difficulté était de le rendre assez rapide, tout en conservant l'expressivité sémantique souhaitée. Vous trouverez des détails à ce sujet dans de nombreux rapports. Voici quelques-uns des premiers rapports avec des détails:
events.yandex.ru/lib/talks/43 et
events.yandex.ru/lib/talks/329 , il y en a beaucoup d'autres.
Toutes sortes de systèmes de traitement en temps réel, par exemple, lors du défilement et du glissement avec la souris, sont également souvent obligés de réfléchir. Vous devez trouver différentes astuces algorithmiques pour que l'interface - au moins subjectivement pour l'utilisateur - soit rapide si les actions réelles sont effectuées objectivement pendant une longue période.
Par exemple, dans l'une des premières versions de Yandex.Mail, il était possible de faire glisser presque tous les éléments clés les uns sur les autres: lettres dans des dossiers, étiquettes sur des lettres, lettres sur des étiquettes et même dossiers sur des lettres. Dans le processus, alors que l'utilisateur tenait l'objet «dans sa main» et qu'il le passait autour de l'écran, il fallait mettre en évidence les éléments sur lesquels il était possible de «le réinitialiser». La réalisation naïve "au front" ralentit jusqu'à l'impossibilité.
Différences entre les tâches réelles et compétitives
Les tâches à l'intérieur de Yandex, en règle générale, sont résolues en mode équipe. L'homme n'est pas livré à lui-même, comme dans un concours. Il peut obtenir de l'aide de ses collègues et doit faire correspondre le chemin de sa décision avec les intérêts des autres participants au processus.
Il se peut que vous ayez écrit une version rapide, mais la plupart de vos collègues considèrent que le code est excessivement difficile à comprendre, à développer et à prendre en charge ultérieurement. Dans de tels cas, des compromis doivent être recherchés. Le plus souvent, l'interaction en équipe est conçue comme un ajout séquentiel de quelque chose à une solution ou comme un processus simultané de programmation par paires. Nous ne faisons presque jamais la même chose en parallèle, afin de comparer plus tard et de choisir le meilleur.
Une autre différence importante est que le vrai code que nous écrivons existe et continue d'être supporté pendant longtemps. Ce n'est pas un processus «à oublier» et si seulement les tests réussissent. Il est important de se rappeler que votre code peut continuer à vivre - non seulement exécuté, mais également modifié - pendant de nombreuses années après l'écriture.
À propos des autres concours frontaux
Vous pouvez facilement trouver sur les sites Internet des tâches purement en JavaScript. Il s'agit essentiellement de la même programmation sportive, uniquement dans un langage spécifique. De plus, il existe un format «code dans le noir», lorsque la mise en page est imposée sans visualiser le résultat, à l'aveugle, on ne voit que le code. Les compétitions comme la nôtre ne sont pas particulièrement répandues, car - en raison des spécificités du développement d'interfaces - il est très difficile de sélectionner de bonnes tâches et de les vérifier automatiquement. Yandex a historiquement développé une solide école de tests automatiques du front-end, y compris en utilisant la comparaison de captures d'écran de navigateurs réels. Sur la base de ces développements, nous avons cherché à effectuer des vérifications de tâches en compétition. C'est aussi une expérience pour nous, mais nous sommes sûrs que cela fonctionnera et nous nous préparons déjà à approfondir le sujet.