А чем особенно отличаются вопросы "как работает мультипоточность?" и "а как вы применяли мультипоточность, для каких задач, что вам это дало, какие минусы?". К любому из них можно подготовиться, если человек нарисовал себе опыт, то и правдоподобный ответ на такой вопрос тоже легко нарисует (не без помощи LLM скорее всего).
По счастью, я прошлый раз проводил реальное интервью (не mock) года два назад, когда такой острой проблемы с нейросетками ещё не было. Не завидую тем кто сейчас собесит людей
Затем, чтобы решать реальные задачи проекта, а не синтетический пример. А решение реальных задач требует знакомства с проектом - это могут быть сотни тысяч строк кода, сложная архитектура, разные слои и компоненты. Как проверить умение решать такие задачи? Только по косвенным признакам: как человек справится с какой-то чётко изолированной задачей, для которой не нужно много контекста. Но как раз такую задачку легко решит языковая модель.
Всё-таки в продакшне чаще для СУБД используется отдельный сервер, так что выигрыш для самого приложения, которое отделено от сервера БД, вполне возможен.
Переменные, о которых идёт речь в статье: это часть строки запроса. Например, var1 и var2 в этом HTTP GET запросе:
https://example.com/items/var1/data?param2=var2
Но надо отметить, что есть общая рекомендация не передавать в path-сегментах (как var1) или query-параметрах (как var2) никакие чувствительные данные, даже при использовании HTTPS (а в этом случае все эти данные не передаются в открытом виде). И причины такой рекомендации - именно такие, что где-то по пути строка запроса может оказаться залогированной, например в логах веб-сервера.
Если нужно передавать чувствительные данные в запросе (например, токен авторизации), более предпочтительно их передавать в заголовках запроса, например так:
GET http://example.com/ HTTP/1.1
Host: decimalparser.net
Authorization: Bearer eyJbWbfs...
Postman - инструмент для создания, редактирования и выполнения HTTP запросов.
Штука довольно удобная - можно настраивать заголовки, тело запроса, изучать ответ сервера. Мне нравится тем, что можно создавать коллекции запросов (и даже сохранять примеры ответа от сервера на будущее, чтобы потом в оффлайне их изучать).
Ещё для выбранного запроса можно сразу получить сгенерированный код на одном из языков программирования (например C#). Можно настроить mock-сервер для тестирования веб-хуков (когда тестируемое приложение само отправляет запрос на стороннее API, которое нежелательно использовать при тестировании). Да и много других фичей.
Всё-таки новость кажется несколько преувеличенной. Мельком в статье упоминается, что секреты из заголовков не отправляются в логи. В логах могут встретиться только те данные, которые были отправлены в сегментах URL или в query параметрах. Но и для тех и для других есть общая рекомендация не использовать для чувствительных данных - именно потому, что высока вероятность, что они осядут в логах где-то "по дороге". И хотя при использовании https эти данные не передаются в открытом виде, они легко могут оказаться например в логах веб-сервера. Вот статья об этом https://blog.httpwatch.com/2009/02/20/how-secure-are-query-strings-over-https/
Так что имхо, автор сам стреляет себе в ногу и жалуется на последствия. Хотя лично я не одобряю, что множество данных отправляется на неизвестные сервера, конкретно эта претензия выглядит надуманной.
Кстати у себя тоже такое наблюдаю - иногда захожу в комментарии, и с удивлением вижу негодование по поводу ссылки на телегу, и думаю: "Ребята, а как Вы вообще её заметили?"
Автор, расскажите пожалуйста об упомянутом "правиле верхней трети шкалы". В гугле при поиске по этой фразе в кавычках результат только один - эта статья.
Если читаете через браузер на десктопе - выделяете фрагмент и по Ctrl-Enter отправляете сообщение об опечатке (фактически обычное личное сообщение, но со ссылкой на статью). Полагаю имелось в виду это.
Согласен, и дополню: этот условный Вася, если подвесил таким образом гирю, представляет общественную опасность.
Предположим, из его квартиры повалил дым/прорвало трубу/кто-то вызвал врачей, ошибившись, на его адрес. В итоге пострадает не злоумышленник, а вполне себе добросовестный слесарь/врач/полицейский.
Не соглашусь. Помню что промучавшись какое-то время, всё-таки получается дойти до решения. Если правильно понмю, нужно было просто прокликать все ручки, которые в исходном состоянии были в "неправильном" положении (именно в исходном состоянии, то есть надо запомнить нужные ручки).
Да, похоже я ошибся: они объявили что прекращают развитие .net framework, но будут продолжать его поддержку в виде багфиксов и т.п. То есть именно deprecated его не объявляли.
С ldap можно и под линуксом работать. Но в любом случае, это довольно специфические задачи. В настоящее время большинство веб-сервисов, написанных на asp.net, крутятся на линуксе.
А чем особенно отличаются вопросы "как работает мультипоточность?" и "а как вы применяли мультипоточность, для каких задач, что вам это дало, какие минусы?". К любому из них можно подготовиться, если человек нарисовал себе опыт, то и правдоподобный ответ на такой вопрос тоже легко нарисует (не без помощи LLM скорее всего).
По счастью, я прошлый раз проводил реальное интервью (не mock) года два назад, когда такой острой проблемы с нейросетками ещё не было. Не завидую тем кто сейчас собесит людей
Затем, чтобы решать реальные задачи проекта, а не синтетический пример. А решение реальных задач требует знакомства с проектом - это могут быть сотни тысяч строк кода, сложная архитектура, разные слои и компоненты. Как проверить умение решать такие задачи? Только по косвенным признакам: как человек справится с какой-то чётко изолированной задачей, для которой не нужно много контекста. Но как раз такую задачку легко решит языковая модель.
Всё-таки в продакшне чаще для СУБД используется отдельный сервер, так что выигрыш для самого приложения, которое отделено от сервера БД, вполне возможен.
Автор, пожалуйста сжимайте картинки перед там как вставлять их в статью. Если каждая картинка весит больше 1 МБ, чтение статьи становится неудобным
Практика показывает, что не все и не всегда обращают на это внимание.
С интересом прочитал, жду продолжения!
Нет, в ASCII буквы идут по алфавиту. Но удачно получилось, что все гласные на нечётных позициях
Так что самый младший бит всегда 1. Дальше можно смотреть на пятый с конца бит, который для всех кроме U равен 0.
Переменные, о которых идёт речь в статье: это часть строки запроса. Например, var1 и var2 в этом HTTP GET запросе:
https://example.com/items/var1/data?param2=var2Но надо отметить, что есть общая рекомендация не передавать в path-сегментах (как var1) или query-параметрах (как var2) никакие чувствительные данные, даже при использовании HTTPS (а в этом случае все эти данные не передаются в открытом виде). И причины такой рекомендации - именно такие, что где-то по пути строка запроса может оказаться залогированной, например в логах веб-сервера.
Если нужно передавать чувствительные данные в запросе (например, токен авторизации), более предпочтительно их передавать в заголовках запроса, например так:
Postman - инструмент для создания, редактирования и выполнения HTTP запросов.
Штука довольно удобная - можно настраивать заголовки, тело запроса, изучать ответ сервера. Мне нравится тем, что можно создавать коллекции запросов (и даже сохранять примеры ответа от сервера на будущее, чтобы потом в оффлайне их изучать).
Ещё для выбранного запроса можно сразу получить сгенерированный код на одном из языков программирования (например C#). Можно настроить mock-сервер для тестирования веб-хуков (когда тестируемое приложение само отправляет запрос на стороннее API, которое нежелательно использовать при тестировании). Да и много других фичей.
Интерфейс Postman
Всё-таки новость кажется несколько преувеличенной. Мельком в статье упоминается, что секреты из заголовков не отправляются в логи. В логах могут встретиться только те данные, которые были отправлены в сегментах URL или в query параметрах. Но и для тех и для других есть общая рекомендация не использовать для чувствительных данных - именно потому, что высока вероятность, что они осядут в логах где-то "по дороге". И хотя при использовании https эти данные не передаются в открытом виде, они легко могут оказаться например в логах веб-сервера. Вот статья об этом https://blog.httpwatch.com/2009/02/20/how-secure-are-query-strings-over-https/
Так что имхо, автор сам стреляет себе в ногу и жалуется на последствия. Хотя лично я не одобряю, что множество данных отправляется на неизвестные сервера, конкретно эта претензия выглядит надуманной.
Кстати у себя тоже такое наблюдаю - иногда захожу в комментарии, и с удивлением вижу негодование по поводу ссылки на телегу, и думаю: "Ребята, а как Вы вообще её заметили?"
Давайте немного переформулируем вопрос:
Автор, расскажите пожалуйста об упомянутом "правиле верхней трети шкалы". В гугле при поиске по этой фразе в кавычках результат только один - эта статья.
Если читаете через браузер на десктопе - выделяете фрагмент и по Ctrl-Enter отправляете сообщение об опечатке (фактически обычное личное сообщение, но со ссылкой на статью). Полагаю имелось в виду это.
Мне кажется, многие такие сочетания я обнаруживал просто методом "тыка"
Согласен, и дополню: этот условный Вася, если подвесил таким образом гирю, представляет общественную опасность.
Предположим, из его квартиры повалил дым/прорвало трубу/кто-то вызвал врачей, ошибившись, на его адрес. В итоге пострадает не злоумышленник, а вполне себе добросовестный слесарь/врач/полицейский.
Не соглашусь. Помню что промучавшись какое-то время, всё-таки получается дойти до решения. Если правильно понмю, нужно было просто прокликать все ручки, которые в исходном состоянии были в "неправильном" положении (именно в исходном состоянии, то есть надо запомнить нужные ручки).
Да, похоже я ошибся: они объявили что прекращают развитие .net framework, но будут продолжать его поддержку в виде багфиксов и т.п. То есть именно deprecated его не объявляли.
Вот эта новость https://devblogs.microsoft.com/dotnet/net-core-is-the-future-of-net/
С ldap можно и под линуксом работать. Но в любом случае, это довольно специфические задачи. В настоящее время большинство веб-сервисов, написанных на asp.net, крутятся на линуксе.