главное, чтоб никто не мог подкрасться и пялиться в твой экран из-за спины
У меня было совершенно наоборот. Когда я сидел в опенспейсе, я занял себе угловой стол так, что все видели, что у меня на мониторах, но я не видел ничего кроме стены с одной стороны и окна с другой (стол был угловой).
Я работал под музыку в наушниках и вообще забывал, что я не у себя дома, а где-то в офисе. Это было для меня самое комфортное место посадки в опенспейсе)
Во-первых, до использования typeof можно явно проверить на null. Прям через оператор сравнения. Это будет явно и очевидно для всех читающих.
Во-вторых, я такие вещи обязательно покрываю unit тестами. Если есть какое-то не очевидное поведение JS, о которым я забыл, я об этом сразу узнаю. Уж на null в тестах проверить можно.
Возможно, есть специфичные проекты, где проверка typeof null — это нечто обыденное, что встречается часто, и без знания этого с проектом просто нельзя работать. Но я в таких проектах пока не работал (что, конечно, не значит, что их нет). Но даже там при ревью тебе коллеги напомнят/подскажут об этой вещи, если эта такой частый у них кейс.
Это нечестный вопрос. Пригождается очень редко. Забывает очень быстро. Код, который полагается на такое поведение, должен комментироваться. Я забуду через неделю, что возвращает typeof null и мне за это не стыдно. Я не могу каждые полгода перечитывать спецификации Javascript только для того, чтобы быть способным ответить на этот вопрос или для того, чтобы приготовиться к случаю (цитата) «Вот не будет завтра lodash, отрубит нам РКН интернет или еще какой катаклизм случится».
Вообще, завалить любого человека на edge-кейсах очень просто. Даже если он реально сильный разработчик с богатым опытом.
У меня вот любимые области, с которыми я много работаю и о которых много читаю, — это особенности HTTP протокола и безопасность в вебе. Это огромные темы, на которые написано много материала и в которых происходят постоянные изменения. Браузеры/сервера постоянно меняются. И эти темы имеют непосредственное отношение к веб-разработке.
Я уверен, вам было бы неприятно, если бы я начал собеседование с заковыристых вопросов по хеадерам, потом скажу, что это вот используется в наших проектах, и раз вы не знаете ответ на этот вопрос, то возможно вы даже до джуниора не дотягиваете.
Это логично, что когда ты написал функцию, которая называется isObject(), ты пишешь на нее тест и передаешь туда массив/объект/строку/число/пустой_объект/undefined/null.
Если вы используете защиту от CSRF (а лучше бы вам её использовать), то удобнее передавать CSRF-токен в отдельном заголовке (типа X-CSRF-Token) для всех запросов, а не внедрять вручную в каждый запрос. Хранить CSRF токен в куках плохо по той причине, что куки можно украсть, в чём собственно и состоит суть CSRF атаки.
Это не верно.
Во-первых, суть CSRF атаки не состоит в том, чтобы украсть кукисы. Она состоит в том, что приложение злоумышленника шлет запросы от лица пользователей в другое веб-приложение.
Во-вторых, кукисы с CSRF-токенами нельзя украсть, если в браузере отсутствуют уязвимости. Вся суть защиты от CSRF-атак строится на том, что кроме оригинального сайта ни у кого больше нет доступа прочитать содержание кукисов.
В-третьих, никто не использует кукисы с CSRF-токенами без хеадеров. В этом нет никакого смысла. Поскольку кукисы проставляются и отправляются браузером автоматически, то они не дают сами по себе никакой защиты. Сайт злоумышленника, попытавшись отправить запрос от имени пользователя, успешно это сделает, если кроме кукисов ничего нет. Поскольку браузер проставит все кукисы сам.
Вся суть защиты состоит в том, что клиент отправляет одновременно токен и в хеадере, и в кукисах. И этот токен должен совпадать.
Мне кажется, что для русскоязычного человека это достаточно простой и интуитивный топик. Именительный падеж — who, остальные — whom. Или можно просто всегда использовать who.
Американцы, в принципе, очень редко используют whom. И это не является ошибкой. Напротив, иногда использование whom звучит излишне литературно. Пару раз натыкался в кинематографе и литературе на ситуации, когда персонаж использовал whom и его «подкалывали» тем, что говорит слишком напыщенно.
Не могу утверждать, что это прям мировые тренды, но представить конкретно хирурга или курьера — достаточно просто.
Роботизированная дистанционная хирургия — довольно популярная тема для обсуждений. Мне кажется, я за последние пару месяцев даже на хабре статьи об этом видел.
Что касается курьеров, то тоже мелькали статьи, что где-то уже используют дронов для доставки пиццы.
Про распространенность/«трендовость» данных явлений ничего сказать не могу.
Число людей, у которых вообще есть доступ к тому, чтобы уронить БД, должен быть минимальным. А все sql update скрипты должны быть проверены перед исполнением на тест-среде.
Новичок… не должен произносить слов
Пусть подчеркивает очевидные проблемы, пока глаз не замылился. Бывает, что так долго варишься в своем проекте, что перестаешь обращать внимание на что-то. Но, конечно, большую часть предложений новичка придется отклонить по тем или иным причинам.
Никогда не критикуй не разобравшись.
При ревью кода коллег не всегда есть время прям полностью вникать во все мелочи. Если не уверен, лучше прокомментировать/спросить. В худшем случае, тебе скажут, что не прав. В лучшем — поможет найти проблему. Даже если код корректен и ты сам неправильно что-то понял, такие замечания могут выявить места, которые лучше закомментировать или переписать более явно.
Но это все, конечно, варьируется от команде к команде.
Это как Java — огромный рынок, на котором всё хорошо, но ничего нового нет. Как с этой проблемой справиться — не знаю.
Вот эту мысль было бы неплохо развить в статье. С моей личной позиции «огромный рынок, на котором всё хорошо, но ничего нового нет» — это вообще не проблема, а наоборот. И я очень рад, что сейчас во фронт-энде все гораздо более стабильно, чем 2-3 года назад, когда, если утром не прочитал новости, то к обеду ты уже не разбираешься в трендах.
Если есть возражения против такой формы собеседования, вежливо скажите об этом интервьюверу. Вставать в позу или обижаться — это не серьезно и просто не профессионально. Более непрофессионально, чем попросить написать программу на листочке.
Так одному кандидату не понравилось, что попросили написать SQL запрос на листочке — он «встал и ушел». Второму не понравилось, что спросили теорию, он встал и ушел. Третьему не понравилось, что спросили, чем не нравится текущее место работы — он встал и ушел.
Завтра этому же кандидату уже на рабочем месте что-то не понравится и он, вместо того, чтобы объяснить свою позицию, «встанет и уйдет».
У меня было совершенно наоборот. Когда я сидел в опенспейсе, я занял себе угловой стол так, что все видели, что у меня на мониторах, но я не видел ничего кроме стены с одной стороны и окна с другой (стол был угловой).
Я работал под музыку в наушниках и вообще забывал, что я не у себя дома, а где-то в офисе. Это было для меня самое комфортное место посадки в опенспейсе)
Во-первых, до использования typeof можно явно проверить на null. Прям через оператор сравнения. Это будет явно и очевидно для всех читающих.
Во-вторых, я такие вещи обязательно покрываю unit тестами. Если есть какое-то не очевидное поведение JS, о которым я забыл, я об этом сразу узнаю. Уж на null в тестах проверить можно.
Возможно, есть специфичные проекты, где проверка typeof null — это нечто обыденное, что встречается часто, и без знания этого с проектом просто нельзя работать. Но я в таких проектах пока не работал (что, конечно, не значит, что их нет). Но даже там при ревью тебе коллеги напомнят/подскажут об этой вещи, если эта такой частый у них кейс.
Это нечестный вопрос. Пригождается очень редко. Забывает очень быстро. Код, который полагается на такое поведение, должен комментироваться. Я забуду через неделю, что возвращает typeof null и мне за это не стыдно. Я не могу каждые полгода перечитывать спецификации Javascript только для того, чтобы быть способным ответить на этот вопрос или для того, чтобы приготовиться к случаю (цитата) «Вот не будет завтра lodash, отрубит нам РКН интернет или еще какой катаклизм случится».
Вообще, завалить любого человека на edge-кейсах очень просто. Даже если он реально сильный разработчик с богатым опытом.
У меня вот любимые области, с которыми я много работаю и о которых много читаю, — это особенности HTTP протокола и безопасность в вебе. Это огромные темы, на которые написано много материала и в которых происходят постоянные изменения. Браузеры/сервера постоянно меняются. И эти темы имеют непосредственное отношение к веб-разработке.
Я уверен, вам было бы неприятно, если бы я начал собеседование с заковыристых вопросов по хеадерам, потом скажу, что это вот используется в наших проектах, и раз вы не знаете ответ на этот вопрос, то возможно вы даже до джуниора не дотягиваете.
Это логично, что когда ты написал функцию, которая называется isObject(), ты пишешь на нее тест и передаешь туда массив/объект/строку/число/пустой_объект/undefined/null.
Напишет unit тесты и увидит, что для null работает не как ожидалось?
Да я подозреваю, что многие экстраверты тоже не особо рады. Я на работу пришел, чтобы работу работать, а не чтобы делать «Человеческие туннели».
Вся эта
дичьважная деятельность, помогающая сформировать культуру, должна быть только на добровольной основе.Это не верно.
Во-первых, суть CSRF атаки не состоит в том, чтобы украсть кукисы. Она состоит в том, что приложение злоумышленника шлет запросы от лица пользователей в другое веб-приложение.
Во-вторых, кукисы с CSRF-токенами нельзя украсть, если в браузере отсутствуют уязвимости. Вся суть защиты от CSRF-атак строится на том, что кроме оригинального сайта ни у кого больше нет доступа прочитать содержание кукисов.
В-третьих, никто не использует кукисы с CSRF-токенами без хеадеров. В этом нет никакого смысла. Поскольку кукисы проставляются и отправляются браузером автоматически, то они не дают сами по себе никакой защиты. Сайт злоумышленника, попытавшись отправить запрос от имени пользователя, успешно это сделает, если кроме кукисов ничего нет. Поскольку браузер проставит все кукисы сам.
Вся суть защиты состоит в том, что клиент отправляет одновременно токен и в хеадере, и в кукисах. И этот токен должен совпадать.
Американцы, в принципе, очень редко используют whom. И это не является ошибкой. Напротив, иногда использование whom звучит излишне литературно. Пару раз натыкался в кинематографе и литературе на ситуации, когда персонаж использовал whom и его «подкалывали» тем, что говорит слишком напыщенно.
Роботизированная дистанционная хирургия — довольно популярная тема для обсуждений. Мне кажется, я за последние пару месяцев даже на хабре статьи об этом видел.
Что касается курьеров, то тоже мелькали статьи, что где-то уже используют дронов для доставки пиццы.
Про распространенность/«трендовость» данных явлений ничего сказать не могу.
Число людей, у которых вообще есть доступ к тому, чтобы уронить БД, должен быть минимальным. А все sql update скрипты должны быть проверены перед исполнением на тест-среде.
Пусть подчеркивает очевидные проблемы, пока глаз не замылился. Бывает, что так долго варишься в своем проекте, что перестаешь обращать внимание на что-то. Но, конечно, большую часть предложений новичка придется отклонить по тем или иным причинам.
При ревью кода коллег не всегда есть время прям полностью вникать во все мелочи. Если не уверен, лучше прокомментировать/спросить. В худшем случае, тебе скажут, что не прав. В лучшем — поможет найти проблему. Даже если код корректен и ты сам неправильно что-то понял, такие замечания могут выявить места, которые лучше закомментировать или переписать более явно.
Но это все, конечно, варьируется от команде к команде.
Но в целом, согласен, что это не лучшая дата для обновлений.
А какие вообще могут быть плюсы от хранения пароля в открытом виде?
Вот эту мысль было бы неплохо развить в статье. С моей личной позиции «огромный рынок, на котором всё хорошо, но ничего нового нет» — это вообще не проблема, а наоборот. И я очень рад, что сейчас во фронт-энде все гораздо более стабильно, чем 2-3 года назад, когда, если утром не прочитал новости, то к обеду ты уже не разбираешься в трендах.
Если есть возражения против такой формы собеседования, вежливо скажите об этом интервьюверу. Вставать в позу или обижаться — это не серьезно и просто не профессионально. Более непрофессионально, чем попросить написать программу на листочке.
Так одному кандидату не понравилось, что попросили написать SQL запрос на листочке — он «встал и ушел». Второму не понравилось, что спросили теорию, он встал и ушел. Третьему не понравилось, что спросили, чем не нравится текущее место работы — он встал и ушел.
Завтра этому же кандидату уже на рабочем месте что-то не понравится и он, вместо того, чтобы объяснить свою позицию, «встанет и уйдет».
У меня однокурсники катались на машинах за несколько миллионов рублей. Были даже люди с ягуарами (машина, не животное).
I'm not interested in working with outsourcing companies, and I'm not a SCRUM supporter.
fixed