Hoy se ha abierto un nuevo conjunto en
la Escuela Yandex de Desarrollo de Interfaces en Moscú. Del 7 de septiembre al 25 de octubre, tendrá lugar la primera etapa de capacitación. Los estudiantes de otras ciudades podrán participar de forma remota o en persona: la empresa pagará el camino y el alojamiento en el albergue. En segundo lugar, es la etapa final que durará hasta el 3 de diciembre, solo se puede completar en persona.
Mi nombre es Julia Seredich, escribimos esta publicación junto con Sergey Kazakov. Ambos somos desarrolladores de interfaces en la oficina de Minsk de Yandex y graduados de SRI de los últimos años.
Con motivo de la apertura de la inscripción en Moscú, publicamos un análisis de las tareas de ingreso a la escuela anterior, aquí en Minsk.
Si rastreamos la historia de las tareas de SRI, de año en año probamos tres habilidades importantes para un programador:
- Diseño. Todos los desarrolladores deberían poder componer. No sucede que tengas al tío Seryozha que escribió para todo el equipo, y solo escribes guiones. Por lo tanto, cada estudiante debe mostrar cómo sabe escribir a máquina.
- Javascript Si el asunto se limitara a la composición tipográfica, entonces no tendríamos una escuela de desarrollo de interfaz, sino una escuela de diseño. La hermosa interfaz plegada necesita ser revivida. Por lo tanto, siempre hay una tarea en JS, pero a veces también es una tarea en algoritmos: los amamos mucho.
- La resolución de problemas es quizás la habilidad principal del desarrollador. Todo está cambiando muy rápidamente al crear interfaces. Es como Lewis Carroll: "Tienes que correr tan rápido solo para permanecer en el mismo lugar, pero para llegar a otro lugar debes correr el doble de rápido". Todos los días nos enfrentamos a nuevas tecnologías: es necesario contar con ellas y poder comprenderlas. Por lo tanto, en la tercera tarea, propusimos comprender las tecnologías con las que un desarrollador novato generalmente no está familiarizado.
En el análisis de cada tarea, diremos no solo sobre el procedimiento correcto, sino también sobre los errores comunes.
Tarea 1: Portafolio
La primera tarea fue realizada por el diseñador de Yandex. Colecciones Alexei Cherenkevich, que sabe escribir, y su colega en el servicio, el diseñador de interfaces Sergey Samsonov.
Condición
Cree un sitio de cartera: cuéntenos sobre usted, su trabajo y las expectativas de la escuela. El sitio debe coincidir con el diseño propuesto tanto como sea posible (enlaces a diseños: 1000 px , 600 px , 320 px , especificación ). Solo estamos interesados en el diseño, así que no use JavaScript.
Al verificar, tendremos en cuenta:
- tamaños de relleno, precisión de color, estilo de fuente, tamaño del tamaño;
- diseño semántico;
- la presencia de varios estados de elementos: visualización de botones y enlaces al desplazarse, resaltar campos de entrada activos, etc.
- compatibilidad entre navegadores (marcada en las últimas versiones de navegadores populares).
La ventaja será:
- uso de soluciones CSS modernas: flexbox, grid, etc.
- diseño adaptativo;
- uso de pre y (o) postprocesadores, ensamblaje, minificación, optimización del código de salida;
- Validación de formulario HTML, botón de carga de archivos estilizado.
La tarea es bastante voluminosa, por lo que puede omitir lo que no funcionará. Esto reducirá ligeramente el puntaje, pero aún puede demostrar su conocimiento. Al finalizar, envíenos dos enlaces: a la cartera y al código fuente en GitHub.
Los diseños propuestos en la asignación no eran solo con pantallas para dispositivos móviles, tabletas y computadoras de escritorio, sino también con una verdadera especificación.
Para agregar tanta objetividad como sea posible al resultado de la prueba de la primera tarea, había muchos criterios para esta prueba.
Criterios
Sitio completado . Esto parece obvio, pero algunos muchachos se perdieron algunos bloques por completo: o querían ahorrar tiempo o no podían hacerlo. El diseño se puede dividir condicionalmente en cuatro pantallas principales: la pantalla principal con un avatar, un bloque con una lista de expectativas de SRI, un bloque con una cartera y un bloque con información de contacto. Se pueden hacer en secciones o simplemente usando un div, lo principal es que los cuatro bloques están disponibles.
Diseño de diseño a juego . El diseñador hizo una especificación separada (incluidos colores, tipografía, estados de botones, etc.) para facilitar a los candidatos. A continuación había un consejo sobre la sangría y las características de la primera pantalla. Muy contento con los chicos que tuvieron en cuenta todos los deseos del diseñador: por ejemplo, la primera pantalla debería haber resultado no menos que la altura de la ventana gráfica.
Diseño adaptable : esto es cuando la interfaz no solo está hecha para que a tres resoluciones todo sea píxel por píxel de acuerdo con el diseño. En estados intermedios, el diseño tampoco debe desmoronarse. Alguien se olvidó de limitar el ancho máximo del contenedor y sacó todo a 1920 píxeles, alguien se equivocó con los fondos, pero en general los candidatos hicieron bien este trabajo.
Diseño semántico . "Cuántas veces le dijeron al mundo" que el enlace debería estar enmarcado como <a>, el botón debería estar enmarcado como <botón>. Afortunadamente, la mayoría de los candidatos han cumplido con este requisito. No todos reconocieron la lista al acecho en las expectativas del SRI al usarla con etiquetas div, pero no da tanto miedo. Hubo un candidato que insertó todas las etiquetas semánticas que solo conocía: dónde era necesario y dónde no. Por ejemplo, en lugar de una lista, <sección> y <artículo>. Aún así, la semántica se trata de comprender la composición de su página y el propósito de cada bloque (la mayoría lo hizo aquí), así como sobre el uso de preprocesadores y / o postprocesadores (pocos lo hicieron aquí, aunque esto también fue en puntos; menos y scss se conectaron con mayor frecuencia) .
Control deslizante de trabajo . En la tarea, escribimos que JS no se puede usar. Aquí se probó la capacidad de resolver problemas: el control deslizante se podía hacer usando los conectores <input> y <label for = ”# id”>. Toda la magia ocurre en el nivel de selector # button-N: marcado ~ .slider-inner .slider-slides. Cuando hacemos clic en una de las casillas de entrada, pasa al estado marcado. Podemos usar esto y asignar la traducción deseada a nuestro contenedor con diapositivas: transform: translate (-33%). Vea la implementación del control deslizante
aquí .
Listas desplegables . Todo se redujo a <input name = "accordion" type = "radio"> y un selector similar: .accordion-item input: marcado ~ .accordion-item__content. Vea la implementación
aquí .
La presencia de los estados: hover ,: active y: focu * . Un punto muy importante. La comodidad dependía de él durante la interacción con la interfaz. El usuario siempre debe recibir comentarios sobre sus acciones. Este ítem se verificó durante toda la interacción con el cuestionario. Si hice clic en el botón "Llámame" y visualmente no sucedió nada (a pesar de que se envió la solicitud), esto es malo, porque luego haré clic una y otra vez. Como resultado, se enviarán diez solicitudes y se me llamará diez veces. No olvides que no hay mouse en los dispositivos móviles, lo que significa que no debería haber un cursor estacionario. Y una cosa más que no preocupaba a quienes cumplían con el punto sobre la semántica. Si su control no es un elemento interactivo, cuando pase el cursor sobre él, el cursor seguirá siendo estándar. Se ve muy desordenado, incluso si prescribió una respuesta para flotar. No subestimes el cursor: puntero.
Animaciones Es importante que todo lo que sucede con los elementos de reacción sea suave. No hay nada instantáneo en la vida, por lo que la presencia de transiciones en vuelo estacionario y activo fue suficiente para que la interfaz sea más agradable. Bueno, aquellos que animaron el control deslizante y las listas generalmente están bien hechos.
Usando la última tecnología . Muchos usaron flex, pero nadie completó la tarea usando grid. Un elemento contado si flex se usó correctamente. Si en algún lugar, debido a estas mismas flexiones, el diseño se estaba separando, por desgracia, no recibió puntos adicionales.
Validación del formulario . Todo lo que se requería era agregar el atributo requerido a cada formulario de entrada. Agregamos puntos a quienes validaron el campo de correo electrónico como correo electrónico.
Estilización del botón de carga de archivos . Esperábamos ver un montón de formas: <input type = ”file” id = ”file” name = ”file” class = ”inputfile” /> y <label for = ”file”> Seleccione el archivo </label>. Además, se requería ocultar la entrada y dar estilo a la etiqueta. Hay otra forma común: hacer una entrada transparente y colocarla encima del botón. Pero no todos los navegadores permiten diseñar <input type = ”file”>, y esa solución no se puede llamar completamente cross-browser. Y es semánticamente más correcto hacer una etiqueta.
Compatibilidad entre navegadores . Verificamos que todo está bien, en las dos últimas versiones de los navegadores modernos (sin IE, los participantes tuvieron suerte), así como en Safari en iPhones y en Chrome en androides.
Nosotros, por el contrario, obtuvimos puntos si alguien usaba JS o Bootstrap: ambos hicieron que la tarea no tuviera sentido. Además, los participantes con Bootstrap no solo recibieron un punto negativo, sino que también perdieron muchos puntos por la semántica y los elementos implementados.
Aquellos que marcaron su sitio en algún lugar de Internet no obtuvieron una ventaja particular, pero los inspectores estuvieron muy contentos cuando no tuvieron que descargar los repositorios y ejecutarlos localmente en su computadora. Entonces esto sirvió como un plus en el karma.
La primera tarea fue muy útil principalmente para el alumno. Aquellos a quienes no hemos aceptado ahora tienen un resumen compilado: puede adjuntarlo con orgullo a todas las respuestas o ponerlo en sus páginas gh.
Tarea 2: Ruta de transporte
El autor de la tarea es Denis Balyko, jefe del grupo de interfaz de búsqueda.
Condición
Tienes un mapa del cielo estrellado. Muestra el nombre de cada estrella, así como la distancia desde ella a otras estrellas en segundos claros. Implemente la función de solución, que debe tomar tres argumentos: un objeto en el que las claves son los nombres de las estrellas, y los valores son las distancias a las estrellas (en el tráfico unidireccional en el espacio), así como los nombres de los puntos inicial y final de la ruta: inicio y finalización, respectivamente. La función debe devolver la distancia más corta desde el inicio de la estrella hasta el final de la estrella y el camino por el que debe ir.
Firma de la función:
const solution = function(graph, start, finish) {
Entrada de muestra:
const graph = { start: { A: 50, B: 20 }, A: { C: 40, D: 20 }, B: { A: 90, D: 90 }, C: { D: 160, finish: 50 }, D: { finish: 20 }, finish: {} }; const start = 'start'; const finish = 'finish';
Salida de muestra:
{ distance: 90, path: ['start', 'A', 'D', 'finish'] }
Nota: el marco de la solución está en la carpeta src /, coloque su solución en solution.js.
La verificación de la segunda tarea fue la más automatizada y objetiva. La mayoría de los chicos supusieron que era necesario implementar el algoritmo de Dijkstra. Aquellos que encontraron su descripción e implementaron el algoritmo en JS son geniales. Sin embargo, al verificar la tarea, encontramos mucho trabajo con los mismos errores. Buscamos fragmentos de código en Internet y encontramos un artículo de donde los participantes descartaron el algoritmo. Es curioso que muchas personas hayan copiado el código del artículo junto con los comentarios del autor. Tal trabajo recibió una puntuación baja. No prohibimos el uso de ninguna fuente, pero queremos que la persona profundice en lo que escribe.
Criterios
Los puntos principales fueron otorgados por las pruebas. A veces era evidente que los chicos estaban confundiendo el repositorio al cambiar el nombre de las carpetas, y las pruebas cayeron simplemente porque no podían encontrar los archivos que necesitaban. Este año tratamos de ayudar a esos tipos y les devolvimos todo a su lugar. Pero el próximo año planeamos cambiar a un sistema de concurso, y esto no será perdonado.
También había criterios "humanos", manuales. Por ejemplo, la presencia de un estilo de código único. Nadie redujo puntos por usar pestañas en lugar de espacios o viceversa. Otra cuestión es alternar comillas simples con comillas dobles de acuerdo con una regla conocida y poner punto y coma por separado.
Por separado, se tuvo en cuenta la claridad y la legibilidad de la solución. En todas las conferencias alrededor del mundo dicen que el trabajo del programador consiste en 80% de leer el código de otras personas. Incluso los escolares pasan por una revisión de código, con sus curadores y entre ellos. Entonces este criterio tenía un peso significativo. Hubo trabajos en los que no hubo variables de más de un carácter, por favor no lo haga. Los comentarios de los participantes fueron muy complacidos, con la excepción de aquellos que fueron idénticos a los comentarios de Stella Chang.
El último criterio es la disponibilidad de pruebas automáticas. Fueron agregados por solo unas pocas personas, pero para todos esto se ha convertido en una gran ventaja en el karma.
La decisión correcta:
const solution = function(graph, START, FINISH) {
Tarea 3: Calendario de eventos
Fue preparado por los desarrolladores de interfaces Sergey Kazakov y Alexander Podskrebkin.
Condición
Escriba un mini calendario para mostrar el horario. Puede tomar cualquier horario que desee. Por ejemplo, el calendario de conferencias de front-end en 2019.
El calendario debe verse como una lista. No hay otros requisitos de diseño. Permite configurar recordatorios de eventos para 3, 7 y 14 días. Después de la primera descarga con Internet, el calendario debería abrirse y funcionar sin conexión.
Recursos utiles
Calendario de conferencias de front-end:
confs.tech/javascript?topics=javascript%2Bcss%2Bux
Trabajadores de servicio:
developer.mozilla.org/en/docs/Web/API/Service_Worker_API/Using_Service_Workers
developers.google.com/web/fundamentals/primers/service-workers
API de notificaciones:
developer.mozilla.org/en/docs/Web/API/Notifications_API
La tercera tarea fue la más interesante de probar, porque había muchas soluciones, cada una con su propia. Verificamos cómo el candidato maneja tecnologías desconocidas, si sabe cómo investigar, si prueba sus soluciones.
Criterios
El calendario inventado . Sí, aún necesitaba ser inventado. Hubo quienes entendieron la condición demasiado literalmente y no insertaron una sola línea de código CSS. No parecía muy personal, pero si todo funcionaba, los puntos no disminuían.
Recuperando una lista de eventos de una fuente . Esta no es una tarea de composición tipográfica, por lo que no se contó la lista de eventos cosidos. Siempre puede cancelar la conferencia, reprogramarla, agregar una nueva. Por lo tanto, era necesario recibir datos del exterior y representar el diseño ya basado en el JSON recibido. Era importante de cualquier manera (usando el método fetch o XMLHttpRequest) para obtener los datos. Si una persona agrega un polyfill para buscar y marca su elección en el archivo Léame, esto cuenta como un plus.
Registrar un trabajador de servicio sin errores y trabajar sin conexión después del primer arranque.
Aquí hay un ejemplo de un trabajador de servicio con almacenamiento en caché programado en el primer arranque. Los detalles sobre los trabajadores de servicios, sus capacidades y formas de trabajar con ellos (estrategias para trabajar con el caché, trabajar sin conexión) se pueden encontrar
aquí .
La capacidad de establecer un recordatorio para que realmente funcione después de 3, 7, 14 días. Era necesario comprender la API de notificaciones,
cuyo enlace estaba directamente en la tarea. No esperamos ninguna implementación específica para verificar si ha llegado el momento de un impulso. Se aceptó cualquier opción de trabajo: almacenamiento en localStorage, IndexDB o sondeo periódico por parte de un trabajador de servicio. Incluso podría crear un servidor de inserción (aquí hay
un ejemplo ), pero no funcionaría sin conexión. Era igualmente importante obtener un impulso después de que la página se cerró y se abrió después de un tiempo. Si el recordatorio "murió" al mismo tiempo que se cerró la página, la decisión no contó. Es genial cuando los muchachos pensaron en los inspectores y aprovecharon la oportunidad para recibir un impulso ahora mismo, para no esperar 3 días.
La capacidad de hacer el icono en el escritorio (PWA). Verificamos el archivo
manifest.json con los íconos correctos. Algunos chicos crearon este archivo (o dejaron el generado en CreateReactApp), pero no agregaron los íconos correctos. Luego, al intentar instalar, se produjo un error como "necesita otro icono".
Estilo de código y estructura del proyecto . Como en la segunda tarea, observamos un estilo de código único (incluso si no coincidía con el nuestro). Algunos tipos jodieron linters, eso es genial.
Errores en la consola . Si había un indicador directamente en la consola de que algo estaba mal y el participante no le prestó atención, entonces tomamos puntos.
Resumen
Divertido en las decisiones de los participantes:
- Un cuestionario contenía el siguiente texto: “Un programador amigo ayudó a armar la aplicación de reacción. Le lancé preguntas sobre qué, cómo y por qué, dijo. Me gustó mucho, quiero saber más al respecto ". Apoyamos de todo corazón este cuestionario, pero desafortunadamente, el amigo del candidato realmente no lo ayudó a hacer una solicitud de trabajo.
- Un candidato envió un enlace a GitHub, donde se encontraba el archivo RAR; es difícil comentar esto de alguna manera. :)
- Otro candidato en el comentario en la primera línea del archivo solution.js honestamente admitió que copió el algoritmo.
Recibimos cuestionarios de 76 candidatos y seleccionamos 23 de ellos. Nos enviaron cuestionarios no solo desde Minsk, sino también desde Moscú, San Petersburgo e incluso Tatarstán. Algunos muchachos sorprendieron con sus profesiones actuales: uno de ellos es médico forense y el otro es estudiante de una universidad médica.
Resultó una distribución interesante de éxito al completar tareas. Los participantes completaron la primera tarea en promedio en un 60%, la segunda en un 50%, y la tercera resultó ser la más difícil y se completó en promedio en un 40%.
A primera vista, las tareas parecen complicadas y requieren mucho tiempo. La razón no es que queramos eliminar tantos candidatos como sea posible. Durante el entrenamiento, los estudiantes se enfrentan a tareas reales: charlar, Yandex.Music para niños o Yandex.Weather para personas que dependen del meteo. Para hacer esto, necesita una base de inicio.
Recuerdo cómo vi mi introducción al SRI hace dos años y pensé que nunca podría resolverlo. Lo principal en este momento es sentarse, leer cuidadosamente las condiciones y comenzar a hacerlo. Resulta que las condiciones contienen casi el 80% de la solución. Por ejemplo, en la condición de la tercera tarea (la más difícil), agregamos enlaces a trabajadores de servicio y API de notificaciones en MDN. Los estudiantes que estudiaron el contenido de los enlaces hicieron frente sin dificultad.
Realmente quiero que este artículo sea leído por los candidatos que planean ingresar al SRI en el futuro, no pudieron ingresar a la Escuela de Minsk o comenzar a realizar cualquier otra tarea de prueba. Como puede ver, es bastante posible actuar. Solo necesitas creer en ti mismo y escuchar todos los consejos de los autores.