Проводил не так много собеседований, но по большей части стараюсь пройтись по заявленному опыту в резюме и базовым вещам, необходимым на проекте, развивая всё это в диалог. Чем сеньорней кандидат, тем больше делаю упор на первое, чем на второе, ибо научить человека всегда можно, а вот насколько хорошо он учится и насколько потенциально будет справляться понять гораздо важнее. Обычно сеньор в диалогах сам способен показать свою сеньорность, а беседах с миддлами очень часть просто видишь, что человек решал какие-то проблемы, имеет какой-то опыт, но вот не сеньор он, нет в его словах, мыслях и подходах этого, как бы он правильно не отвечал на вопросы.
Ну а уже по ответам и соответствию заявленного опыта и роли действительности можно принимать решения, подходит кандидат в проект или нет. Но опять же, не каждый кандидат со 100% правильных ответов должен проходить и не каждый кандидат с заметной долей ошибок или незнания должен отсекаться.
А разве звёзды что-то значат? Я обычно на документацию в первую очередь смотрю и наличие хороших примеров, по которым можно понять насколько удобно библиотеку использовать.
Это уже паразитизм в первую очередь, но это не отменяет эффект Даннинга-Крюгера. Они ведь уверены, что смогут это сделать и что это правильно, то есть они всё равно считают себя компетентными.
сервер столкнулся с неожиданным условием, которое помешало ему выполнить запрос
Ну так по ссылке и написано. Если условие неожиданно, то и обработать его не получится, так как код обработки отсутствует. Под обработать я подразумеваю что-то большее, чем просто поймать исключение и выдать стандартную ошибку. Потому что в случае обработки скорей всего это будет либо 4хх, либо какие-то 5хх, но не 500.
В целом я согласен с вашей идеей, что 5хх может быть хорошим триггером для мониторинга и алертинга и я не против использования 5хх, просто считаю, что их стоит использовать несколько раз всё взвесив и убедившись, что 4хх точно не подходят.
500 — это необработанная ошибка на сервере. Если ошибка обработана, в большинстве случаев это что-то из 4хх. Некоторые из 5хх можно кидать в случае обработки, семантически это будет верно, но есть вероятность, что 5хх придёт от веб сервера, поэтому клиенту придётся проверять content-type и другие вещи, чтобы различать их, поэтому в общем случае строить взаимодействие на 2хх/4хх лучше.
Я бы не согласился с выбором кодов для 4хх, хотя согласен с 5хх, но только в случае если провайдер единственный или указывается в параметрах ссылки. Иначе правильнее может быть вернуть 422, несмотря на то, что проблема с сервером, по причине того, что обращение идёт к ресурсу, а сам ресурс доступен, проблемы с одним из параметров ресурса.
А по 4хх — 406 не совсем о том, я бы первые 4 сделал 422, а последний 429. Впрочем всегда подходит вариант возвращать только 400.
Используем http-коды. Это позволяет хорошо структурировать и группировать ошибки, особенно при обработке на клиенте и при введении новых ошибок. Также позволяет лучше анализировать логи, создавать алерты и тд
Я слабо понимаю причину полного отказа от использования http-кодов, кроме банальной лени или используемых библиотек, которые их не поддерживают нормально или поддерживают в нежелательном виде (к примеру исключения на 4хх и 5хх). Но это скорее проблема выбора библиотек и легаси кода, новые проекты не стоит писать на этом же. Но таких случаях это может быть оправдано. Могу ещё понять использование нескольких протоколов, хотя это не исключает и не запрещает возможность использования http-кодов.
Даже если не углубляться, 200, 400, 401, 403, 404 — минимальный джентельменский набор, который позволит любому клиенту определить происходящее, не делая парсинг тела запроса.
В проектах приходилось использовать также 201, 204, 409, 410, 422, 429.
Как-то на одном из проектов лет 5-6 назад была чудо-разработка в виде атрибута, по которому в тэг по ссылке из атрибута грузились данные.
Пришёл я в этот проект и следующей таской была разработка диалогов, я так посчитал примерное количество запросов каждый раз, когда открываешь диалоги или просто список диалогов и настоял на том, что больше мы эту штуку юзать не будем.
Собственно я к тому, что в идеальном мире абсолютная декларативность конечно могла бы и сработать, но всегда есть ограничения и их довольно много. Для прототипирования такая штука могла быть идеальна, а для мобильного интернета и мобильных устройств, особенно лет 10 назад, — катастрофой.
Хорошо, что в статье приводятся сравнения с таблицами, приходится часто использовать гуглотаблицы, собственно на средней таблице время обновления при внесении изменения в поле, от которого зависят другие поля, может быть довольно заметным. А если в документе карусель из зависимых тегов с подгрузкой данных по ссылке, предсказуемость состояния такого документа будет очень быстро теряться, либо же будет страдать отзывчивость, особенно в случае использования функций для вычисления чего-то прямо в HTML.
Мне нравится в целом посыл и идея, с одной стороны это может выглядеть как React, встроенный в HTML, с другой может использовать схемы а-ля xml для расширения функционала, но куда лучше это всё будет работать, если данные будут разделены с представлением и их обработкой будет заниматься бизнес логика приложения, а не метатэги в HTML.
^C^C^C^Z^Z^C^Z^C^Zjhfjsfhjvbdjnvjdfhjvdhjsjfjssrigrsnsrgnjfsnjgfsnkdfnjd<Esc><Esc><Esc> i
Good article, I’d recommend it for those who plans to start using vim! wq
Если вы сидите над задачей и за 2 недели ничего не написали — вы решаете не задачу, а какую-то другую проблему. Возможно из разряда «а что, если на вход передать шестиногую собаку, у которой хвост спереди». Решение задачи — не только написание кода
Странно, я вот вообще был удивлён, что в Питере в убере такси находит почти мгновенно и водитель приезжает минуты за 3. В том же Воронеже такого счастья не было ни в одной службе такси, несмотря на то, что жил я в центре.
Ну а уже по ответам и соответствию заявленного опыта и роли действительности можно принимать решения, подходит кандидат в проект или нет. Но опять же, не каждый кандидат со 100% правильных ответов должен проходить и не каждый кандидат с заметной долей ошибок или незнания должен отсекаться.
Ну и с проблемами объяснения джуну как-то не сталкивался.
Ну так по ссылке и написано. Если условие неожиданно, то и обработать его не получится, так как код обработки отсутствует. Под обработать я подразумеваю что-то большее, чем просто поймать исключение и выдать стандартную ошибку. Потому что в случае обработки скорей всего это будет либо 4хх, либо какие-то 5хх, но не 500.
В целом я согласен с вашей идеей, что 5хх может быть хорошим триггером для мониторинга и алертинга и я не против использования 5хх, просто считаю, что их стоит использовать несколько раз всё взвесив и убедившись, что 4хх точно не подходят.
500 — это необработанная ошибка на сервере. Если ошибка обработана, в большинстве случаев это что-то из 4хх. Некоторые из 5хх можно кидать в случае обработки, семантически это будет верно, но есть вероятность, что 5хх придёт от веб сервера, поэтому клиенту придётся проверять content-type и другие вещи, чтобы различать их, поэтому в общем случае строить взаимодействие на 2хх/4хх лучше.
Я бы не согласился с выбором кодов для 4хх, хотя согласен с 5хх, но только в случае если провайдер единственный или указывается в параметрах ссылки. Иначе правильнее может быть вернуть 422, несмотря на то, что проблема с сервером, по причине того, что обращение идёт к ресурсу, а сам ресурс доступен, проблемы с одним из параметров ресурса.
А по 4хх — 406 не совсем о том, я бы первые 4 сделал 422, а последний 429. Впрочем всегда подходит вариант возвращать только 400.
Я слабо понимаю причину полного отказа от использования http-кодов, кроме банальной лени или используемых библиотек, которые их не поддерживают нормально или поддерживают в нежелательном виде (к примеру исключения на 4хх и 5хх). Но это скорее проблема выбора библиотек и легаси кода, новые проекты не стоит писать на этом же. Но таких случаях это может быть оправдано. Могу ещё понять использование нескольких протоколов, хотя это не исключает и не запрещает возможность использования http-кодов.
Даже если не углубляться, 200, 400, 401, 403, 404 — минимальный джентельменский набор, который позволит любому клиенту определить происходящее, не делая парсинг тела запроса.
В проектах приходилось использовать также 201, 204, 409, 410, 422, 429.
А не жалейте меня, я прекрасно живу, только кушать охота порой
Пришёл я в этот проект и следующей таской была разработка диалогов, я так посчитал примерное количество запросов каждый раз, когда открываешь диалоги или просто список диалогов и настоял на том, что больше мы эту штуку юзать не будем.
Собственно я к тому, что в идеальном мире абсолютная декларативность конечно могла бы и сработать, но всегда есть ограничения и их довольно много. Для прототипирования такая штука могла быть идеальна, а для мобильного интернета и мобильных устройств, особенно лет 10 назад, — катастрофой.
Хорошо, что в статье приводятся сравнения с таблицами, приходится часто использовать гуглотаблицы, собственно на средней таблице время обновления при внесении изменения в поле, от которого зависят другие поля, может быть довольно заметным. А если в документе карусель из зависимых тегов с подгрузкой данных по ссылке, предсказуемость состояния такого документа будет очень быстро теряться, либо же будет страдать отзывчивость, особенно в случае использования функций для вычисления чего-то прямо в HTML.
Мне нравится в целом посыл и идея, с одной стороны это может выглядеть как React, встроенный в HTML, с другой может использовать схемы а-ля xml для расширения функционала, но куда лучше это всё будет работать, если данные будут разделены с представлением и их обработкой будет заниматься бизнес логика приложения, а не метатэги в HTML.
^C^C^C^Z^Z^C^Z^C^Zjhfjsfhjvbdjnvjdfhjvdhjsjfjssrigrsnsrgnjfsnjgfsnkdfnjd<Esc><Esc><Esc>i
Good article, I’d recommend it for those who plans to start using vim!
wq